From: dwwx@cbnewsk.ATT.COM (david.w.wood)
Subject: Re: System Requirements Specifications
Organization: AT&T Bell Laboratories
Date: Mon, 14 Dec 1992 05:02:24 GMT


|>In article 25211@nmpd.oz.au, 
|>andrew@alarbus.oz.au (Andrew Reye) writes:
||>... It appears to me that the
||>interface (i.e.  protocols etc) and the information ( objects, object
||>naming ) need to be clearly defined in the system requirements
||>specification.

|>In article 27046@den.mmc.com, 
|>jhull@vulcan-gw.den.mmc.com (Jeff Hull) responded
|>
|>A common practice that I believe to cause significant difficulties
|>is documenting the details of system interfaces in the system
|>requirements specification.

I have to agree.

|>A superior approach is to identify each distinct system interface
|>in the system requirements at an appropriate level of abstraction
|>and then place the details of the interface in a system interface
|>control document.

Such as referencing standards, eg, TCP/IP, OSI, etc.  Those aspects
of the interface which are requirements (ie I don't care how you do it
as long as these things are true, exist, whatever).

|>This allows for better differentiation between "in-scope" and 
|>"out-of-scope" changes and better control of the funding implications 
|>of such differences.

Yes.

But getting back to the original question about a presentation style
for the information...

There is IEEE 830, DOD 2167A and 2167B (still draft form?) and various
structured presentation forms such as yourdon, ward-mellor,
gane-sarson, hatley-prihbia, etc, and the newer OO presentations such
as booch, shlaer-mellor, coad, rumbaugh, etc.  For presenting
requirements, any of the above are equal.  But I don't think that
"presenting requirements" is what you are really after here.  I think
the following list is more along the lines of your needs (eh, your
requirements you might say):
	- funtionality, what functionality must be provided the system
	- performance, how fast, big, reliable, available, safe must the
		system be
	- portability, what platforms must the application be available on
	- usability, the requirements can be understood and used
	- testability, the requirements can be tested/verified as being
		achieved by the completed system
	- correct, the requirements are correct
	- unambigious, each requirement has only one interpretation
	- maintainable, the requirements can be easily added to, deleted,
		and modified while maintaining correctness.  Some attributes
		to consider are:
		- coupling (independence of subareas of the requirements)
		- cohesive (commonality of requirements grouped together)
	- complete, all information needed by the requirements customers
		are present (customers include, but not limited to
			system test
			system architect
			project manager
			system designers
			integration test)
		NOTE: all information means all requirements information,
			obviously the above customers will need other
			information which does not belong in system
			requirements.

Now, the original posting also mentioned that the application was of a
distributed nature.  Now that could mean either homogenous or heterogenous
distributivity (same thing distributed or different things distributed).
You may want a structure as follows:
			SYSTEM REQUIREMENTS
				|
				V
			SYSTEM ARCHITECTURE
			/	|	\
		       /	|	 \
		SUB-SYSTEM1  SUB-SYS2	SUB-SYSk
		REQs	      REQs	REQs
		|		|	|
		V		V	V
		SYB-SYS1    SUB-SYS2	SUB-SYSk
		ARCH	    ARCH	ARCH

The top level, system requirements, is to specify requirements on the
total system.  The system architecture explains how the requirements
are divided into "boxes", allocating and/or distributing requirements 
to each box.  The sub-system requirements specifies requirements at
the level of the subsystem
	sub-sys req=allocated sys req+sys arch info+elaborated info
Sub-sys arch specifies how sub-sys req are allocated and/or distributed
to boxes at that level (could be processes, other hardware, modules...).

The main point to all of this is to make sure you seperate requriements
from arch/design.  Make sure you understand the needs of the people
who use/need the requirements (they are all EQUAL customers). Too
often test personnel are ignored at this level, which is tragic because
too often things are stated as requirements which are not testable and
if they are not testable HOW DOES THE DEVELOPER KNOW WHAT TO DEVELOP???
The answer being, that they don't know, but they build something anyway
and then the testing group gets blamed for causeing trouble.

Anyway, understand your needs (ie what are the questions people want
to have answered by the system requirements) and then pick whatever
meets those needs (and be prepared to discover other needs that people
didn't realize they had, so whatever you pick should be adapatble).
Somebody needs to "own" the system requirements presentation method
so people know who to talk to when they have questions, problems or
suggestions for improvements.

Hope this helps...

David Wood
AT&T Bell Labs
200 Laurel Ave
MT 3E-337
Middletown, NJ 07721

(908) 957-3852

Newsgroups: comp.software-eng