Free Quote

Agile Requirements Management

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.

  • Oct 20th, 2008 at 8:15 pm

    The alternative to using T-cards is to use a requirements database. This allows you to capture the relationships and dependencies between requirements/test-cases/user stories and to easily trace the impact of a change. If the database is web-based then all of the team members can access it especially when the team is distributed.

  • Oct 23rd, 2008 at 12:03 pm

    Thank you for your advice, Bruce!
    But from my point of view the T-cards system gives more pictorial view and is more applicable for Agile principles.

  • Nov 25th, 2008 at 9:24 pm
    Little green man

    Agrre with julkaft. Web-based systems (like JIRA, e.g.) is usually used for “hard” projects, and not for Agile. Of course, it’s useful in many cases, but T-cards usage is more flexible and visual. From my point of view, it’s more comfortable in case when Dev and QA teams are sitting together and can discuss the project status at any time.
    Another solution is to use these methods in the same time. For example, you use JIRA as bug-tracking system and storage of all requirements (submitted like Change Requests or New Features) and in the same time you use T-cards on the desk to have the clear view about current project status. We work this way about 1 year, and it’s really working :)

Leave a Comment
Your email will not be published