Managing requirements is one of six best practices that have been identified as having a positive effect on the quality of software. These six practices have been used as the basis of the Rational Unified Process (RUP).

Further information can be found on the five other best practices can be found at Software Best Practices.

The fundamental issue one has to grasp is that requirements of software will change. Even if the actual requirements are not altered, our perception and that of other stakeholders will change. Our old friend risk makes an appearance here. Imagine we do not keep abreast of the requirements and demands that are made on the software we build. How do we know if we have built the right thing? Even more importantly, are we building or going to build the right thing? Managing requirements thus becomes an important risk mitigation activity.

Definition of requirement:- "Condition or capability a system must have."

Three elements make up managing requirements.

1) Elicitation, organising, documenting. This is what most of us recognise as requirements gathering. In the traditional waterfall process this is a huge undertaking at the start of the project. Stereotypically the requirements would all be put in a binder, on a shelf and be left to quietly lose relevance

Under the RUP and other frameworks such as Agile, requirements elicitation etc is much more of a contextual activity. The aim is to undertake the activities as close as possible in time and place to the other development processes such as coding and testing. Tools are an important part of this process as they offer much greater flexibility and ability to link items of information.

2) Evaluating changes. If organisations impleted every change that was requested by a customer, then software development would be a very slow process. At the end of the process, would we have a better product?

The subject of requirements is so large, that the RUP devotes a discipline for it alone.

Proponents of Requirements Management have come up with some supporting arguments.

Complex projects often end up drifting out of control. Tw common example problem, is that of feature creep. A certain shrink wrap software manufacture is noted for its “bloatware”. The second is lack of understanding in what the software is supposed to do. Requirements Management can handle this.

Customer satisfaction and quality are perceived to improve. Only when everyone involved understands what is to be built and why, can the project be on a firm footing.

The project team needs to decide if a particular change is necessary and the best way to implement that change. One method of implementation may be technically perfect but awful in a business sense. The will have to be a trade-off and a decision. This leads us on to number 3.

3) Keeping track of trade-offs and decisions. Eventually someone will want to know why a particular decision was taken. In an ideal world this search would be for a good reason. For instance finding out if it could be avoided in future. Alternatively why bother making it again, if someone else has done all the research for you?

Mangement of requirement introduces traceability to the development process. Thus a requirement is derived ultimately from a customer need. A process such as the RUP will create links between the requirements and tests. Should a particular test expose a defect, we can trace this back to a requirement or requirements, even to the point of the customer need that we are not satisfying.

Elicitation, evaluating changes and tracking decisions are all conducive to prioritising requirements. For example Widget A is idenitified as an essential component in ensuring performance of the core architecture. Widget B may be used in the construction phase, to implement a remote piec of functionaliy. Widget A will receive the most attention in the early iterations. This will include functional testing and ongoing regression testing. Planning for the testing of widget B does not have to start until it is decided to incorporate into the design.

At the other end of the chain, a requirements weighting may have an effect on defects. Defects which affect Widget B will given more priority for fixing than Widget B.

Communication is improved by with requirements management. Clearer requirments ensure that everyone involved in the project has a common vocabulary. Misunderstandings, especially important ones, are exposed earlier on the project timeline.

The effect on testing directly is not very high. Indirectly, testing is affected by the improved clarity of the requirements, enabling more accurate inputs and outputs to be specified in test cases.