Requirements Analysis for Special Properties

1. Requirements Analysis for Special Properties • Systems Engineering (def?) • why? • increasing complexity • ICBM’s (then TMI, Therac, Challenger...) • how? • create system architecture • first job: analyze and modify requirements! • criteria for its evaluation • tradeoffs involving subsystems CSC 402, Fall 2000

2. Components of Systems • Safety (and other properties) “emergent” • the system is more than the sum of its parts • “synergy” a real concept? • complexity shows up at the interfaces • what does “divide and conquer” really accomplish? complex interfaces, simple modules simple interfaces, complex modules CSC 402, Fall 2000

3. Software and Systems Engineering • Software as “component” • embedded systems - software “control” Uncontrolled Variables Controlled Process Inputs Outputs Sensors controlled vars Actuators manipulated vars Software Controller CSC 402, Fall 2000

4. Human as “Component” • human “control” - software “decision support” • consider the system properties like “safety” • medical expert systems • or even patient databases • pilot interface to commercial airliner • at system level: • what is known about the components • how can we reduce risks • relative to component parameters we can control CSC 402, Fall 2000

5. Safety Analysis • Safety as system property • software not “safe” or “unsafe” by itself • safety relative to reliability? • what do we know about software reliability? • very, very little! • Parnas, Hamlet write about this extensively CSC 402, Fall 2000

6. Steps in Safety Analysis Definition and Description of System System Changes Hazard Identification Accident Modeling Quantification of Risks Documentation of Results CSC 402, Fall 2000

7. Feedforward control aspects • plans ahead to avoid and mitigate • Feedback control aspects • uses accident information, when available • when system not entirely novel CSC 402, Fall 2000

8. Lots of Methods • FMEA - failure modes effects analysis • based on failure modes of each significant system component • AEA - action error analysis • human actions and failures are analyzed with respect to the system • ETA - event tree analysis • postulate hazardous event, determine system responses • FTA - fault tree analysis • postulate hazardous event, determine possible causes • CCA - cause consequence analysis • combine ETA and FTA • HAZOP - hazard and operability study • guide words (checklist approach) of “deviation analysis” - more of, less of, none, other • WSA - work safety analysis • investigate working methods, machines and environment CSC 402, Fall 2000

9. State Space Search Strategies • Forward analysis • based on system structure • propogate failure of system elements forward • Backward analysis • based on system structure • propogate backwards from postulated accidents • Morphological analysis • concentrate on hazardous factors and potential targets CSC 402, Fall 2000

10. Goals of the Search CSC 402, Fall 2000

11. Applicability to Software? • FTA: Leveson, Cha, 1991 • Hazop: (Deviation Analysis) Reese, 1996 • Others? (Want a Master’s Thesis topic???) CSC 402, Fall 2000

12. Fault Tree Analysis • Basic steps: • postulate accident or undesired system output • root of tree • determine necessary preconditions • draw as leaves with appropriate logical connectors • add probabilities if known CSC 402, Fall 2000

13. Why Software FTA? • Benefits: • Combats software state space explosion • backwards technique reduces search space • only the events of interest are considered • Partial verification technique • useful at many levels of abstraction • including requirements • can be viewed as a structured walkthrough • with the power of the included logic CSC 402, Fall 2000

14. Learning and communication • human interpretation of models is informative • Automatable • there are some tools to draw and analyze CSC 402, Fall 2000

15. Risky State Logical Connector and/or logical connector necessary precondx necessary precondx necessary precondx necessary precondx Recurse to leaves CSC 402, Fall 2000

16. Comments • Leveson, Cha paper: • work from system spec to software spec • work from software spec down to code • to individual software constructs • based on safety-critical variable values • must know static program dependencies to take path • must also know how values may change • could be done like symbolic execution - path expressions CSC 402, Fall 2000

17. Necessary Preconditions for FTA • Need to know precisely: • necessary preconditions to get to any system state • probabilities for those conditions • is this possible for software? • fault tree value if it is not possible? CSC 402, Fall 2000

18. Specification Support for FTA • Basic support • precise and measurable requirements • analysis models that exhibit system behavior • Full support • formal specifications • state charts have been used as a basis for software FTA CSC 402, Fall 2000

19. Classify the Technique? • Static or Dynamic • execution as conceptual (walkthrough) • execution of “model” separate from product • Redundancy in Requirements Analysis • what are the tradeoffs? • is this really a multi language approach to requirements and specification? CSC 402, Fall 2000