Specifying requirements in the right way!
Cologne, 10 February 2004
Whenever one listens to discussions about requirements within software development projects, it seems like the attendees are really not discussing requirements. Very often, precise proposals or ideas for solutions are being discussed, without having analyzed the originating/original problem to the point. Also, executives tend to formulate their "requirements" as vague objectives which afterwards are not subsequently transferred into real requirements, consequently.Every development project runs the risk to fail, to run out of time or budget, or at least to create unnecessary annoyances and disappointments about the product to be built if it does not rest upon solid requirements specifications and management procedures. This is even more important in times of tight budgets and resources. So, what exactly are requirements and what is the right way to specify them?
The term "requirement" is defined in the standard ISO 9000:2000 as follows: "Expectation which is either being defined, presupposed, or legally committed." Therefore, requirements represent the "bridge" between the context description and a matching design solution. But requirements are by no means supposed to be product features nor functionalities.
The following example illustrates the difference between the problem definition, the implicit requirement and a solution that matches the requirement. The example is about a car radio:
Interestingly, many car radios do not fulfill the specified requirement, especially those which use push buttons for changing the volume. This is the result of the lack of understanding at the manufacturers' side for the context of use of car radio users, who only ever really look at the radio when they buy it in the shop. However, it is only fair to state, that many requirements are "hidden" in the context and therefore not obvious at all.
The following three characteristics characterize requirements which are formulated adequately:
1. Requirements are not specified in terms of a design solution.
2. Requirements are unambiguous and directly allow testing design solutions against them.
3. Requirements are based on contextual data and therefore have a rationale.
ProContext has developed the Context Scenario Method in order to specify the hidden/implicit requirements for development projects, software applications, and interactive products, consistently and comprehensively. The method enables qualified requirements engineers to develop and maintain comprehensive requirements specifications in the course of the project. The specifications can be adapted consistently to new/changed context information in the course of the project. This way the "sum of predictable surprises" will be minimized and the success of the project prepared, accurately.
ProContext offers professional requirements engineering and comprehensive requirements management as a service within development projects for software, web ware and interactive hardware systems.
ProContext GmbH
Deutzer Freiheit 77-79
50679 Köln
Germany
The term "requirement" is defined in the standard ISO 9000:2000 as follows: "Expectation which is either being defined, presupposed, or legally committed." Therefore, requirements represent the "bridge" between the context description and a matching design solution. But requirements are by no means supposed to be product features nor functionalities.
The following example illustrates the difference between the problem definition, the implicit requirement and a solution that matches the requirement. The example is about a car radio:
Context description:
The driver of a car typically changes the volume as well as the radio station while driving.
Requirement contained within this context:
Adjusting volume as well as selecting a radio station at a car radio must be possible without requiring the driver to take his eyes/attention away from the traffic in front of him.
Design solution:Looking at the specification of the requirement in the example it can be shown that many different solutions are possible and will meet this requirement - like voice input or controls integrated into the steering wheel. But, the specification of the requirement itself is unambiguous and can be clearly used for testing the suitability of any of a proposed design solution.
For example, usage of a knob for the volume with an integrated push button for selecting the next radio station.
Interestingly, many car radios do not fulfill the specified requirement, especially those which use push buttons for changing the volume. This is the result of the lack of understanding at the manufacturers' side for the context of use of car radio users, who only ever really look at the radio when they buy it in the shop. However, it is only fair to state, that many requirements are "hidden" in the context and therefore not obvious at all.
The following three characteristics characterize requirements which are formulated adequately:
1. Requirements are not specified in terms of a design solution.
2. Requirements are unambiguous and directly allow testing design solutions against them.
3. Requirements are based on contextual data and therefore have a rationale.
ProContext has developed the Context Scenario Method in order to specify the hidden/implicit requirements for development projects, software applications, and interactive products, consistently and comprehensively. The method enables qualified requirements engineers to develop and maintain comprehensive requirements specifications in the course of the project. The specifications can be adapted consistently to new/changed context information in the course of the project. This way the "sum of predictable surprises" will be minimized and the success of the project prepared, accurately.
ProContext offers professional requirements engineering and comprehensive requirements management as a service within development projects for software, web ware and interactive hardware systems.
ProContext GmbH
Deutzer Freiheit 77-79
50679 Köln
Germany
| Phone: | +49 221 759 92 595 |
| Fax: | +49 221 759 92 597 |
| E-Mail: | info@procontext.com |