Download presentation
Presentation is loading. Please wait.
Published byGeoffrey McDowell Modified over 9 years ago
1
© Colin Potts C1-1 Requirements Documentation Colin Potts Georgia Tech
2
© Colin Potts C1-2 Customer- and developer- oriented documentation
3
© Colin Potts C1-3 Post-requirements traceability Requirements Test cases Implementation meets derived from passes/fails
4
© Colin Potts C1-4 Pre- and post-requirements traceability in AIMS Requirements Test cases Implementation meets derived from passes/fails Detailed design Specification meets
5
© Colin Potts C1-5 Traceability (cont). 1.1 The system shall blah, blah... 1.2 If the co-worker is blah, blah, the system shall inform the user... 1.2.1... Input: CoWorker record in which blah = 1, and... Expected output: blah = 2 if !(fizzwick(cw)) { for (i=0;i=max;i++) update(cw, i);... else... ReqtTest case Code....
6
© Colin Potts C1-6 Documentation standards l Common document standards exist »e.g IEEE 830 (Software Reqts. Specs.)
7
© Colin Potts C1-7 AIMS Documentation structure l Reqts. definition
8
© Colin Potts C1-8 AIMS Documentation structure l Specification & design
9
© Colin Potts C1-9 AIMS Documentation structure l Functional reqts./app. overview/det. design
10
© Colin Potts C1-10 Documentation and models l Models are formal representations (usually graphical) of the HAS or product »e.g. interaction, data flow, entity- relationship diagrams l Should models be produced with or after reqt. documentation? Customer- oriented Developer- oriented Models Customer- oriented Developer- oriented Models Option 1 Option 2
11
© Colin Potts C1-11 Qualities of requirements documents l Customer-oriented »Unambiguous »In customer’s language »Complete with respect to intent l Developer-oriented »Technically precise »Consistent »Complete specifications »Feasible »Testable l Both »Clear »Unambiguous »Free of “gold plating”
12
© Colin Potts C1-12 Requirements reviews & inspections l Informal reviews »Purpose: Critique and improve requirements »When: Incrementally & throughout »Who: Interested parties l Formal reviews »Purpose: Approve requirements and authorize project »When: When reqts. docs. are complete »Who: Owner (in SSM terms)
13
© Colin Potts C1-13 Class exercise: Requirements critique l Take the requirements document l Individually read several paragraphs carefully, looking for ambiguities l As a class, discuss: »general quality »specific issues »recommend reformulation of reqts.
14
© Colin Potts C1-14 Requirements documentation: how to find out more l Example standards »Contained in Dorfman & Thayer’s “green” tutorial –Heavy systems engineering & DOD emphasis –IS organizations will want to water down many of these guidelines
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.