© Colin Potts C6-1 Some future trends in requirements engineering Colin Potts Georgia Tech

© Colin Potts C6-2 Domain modeling & formal specs. l Domain modeling »Model a generic system or system template, not a specific system »Specify new systems by customizing the template l Formal specification »Use mathematically formal language to specify parts of a system »Prove properties of the specification to guarantee quality

© Colin Potts C6-3 Domain modeling l Use any engineering technique to specify a generic system »Typically use OOA, because it supports generalization directly l When specifying a system, refine the template »i.e. instantiate, specialize or modify

© Colin Potts C6-4 Domain modeling: Evaluation l Little experience »Several DARPA evaluation projects (C3I, etc.) l Domain modeling in practice has been confused with reuse of OO code »because domain modeling is a kind of reuse of analysis model fragments »and OO representations lend themselves to more abstract descriptions

© Colin Potts C6-5 Formal requirements specification l Mathematically rigorous specification »Rationale: critical systems failures will eventually lead to enforcement of engineering stds. l Several flavors of formal specification »Model-based specification is the most likely to achieve practical value »cf. Information modeling with richer constraints

© Colin Potts C6-6 Model-oriented formal specifications l Extension of ER modeling »ER diagrams are like type and function declarations »Cardinality constraints are logical rules »Other rules that cannot be shown in an ER diagram can be specified l Behavior is specified in operations »Preconditions and postconditions for each operation l Languages »Z, VDM, Fusion (OOA) method

© Colin Potts C6-7 Admissibility System states are legal configurations of attribute/relationship values What are the rules that specify these legal states? »And only these states »Need to specify these succinctly –Not as a transition diagram Conceivable states Admissible states

© Colin Potts C6-8 Model-based specification of behavior System behavior is modeled as a collection of state-changing operations »The preconditions of an operation state when it can occur –Not when it is triggered »Postconditions define the effects Permitted operation illegal operation

© Colin Potts C6-9 Simple Z example Container contents: Nat capacity: Nat contents < capacity schema declarations predicate/ invariant

© Colin Potts C6-10 Z operation schema Fill changes Container amount? : Nat contents + amount? < capacity contents' = contents + amount? precondition postcondition

© Colin Potts C6-11 Class exercise: Z modifications l As a class »Specify a new operation –Write the operation schema for dispense, an operation that dispenses fluid from the container »Add a new rule –Let the container have a warning light that goes on when the container becomes more than 80% full »What kinds of proof obligations arise in the two cases? »How does using model-based specification clarify your understanding of the (very trivial) problem domain?

© Colin Potts C6-12 Formal specification: evaluation l Maturity »Encouraging experiences in industrial projects, incl. –IBM (CICS) –Tektronix (oscilloscope embedded software) –Inmos (transputer FP microcode) l Advantages »Precision helps understand reqts and design implications l Limitations »Requires retraining (but not advanced math) l Trend »Increasing investment with need for dependable software & accountability for effects