Agility has become a widely practiced approach for developing and maintaining IT and software products. But there are still some concerns to use it for large or critical systems. “Requirements first” is one of the strongest arguments of the agile opponents. As a requirements engineer I totally agree with this… but when you take a closer look on how requirements are gathered and how a professionals work, you see, that an agile analysis is not so far away from dogmatic concepts. Here are some thoughts about it
Stakeholders must be available for the project and participate. They do not only deliver information, but they actively develop and form it with the whole project team.This includes:
Following the first thought, as a requirements engineer in an agile process, you should only use simple tools and documentation techniques to not discourage the stakeholders (and this is not only true for agility!). Proven methods are user-stories, flip chart sketches, wireframes for UI topics and post-its. For gathering requirements, workshops and questions (unstructured interviews) are the tools for success. Of course, the requirements engineers toolbox offers some more useful specialities – but use them with care and only step by step.
Get yourself an overview about the big picture. From there, you can dive into the deep. A big modeling approach is ineffective. Most of the requirements specified in the early phase of a project are never used or needed (indeed, 45% are never used). Always keep in mind, that things change from the start of the project to the end of implementation.
The shorter the feedback cycle between the gathering of requirements and their implementation is, the less need is for documenting the details.
Implementation should always be prioritized over documentation. Writing tests already is a documentation – and in fact the best one you can have. And the same is true for test cases. Why invest time and useless feedback cycles with your stakeholders about textual descriptions of requirements when an implemented case is the best point for discussion? And if the implementation is not correct yet, it can be adjusted with the next iteration.
The most effective requirement is one, that’s sufficient for the development team. Classic approaches invest a lot of time in documentation and traceability which is not used when the project is launched. Small bits can be discussed, prioritized and described more easily than large chunks. A requirements engineer should invest his time in work with the stakeholders and the agile team more then in writing words.
No Comments to “5 Thoughts on Agile Requirements Analysis”
Comments are closed