1 / 12

Some future trends in requirements engineering

Explore the future trends in requirements engineering focusing on domain modeling and formal specification. Learn how to use domain modeling to specify systems by customizing templates and prove properties of the specification for quality assurance. Discover the importance of formal specification in guaranteeing quality and mitigating critical system failures. Dive deep into model-based and formal specifications, including their advantages and limitations. Gain insights on system states, admissibility, and modeling system behavior through state-changing operations. Delve into examples and exercises using Z schema for formal specification.

joan-nelson
Télécharger la présentation

Some future trends in requirements engineering

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. 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

More Related