Currently, the development of new technologies generates new needs, which lead to other technologies, thus creating an innovative cycle. Therefore, companies, teams and employees are immersed in a fast, evolutionary process that, demands rapid and adequate responses. In this context, the development team needs to be prepared for requirements changes during the project. Seeing the rate on which the requirements advances, it is a concern to keep them up to date. This scenario calls for an agile approach of requirements gathering – a set of practices used in the survey of requirements in a holistic way, emphasized in the expected behavior of the software and focused on the business value of the application.
Agile Manifest values working software that adds value to the customer. This requires a minimum of documentation for software development. According to Angela Wick , prioritizing documentation is not agile; whenever you prioritize collaboration and use as few documents as possible, then you are using the agile requirements approach in your project.
Agile teams focus on faster delivery of feature, instead of spending months detailing system requirements. The customer no longer has to wait months to see the system and find out if what was correctly done. After each cycle (3 weeks on average), the client receives an executable version and that he/she can test in its own environment. Frequent feature delivery allows the customer to make more assertive decisions about the final product.
The agile approach makes the requirement elicitation much more flexible, timely, interactive, adaptable and just-in-time. Just-in-time is perhaps the word that best fits in that context, that is, delivering the requirements according to the needs of the client and in the established time.
Another very interesting and widely adopted approach in agile teams is the participation of the customer in iterations (sprints). This enabled the detection of possible requirements failures during the development process and then adapt them in real time, which in turn avoids wasting time in the development process.
Nowadays huge, over detailed specification tend to be much more simpler in an agile context, documentations are direct and summarized.
However, flows, diagrams and figures are still very welcome! It is often that we need the development staff to deploy the software with an expected level of quality. Just a diagram and a good conversation between Requirements and Developer and that’s it! With a minimum documentation (a diagram and a good conversation between the requirements analyst and the development team) it is often possible to deliver what the customer wish.
How to deliver the requirements quickly
When the Requirements Analyst finds himself under pressure between time and quality, the greater focus tends to stay on time. So, the most common is the person in charge of the requirements to go over the documentation without much dialogue. He or she guarantees that everything is in the document which follows a template or a checklist. However, this does not help speed up the requirements process. On the contrary, when most of the time requirements are spent on documentation and review and not on planning, elicitation and analysis, the longer and more painful the requirements process are.
According to Ambler (2004-2007)  one should model together the developers so latter can understand the requirements and what they are trying to build.
Consider these 5 requirements surveying activities:
Planning, eliciting, analyzing, documenting and reviewing.
How long is your team’s dedication to these activities?
Figure 1 – Slow requirements process
Figure 2 – Faster requirements process
Conforming to Angela Wick , if the invested percentage of your team fits more to the first chart, beware. You may be putting a lot of effort into documenting and reviewing something that might change and, therefore, is bound to rework. This may even result in more problems than benefits. Less time should be spent on documentation and review activities. Besides requiring a lot of time from the stakeholders, these activities may be unnecessary. Changes can occur at any time, even after long meetings or during testing when new requirements might be be identified.
Unlike Figure 1, the second graph (Figure 2) shows how the requirements process should be in an agile team. As requirements analysts, “owners” of the business, we must change attitude in order to achieve a critical and constructive dialogue during the elicitation of requirements and analysis. In a model process from the agile’s point of view, requirements gathering and analysis should take about 5-10% of the documentation and review phases. This is a considerable time-saving, approach change that leads to reduced risk of development rework. Therefore, this process must be completely carried out before the documentation step and review.
What really adds value is the customer’s business knowledge. It does not matter how the requirements are identified or documented, but whether the information needed to understand the solution is clear to all stakeholders involved.
The great challenge of requirement gathering is to document knowledge in a way that is useful to everyone and can be updated to keep up with constant changes.
Keep in mind: Agile is not a method, it a new way of thinking!
I thank Prof. MSc. Igor Muzetti Pereira da ICEA-UFOP for comments that greatly improved the manuscript.
O Blog é mantido por profissionais da MATERA, e portanto, as opiniões não necessariamente refletem a opinião da empresa.