© Colin Potts C5-1 Process-oriented approaches Colin Potts Georgia Tech

© Colin Potts C5-2 Process-oriented philosophy l A system is what it does »so model it as a hierarchy of functions l Functional decomposition for description »but not necessarily for deriving the description l Requirements drive the decomposition process »but decomposition furthers understanding of the requirements

© Colin Potts C5-3 Overview: Structured Analysis l Structured Analysis »Functional decomposition based on data flow »Widely used »Intuitively simple

© Colin Potts C5-4 Mapping the system’s context l Describe system’s interfaces to its environment Burglar alarm system Sensor Householder Security company Clock Tone generator Status signal Settings Alarm cmd Security code Time Alarm notificn Warning tone cmd

© Colin Potts C5-5 Team exercise: Context mapping l In teams of 2-3 »Think about the system described in the requirements document »Draw a context diagram for the system l As a class »Discuss insights gained into the system’s requirements

© Colin Potts C5-6 Data flow diagrams l Define sub-functions & essential internal data flows Set alarm Raise alarm Monitor sensors Determine alarm conditions Settings Active sensors Intruder signal Security code Alarm signal Time Warning tone cmd Non- inhibited alarm Alarm cmd Alarm notificn

© Colin Potts C5-7 Layered DFDs l Functional architecture is hierarchical »System is a collection of interacting functions which may be decomposed further »Net inputs and outputs should be consistent across levels

© Colin Potts C5-8 Structured system specification l Structured Analysis has recommended document structure »Data flow diagrams form core models »Data dictionary »Process specs. Data element Definition AInteger* B Integer, Float A B C D E P Q R Process P Find sum of elements Find mean of elements

© Colin Potts C5-9 Detailed specification Data dictionary »Definitions of data elements that flow along data flows Backus-Naur Form »Settings ::= Out | In | Off »Security_Code ::= Digit Digit Digit Digit »Security_Code ::= Digit* »Alarm_Notificn ::= Time House_Id Sensor_Id l Process specs »Data flow diagram decomposition –Sub-diagram with consistent I/O »Pseudo-code defs

© Colin Potts C5-10 Structured Analysis: Evaluation l Advantages »Basic ideas and notations are simple »Many organizations have major investment in SA »Widespread tool support for notations and analyses Limitations »Top-down decomposition is better for explaining than for deriving »Essential architecture and implementation architecture often different –Document maintenance »Significant ambiguities –Serious for RT systems

© Colin Potts C5-11 How to find out more: Structured specification l Methodology-specific textbook »De Marco: Structured Analysis & System Specification l Book on methods, incl. SA »Wieringa: Requirements Engineering