1 / 11

Process-oriented approaches

Process-oriented approaches. Colin Potts Georgia Tech. Process-oriented philosophy. A system is what it does so model it as a hierarchy of functions Functional decomposition for description but not necessarily for deriving the description Requirements drive the decomposition process

plato
Download Presentation

Process-oriented approaches

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Process-oriented approaches Colin Potts Georgia Tech

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

  3. Overview: Structured Analysis • Structured Analysis • Functional decomposition based on data flow • Widely used • Intuitively simple

  4. Mapping the system’s context • Describe system’s interfaces to its environment Alarm notificn Security company Sensor Time Status signal Burglar alarm system Clock Alarm cmd Settings Tone generator Security code Warning tone cmd Householder

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

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

  7. Layered DFDs • 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

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

  9. 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 Process specs Data flow diagram decomposition Sub-diagram with consistent I/O Pseudo-code defs Detailed specification

  10. 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 Structured Analysis: Evaluation

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

More Related