home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.software-eng
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!cs.utexas.edu!asuvax!ncar!csn!news.den.mmc.com!thor!jhull
- From: jhull@vulcan-gw.den.mmc.com (Jeff Hull)
- Subject: Re: System Requirements Specifications
- Message-ID: <1992Dec15.203415.6541@den.mmc.com>
- Summary: All requirements presentation styles are not equal.
- Sender: news@den.mmc.com (News)
- Nntp-Posting-Host: thor.den.mmc.com
- Reply-To: jhull@vulcan-gw.den.mmc.com
- Organization: Martin Marietta Astronautics Group
- References: <DWWX.92Dec14000224@cbnewsk.ATT.COM>
- Date: Tue, 15 Dec 1992 20:34:15 GMT
- Lines: 67
-
-
- David Wood wrote a wonderful article, most of which I heartily endorse.
- There are a couple of nits I would like to pick, howerer:
-
- In article 92Dec14000224@cbnewsk.ATT.COM,
- dwwx@cbnewsk.ATT.COM (david.w.wood) writes:
- |>There is IEEE 830, DOD 2167A ... and the newer OO presentations such
- |>as booch, shlaer-mellor,... For presenting
- |>requirements, any of the above are equal.
-
- I can't prove it (yet), but I think "the above" are not equal. Some of
- these presentations lend themselves to *proving* that the requirements
- are complete and consistent, e.g., Shlaer-Mellor, while others force one
- into the position of relying solely on an "informed opinion," aka an
- "engineering judgement," e.g., DoD2167A. I really believe that a
- presentation that allows (or encourages) one to prove the requirements
- are complete and consistent is superior to one that does not.
-
- MMAG is developing a tool called IADA that provides an executable
- simulation of a Teamwork OOA model to prove by demonstration that
- the requirements are complete and consistent.
-
-
-
- |>the following list is more along the lines of your needs (eh, your
- |>requirements you might say):
-
- *LOVE* your list.
-
-
- |>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.
-
- One common flaw I see (in 2167A projects) is that these allocations are
- not made cleanly. All too often a given superior-level
- requirements document does not have its requirements written so that an
- entire identified requirement, i.e., a unit of text that has its own
- identifier (such as paragraph number), gets allocated to the next lower
- level portion of the system. This leads to *unbelieveable* discussions
- of what got allocated to one subsystem and what got allocated to the
- "adjacent" subsystem.
-
-
- |> system test
- |> system architect
- |> project manager
- |> system designers
- |> integration test)
- |>...Make sure you understand the needs of the people
- |>who use/need the requirements (they are all EQUAL customers).
-
- Remember the contractual customer and the system end users, too!
-
-
-
- ---
- -- -- -- -- --
- _ _
- /_ / ) / ) Jeff Hull j.hull@vulcan-gw.den.mmc.com
- //_) -/- -/- 1544 S. Vaughn Cir
- /_/ \_/ / / Aurora, CO 80012 303-977-1061
-
- No matter where you go ... there you are.
- #include <standard.disclaimer.h>
-
-