home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / software / 4929 < prev    next >
Encoding:
Text File  |  1992-12-14  |  5.3 KB  |  135 lines

  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!spool.mu.edu!uwm.edu!linac!att!cbnewsk!cbnewsk!dwwx
  3. From: dwwx@cbnewsk.ATT.COM (david.w.wood)
  4. Subject: Re: System Requirements Specifications
  5. Organization: AT&T Bell Laboratories
  6. Date: Mon, 14 Dec 1992 05:02:24 GMT
  7. Message-ID: <DWWX.92Dec14000224@cbnewsk.ATT.COM>
  8. In-Reply-To: jhull@vulcan-gw.den.mmc.com's message of 8 Dec 92 17:11:04 GMT
  9. References: <1992Dec8.063049.25211@nmpd.oz.au> <1992Dec8.171104.27046@den.mmc.com>
  10. Sender: dwwx@cbnewsk.cb.att.com (david.w.wood)
  11. Lines: 122
  12.  
  13.  
  14. |>In article 25211@nmpd.oz.au, 
  15. |>andrew@alarbus.oz.au (Andrew Reye) writes:
  16. ||>... It appears to me that the
  17. ||>interface (i.e.  protocols etc) and the information ( objects, object
  18. ||>naming ) need to be clearly defined in the system requirements
  19. ||>specification.
  20.  
  21. |>In article 27046@den.mmc.com, 
  22. |>jhull@vulcan-gw.den.mmc.com (Jeff Hull) responded
  23. |>
  24. |>A common practice that I believe to cause significant difficulties
  25. |>is documenting the details of system interfaces in the system
  26. |>requirements specification.
  27.  
  28. I have to agree.
  29.  
  30. |>A superior approach is to identify each distinct system interface
  31. |>in the system requirements at an appropriate level of abstraction
  32. |>and then place the details of the interface in a system interface
  33. |>control document.
  34.  
  35. Such as referencing standards, eg, TCP/IP, OSI, etc.  Those aspects
  36. of the interface which are requirements (ie I don't care how you do it
  37. as long as these things are true, exist, whatever).
  38.  
  39. |>This allows for better differentiation between "in-scope" and 
  40. |>"out-of-scope" changes and better control of the funding implications 
  41. |>of such differences.
  42.  
  43. Yes.
  44.  
  45. But getting back to the original question about a presentation style
  46. for the information...
  47.  
  48. There is IEEE 830, DOD 2167A and 2167B (still draft form?) and various
  49. structured presentation forms such as yourdon, ward-mellor,
  50. gane-sarson, hatley-prihbia, etc, and the newer OO presentations such
  51. as booch, shlaer-mellor, coad, rumbaugh, etc.  For presenting
  52. requirements, any of the above are equal.  But I don't think that
  53. "presenting requirements" is what you are really after here.  I think
  54. the following list is more along the lines of your needs (eh, your
  55. requirements you might say):
  56.     - funtionality, what functionality must be provided the system
  57.     - performance, how fast, big, reliable, available, safe must the
  58.         system be
  59.     - portability, what platforms must the application be available on
  60.     - usability, the requirements can be understood and used
  61.     - testability, the requirements can be tested/verified as being
  62.         achieved by the completed system
  63.     - correct, the requirements are correct
  64.     - unambigious, each requirement has only one interpretation
  65.     - maintainable, the requirements can be easily added to, deleted,
  66.         and modified while maintaining correctness.  Some attributes
  67.         to consider are:
  68.         - coupling (independence of subareas of the requirements)
  69.         - cohesive (commonality of requirements grouped together)
  70.     - complete, all information needed by the requirements customers
  71.         are present (customers include, but not limited to
  72.             system test
  73.             system architect
  74.             project manager
  75.             system designers
  76.             integration test)
  77.         NOTE: all information means all requirements information,
  78.             obviously the above customers will need other
  79.             information which does not belong in system
  80.             requirements.
  81.  
  82. Now, the original posting also mentioned that the application was of a
  83. distributed nature.  Now that could mean either homogenous or heterogenous
  84. distributivity (same thing distributed or different things distributed).
  85. You may want a structure as follows:
  86.             SYSTEM REQUIREMENTS
  87.                 |
  88.                 V
  89.             SYSTEM ARCHITECTURE
  90.             /    |    \
  91.                /    |     \
  92.         SUB-SYSTEM1  SUB-SYS2    SUB-SYSk
  93.         REQs          REQs    REQs
  94.         |        |    |
  95.         V        V    V
  96.         SYB-SYS1    SUB-SYS2    SUB-SYSk
  97.         ARCH        ARCH    ARCH
  98.  
  99. The top level, system requirements, is to specify requirements on the
  100. total system.  The system architecture explains how the requirements
  101. are divided into "boxes", allocating and/or distributing requirements 
  102. to each box.  The sub-system requirements specifies requirements at
  103. the level of the subsystem
  104.     sub-sys req=allocated sys req+sys arch info+elaborated info
  105. Sub-sys arch specifies how sub-sys req are allocated and/or distributed
  106. to boxes at that level (could be processes, other hardware, modules...).
  107.  
  108. The main point to all of this is to make sure you seperate requriements
  109. from arch/design.  Make sure you understand the needs of the people
  110. who use/need the requirements (they are all EQUAL customers). Too
  111. often test personnel are ignored at this level, which is tragic because
  112. too often things are stated as requirements which are not testable and
  113. if they are not testable HOW DOES THE DEVELOPER KNOW WHAT TO DEVELOP???
  114. The answer being, that they don't know, but they build something anyway
  115. and then the testing group gets blamed for causeing trouble.
  116.  
  117. Anyway, understand your needs (ie what are the questions people want
  118. to have answered by the system requirements) and then pick whatever
  119. meets those needs (and be prepared to discover other needs that people
  120. didn't realize they had, so whatever you pick should be adapatble).
  121. Somebody needs to "own" the system requirements presentation method
  122. so people know who to talk to when they have questions, problems or
  123. suggestions for improvements.
  124.  
  125. Hope this helps...
  126.  
  127. David Wood
  128. AT&T Bell Labs
  129. 200 Laurel Ave
  130. MT 3E-337
  131. Middletown, NJ 07721
  132.  
  133. (908) 957-3852
  134.  
  135.