Re: Writing software requirements; document change control

[Matthew Wong <wong -at- ACEC -dot- COM>]

On Wed, 18 May 1994 11:26:00 -0400 Peggy Thompson wrote:


>  Hi. Do any of you out there have experience writing requirements
>  documents for software development? Can you give me any hints,
>  point me to references?

>  Also, to what extent do you all--all of you--practice formal
>  document change control; i.e., placing your documents
>  under--booms of thunder, please--Configuration Management?

Peggy,

I hope the following suggestions about software requirements will prove
useful.

1.  My experience with documenting software requirements is limited to the
DoD environment.  The DoD has two standards for developing software:
DoD-STD-7935A (for developing database systems) and DoD-STD-2167A
(for developing software that will be integrated into defense hardware).
These standards include specifications for documenting software
requirements to establish its functional baseline.

2.  In my experience software requirements mean different things to different
people. To the customer, requirements usually mean specifications: the
software should do thins and that. To the user, requirements means how the
software should behave, that it should do this and that when I do this or that.
To the programmer, requirements means to what should the software do to
fulfill a specification.

3. Figure out who wants the requirements.  Then figure out in what
perspective (customer, user, programmer).

4. Then figure out to what level of detail. For example, some requirements
for a database may specify all the fields (i.e.m, the data dictionary).  I have
also written requirements that document how the system will be used: i.e.,
how the work flow in the office will change with it.

5. The purpose of a requirements document is to establish a baseline before
development begins.  What this means is that as you attempt to define the
requirements you will inevitably  find yourself in the midst of the politics of
managers and developers and customers.

6. While I hate a datelines, I recommend datelines for developing software
requirements to protect yourself--the process can go on and on and on.
Establish a dateline for everyone's input (customer, managers, etc.),
establishing a datelines for several reviews of your requirements. Establish a
final dateline for the final requirements.

These are just some thoughts.  Dont't hesistate to contact me at the
address below if you have questions.

Good luck.

Matthew (wong -at- acec -dot- com)