WASHINGTON (07/31/2000) - Government agencies, and particularly the U.S.
Department of Defense, have long held that requirements management is an essential part of successful software development.
The concept seems straightforward: Write down a list of all the things the software or system is supposed to do, and that becomes the basis for what developers build.
The Software Engineering Institute (SEI) identifies requirements management as one of the "early" (Level 2) practices in its Capability Maturity Model (CMM).
If you don't practice requirements management, you can't qualify for Level 3, the minimum CMM level at which an organization is allowed to conduct software development on certain large government software contracts.
Even the typical agency software development request for proposals frequently contains requirements that become part of the contract. If either party to the contract ignores them, the consequences can be career-limiting. Unfortunately, this approach is a bit like rocketry: We line up the requirements and then we launch the project, trusting that nothing will change and all calculations will correctly place the rocket on target. It seldom works out that way, as we all know.
One problem is the requirements document format. It's difficult to convince people to sit down and read one, and if they do, many times they don't really understand it or try to force-fit what they're reading into a mental picture, ensuring a communication problem.
Moreover, there's no easy and fast procedure for "steering" the requirements rocket. Modifying requirements is normally subject to layers of review and sign-off and frequently results in contractor demands for more time and money.
It's common for people not to have a clear picture of how they want a system to work until they see parts of it running. Some software development methods try to take this into account by developing a prototype to help design or identify requirements.
But the prototype, by definition, doesn't specify all the aspects of what the finished system must do.
One approach advocated by some object-oriented developers is to rely on "use cases" (sometimes called scenarios, or stories) to define the requirements. A story describes something the system will do. A collection of all the stories about a system constitutes a specification for the system's behavior - in other words, a requirements definition. Coupled with frequent releases, this technique can provide a steering mechanism. In each release, an agreed list of stories is integrated, and managers and developers can agree to remove or add stories to a given release to stay within an estimated time and cost window.
Stories - with their discrete nature and manageable size - are easier for users to relate to.
If the developers partner with the users in building the system, using stories to define requirements and steer development can give the team an excellent basis for working together.
--Bragg is an independent consultant and systems architect with extensive experience in the federal market. He welcomes your questions and topic suggestions at firstname.lastname@example.org.