home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.software-eng
- Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!cbnewsk!cbnewsk!dwwx
- 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
- Message-ID: <DWWX.92Dec14000224@cbnewsk.ATT.COM>
- In-Reply-To: jhull@vulcan-gw.den.mmc.com's message of 8 Dec 92 17:11:04 GMT
- References: <1992Dec8.063049.25211@nmpd.oz.au> <1992Dec8.171104.27046@den.mmc.com>
- Sender: dwwx@cbnewsk.cb.att.com (david.w.wood)
- Lines: 122
-
-
- |>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
-
-