Tell a good story
Government agencies, and particularly the Defense Department, have long
held that requirements management is an essential part of successful software
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