© Colin Potts C1-1 Requirements Documentation Colin Potts Georgia Tech

© Colin Potts C1-2 Customer- and developer- oriented documentation

© Colin Potts C1-3 Post-requirements traceability Requirements Test cases Implementation meets derived from passes/fails

© Colin Potts C1-4 Pre- and post-requirements traceability in AIMS Requirements Test cases Implementation meets derived from passes/fails Detailed design Specification meets

© Colin Potts C1-5 Traceability (cont). 1.1 The system shall blah, blah If the co-worker is blah, blah, the system shall inform the user 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....

© Colin Potts C1-6 Documentation standards l Common document standards exist »e.g IEEE 830 (Software Reqts. Specs.)

© Colin Potts C1-7 AIMS Documentation structure l Reqts. definition

© Colin Potts C1-8 AIMS Documentation structure l Specification & design

© Colin Potts C1-9 AIMS Documentation structure l Functional reqts./app. overview/det. design

© 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

© 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”

© 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)

© 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.

© 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