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

  1. Newsgroups: comp.software-eng
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!asuvax!ncar!csn!news.den.mmc.com!thor!jhull
  3. From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
  4. Subject: Re: System Requirements Specifications
  5. Message-ID: <1992Dec15.203415.6541@den.mmc.com>
  6. Summary: All requirements presentation styles are not equal.
  7. Sender: news@den.mmc.com (News)
  8. Nntp-Posting-Host: thor.den.mmc.com
  9. Reply-To: jhull@vulcan-gw.den.mmc.com
  10. Organization: Martin Marietta Astronautics Group
  11. References: <DWWX.92Dec14000224@cbnewsk.ATT.COM>
  12. Date: Tue, 15 Dec 1992 20:34:15 GMT
  13. Lines: 67
  14.  
  15.  
  16. David Wood wrote a wonderful article, most of which I heartily endorse.
  17. There are a couple of nits I would like to pick, howerer:
  18.  
  19. In article 92Dec14000224@cbnewsk.ATT.COM, 
  20. dwwx@cbnewsk.ATT.COM (david.w.wood) writes:
  21. |>There is IEEE 830, DOD 2167A ... and the newer OO presentations such
  22. |>as booch, shlaer-mellor,...  For presenting
  23. |>requirements, any of the above are equal.  
  24.  
  25. I can't prove it (yet), but I think "the above" are not equal.  Some of
  26. these presentations lend themselves to *proving* that the requirements
  27. are complete and consistent, e.g., Shlaer-Mellor, while others force one
  28. into the position of relying solely on an "informed opinion," aka an
  29. "engineering judgement," e.g., DoD2167A.  I really believe that a
  30. presentation that allows (or encourages) one to prove the requirements
  31. are complete and consistent is superior to one that does not.
  32.  
  33. MMAG is developing a tool called IADA that provides an executable
  34. simulation of a Teamwork OOA model to prove by demonstration that
  35. the requirements are complete and consistent.
  36.  
  37.  
  38.  
  39. |>the following list is more along the lines of your needs (eh, your
  40. |>requirements you might say):
  41.  
  42. *LOVE* your list.
  43.  
  44.  
  45. |>The top level, system requirements, is to specify requirements on the
  46. |>total system.  The system architecture explains how the requirements
  47. |>are divided into "boxes", allocating and/or distributing requirements 
  48. |>to each box.  
  49.  
  50. One common flaw I see (in 2167A projects) is that these allocations are
  51. not made cleanly.  All too often a given superior-level
  52. requirements document does not have its requirements written so that an
  53. entire identified requirement, i.e., a unit of text that has its own 
  54. identifier (such as paragraph number), gets allocated to the next lower
  55. level portion of the system.  This leads to *unbelieveable* discussions
  56. of what got allocated to one subsystem and what got allocated to the
  57. "adjacent" subsystem.
  58.  
  59.  
  60. |>    system test
  61. |>    system architect
  62. |>    project manager
  63. |>    system designers
  64. |>    integration test)
  65. |>...Make sure you understand the needs of the people
  66. |>who use/need the requirements (they are all EQUAL customers). 
  67.  
  68. Remember the contractual customer and the system end users, too!
  69.  
  70.  
  71.  
  72. ---
  73. -- -- -- --  --
  74.        _   _
  75.     /_    / ) / ) Jeff Hull           j.hull@vulcan-gw.den.mmc.com
  76.    //_) -/- -/-   1544 S. Vaughn Cir  
  77. /_/ \_/ /   /      Aurora, CO 80012    303-977-1061
  78.  
  79. No matter where you go ... there you are.
  80. #include <standard.disclaimer.h>
  81.  
  82.