Using Agile in traditional requirements – Boost your requirements documentation

A number of Agile methods work exceedingly well when applied to traditional requirements management and testing. We recently discussed how to use User Stories in traditional requirements work, both in traditional system maintenance and when you’re developing new systems.

This article is about boosting your requirements documentation using Agile techniques.

Very often you will find that user stories are sufficient in many cases, especially if they are complemented with prototypes. It might not be necessary to describe basic functions in the form of heavy requirement specifications or use cases, with scenarios and alternative flows.

However, in cases where you feel that there is too little detail in a user story, it’s a good idea to complement the user story with use cases, traditional requirements, or decision tables.

One fully functioning alternative is to use your test cases as the basis of detailed requirements. Their purpose is roughly the same, and in addition, they make it easier to manage traceability between different levels of requirements and test documentation.

A common problem that can pop up when new functionality is delivered is discovering that the customer actually wanted something altogether different. To minimize this problem, we complement our requirements with prototypes when we develop ReQtest. We also combine the prototypes with usability tests whereby users execute an actual task in the system and explain out loud to the test lead if anything is difficult to understand or in any other way unclear.

Often we find things that need to be improved, and since we have such short iterations, we normally can address the problem by the next day and then repeat the test with a different user.

Usability tests can be done with wireframes, pictures drawn in illustration programs like Microsoft Visio or Balsamiq Mockups or with prototypes in the partially-complete system. Developers appreciate the fact that they get quick feedback, instead of needing to correct the problems much later. Prototypes work as a kind of “interpretation” where the developers confirm the requirement from their point of view. Since the customer understands early on what will be delivered, the requirement dialogue is easier, and needs are clarified iteratively.

Prototypes are a good way to improve the requirements dialogue, and confirm that the right system is being built according to the requirements, so use them!

Read more about Requirements – 

Four Scrum techniques to help you work efficiently – https://reqtest.com/blog/newsletters/four-scrum-techniques-to-help-you-work-efficiently/

What does ‘Lean’ mean for requirements management and testing? – https://reqtest.com/blog/newsletters/lean-and-requirements-management-and-testing/