Requirements Lifecycles

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 detailed 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 to 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 give 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 about four states:

• In product backlog
• In sprint backlog = not started
• In progress
• Done

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 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):

• Draft
• Internally prioritized
• Planned
• Refined
• Started
• Additional custom states not mentioned in the model such as Implemented and Verified
• Done
• 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 requirements life cycle 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.