Software projects start with requirements. But between 40% and 60% of software failures and defects are the result of poor software management and requirements definition. Managing requirements can be a challenge because we have been taught to capture all requirements up front, and achieve customer sign off.
One of the most visible differences between agile software development and traditional software development is the way that we approach requirements. Although Agile Development is much more flexible than more traditional development methodologies,
Agile Development does nevertheless have quite a bit of rigor and is based on the fairly structured approach of lean manufacturing as pioneered by Toyota.
There are the following basic principles of managing requirements:
- Software development teams should only create the documentation that adds value.
- Creating documentation is a time-consuming and expensive process, so if that documentation doesn’t help the development process then it shouldn’t be created at all.
- Teams should choose a methodology that is appropriate to the project. Generally the larger and more distributed the team or the more critical a project is, the greater the need for documentation.
- A common approach amongst Agile Development teams is to represent each requirement, use case or user story (XP programming), on a card and use a T-card system to allow stories to be moved around easily as the user/business representative on the project adjusts priorities.
Requirements are broken down into very small pieces in order to be achieved; and actually the fact it’s going on a card forces it to be broken down small. The advantage it has over lengthy documentation is that it’s extremely visual and tangible; you can stand around the T-card system and whiteboard discussing progress, issues and priorities.
In short, the principle of Agile Requirements Management is to document the bare minimum amount of information that will allow a feature to be developed, and always broken down into very small units.