Requirements are highly controversial in software development. There is always too much and too little requirements. They are often blamed for project failure or seen as required for project success.
I have seen cases where there were too detailled and complex requirements. The result was that everyone worked around the official requirements and used other more informal requirements.
I have also seen cases where the requirements were way to unclear. It became impossible too know for certain what they meant or when they had been met.
In agile software development, the supplier (ideally) works closely with the customer to clearly define requirements. In practice, this is not at easy at it seems. In my experience many customers and end-users do not know what they need before they see it.
There is a host of different techniques that can be used to improve requirements engineering in software development. Agile methods provide a number of methods such as iterative and incremental development, user-centred design — always available customer, acceptance test-driven development etc. About a recently published book on Agile Software Requirements.
Something that can really help is a good requirements life cycle model. In Scrum and XP the default requirement has approximately four states:
- In product backlog
- In sprint backlog = not started
- In progress
Sometimes a more complex requirements life cycle model is needed. One such model that I have enjoyed working with is the requirements abstraction model by Gorscheck and Wohlin. In all fairness, I should mention that I first started using it on the recommendation of Johan Natt och Dag. Some of the states used in the requirements life cycle model of the requirements abstraction model include (and a few of my own added as well):
- Internally prioritized
- Additional custom states not mentioned in the model such as Implemented and Verified
- Here I usually add Retired
This more complex model is perhaps better adapted to methods such as Kanban (more here) or SPI-LEAM, by Petersen and Wohlin, than Scrum and XP mentioned above.
Today, Google alerted me about an interesting research article by Anthony White where a number of different requirements lifecycle models are analyzed from a systems dynamics perspective. The main model considered in the article is considered as “uncontrollable and unobservable”. While I am not quite sure about the value provided by the research presented in the article, it was an interesting read.