Tracking changes to requirements in Agile development

Tracking changes to requirements in Agile development

What is the best way to track changes to requirements?

    Requires Free Membership to View

    When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.

    Hannah Smalltree, Editorial Director

    By submitting your registration information to SearchSoftwareQuality.com you agree to receive email communications from TechTarget and TechTarget partners. We encourage you to read our Privacy Policy which contains important disclosures about how we collect and use your registration and other information. If you reside outside of the United States, by submitting this registration information you consent to having your personal data transferred to and processed in the United States. Your use of SearchSoftwareQuality.com is governed by our Terms of Use. You may contact us at webmaster@TechTarget.com.

This is a loaded question that depends on many variables and requires a unique answer for different development teams. You have to consider the problem domain, your software development lifecycle (SDLC), and overall ALM process. Of course, problem complexity and the ability to deliver well-defined, stable requirements will impact change tracking as well. 

From my experience with delivering custom business applications, the best way to track changes to requirements is by using an Agile SDLC and let your development process take care of the problem. By that, I mean: 

  • With most Agile approaches, you do not try to capture formal requirements. Instead, you start with high-level objectives and use case-driven features aligned to individual users. We practice this at OutSystems, as we have found that aligning a feature to individual users ensures that you don’t overload a given feature definition.

 

  • The next step is to simply work in a priority order and use the working application to decide, with all stakeholders, if the requirement is complete. Of course, you do this on a rapid (sprint) iterative basis, ideally spanning one to two weeks. Working this way constantly refines the real business needs (a.k.a. requirements) and aligns them with priority and available resources, resulting in a very lean business application. Tracking change becomes inherent to the process -- simple, efficient and elegant.

So, what’s the best way to track change? A simple email after the sprint review meeting will do. By sending these wrap-up emails, you ensure everyone is kept up to speed on what was decided in the meetings, and you keep a lightweight historical record of the project. It’s the Agile way to do it.

This was first published in March 2011