Some future trends in requirements engineering

1. Some future trends in requirements engineering Colin Potts Georgia Tech

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

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

4. Domain modeling: Evaluation • Little experience • Several DARPA evaluation projects (C3I, etc.) • 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

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

6. Model-oriented formal specifications • 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 • Behavior is specified in operations • Preconditions and postconditions for each operation • Languages • Z, VDM, Fusion (OOA) method

7. 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 Admissibility Admissible states Conceivable states

8. 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 Model-based specification of behavior illegal operation Permitted operation

9. Simple Z example schema Container contents: Nat capacity: Nat contents < capacity declarations predicate/ invariant

10. Z operation schema precondition Fill changes Container amount? : Nat contents + amount? < capacity contents' = contents + amount? postcondition

11. Class exercise: Z modifications • 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?

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