Requirements Engineering From System Goals to UML Models to Software Specifications

1. Requirements EngineeringFrom System Goals to UML Models to Software Specifications Axel Van Lamsweerde

2. Formal Methods Background • Three Components of Logic: • Syntax • Semantics • Proof Theory

3. Propositional Logic • Logical Connectors: • ^ (and) • v (or) •  (not) •  (implies) •  (equivalent to)

4. Syntax of Propositional Logic • <atomicProposition> ::= true | false | <propositionalSymbol> • <statement> ::= < atomicProposition> | (<statement>) | (<statement> ^ <statement> ) | (<statement> v <statement> ) | (<statement>  <statement> ) | (<statement>  <statement> )

5. Rules of Inference Modus Ponens: PQ,P Q Chaining: P  Q, Q R P R Resolution: PvQ, PvR Q v R

6. Propositional Logic Example • trainMoving v doorsClosed, trainStopped v trainMoving • What can be derived?

7. First-Order Predicate Logic • More expressive than propositional logic • Syntax: <term> ::= <constant> | <variable> | <functionSymbol> (<term>*) <atomicPredicate> ::= true | false | <predicateSymbol> (<term>*) <statement> ::= <atomicPredicate> | (<statement>) | (<statement> ^ <statement> ) | (<statement> v <statement> ) | (<statement>  <statement> ) | (<statement>  <statement> ) | (A<variable>)(<statement>) | (Ǝ<variable>) (<statement> )

8. Formal Methods • … will be covered in greater detail with Chapters 17 and 18.

9. Requirements EngineeringFrom System Goals to UML Models to Software Specifications Axel Van Lamsweerde

10. Chapter 5 Requirements Quality Assurance

11. Requirements QA Overview • Inspections and reviews • Queries on a requirements database • Animation-based validation • Formal verification

12. Requirements inspections and reviews • Background: During coding, reviews can be more effective than testing. • High detection rates • Quality benefits • Cost savings

13. Requirements inspections and reviews • Walkthroughs (internal only) • Inspection Planning • Determines: • size of team • members of team • timing of inspection • schedule • scope • format of reports, output.

14. Requirements inspections and reviews • Individual Reviewing • Free mode • Checklist-based • Process-based (roles, use cases) • Defect Evaluation at Review Meetings • Collect defects • Discuss • Clarify/reach consensus • Create inspection report

15. Requirements inspections and reviews • Requirements Document Consolidation • Revise document to address concerns • Observations: • Review meetings are good at reducing false positives. • Process-based is generally most effective • Different defect categories are better adapted to different review techniques

16. Requirements inspections and reviews • Inspection Guidelines • What? • Accurate, constructive, non-offensive • Who? • Not the RD authors, no conflict of interest, no direct management chain, represent stakeholder viewpoints, 3+ reviewers • Potential reviewers: domain expert, end-user, developer, QA specialist

17. Requirements inspections and reviews • Inspection Guidelines (continued) • When? • After authors are comfortable w/ RD, before design is underway/completed, shorter repeated meetings can be more productive (2 hrs) • Where? • Focus on areas with known defects or areas that have not been reviewed, focus on -ility areas (safety, security, usability) • (How comes later!)

18. Requirements inspection checklists • May be: • Defect-based • Quality specific • Domain specific • Language-based • A mix of these

19. Possible Checklist Categories: Omission Contradiction Inadequacy Unmeasurability Noise Overspecification Unfeasiblity Unintelligiblity Poor structuring Forward reference Remorse Poor modifiability Opacity What should you ask for these? Requirements inspection checklists

20. Quality-specific checklists • Specify defects into non-functional categories • Examples: • Is there any unspecified response in this operation to out-of-range values of an input variable? • Is there any recovery operation in the case of input saturation? • Are all sensory inputs used by the software controller? • In the case of error recovery by performance degradation, is the degradation predictable? • Does every state sequence from hazardous state N lead to a low-risk state?

21. Domain-specific checklists • How can we design checklists to a specific domain?

22. Language-based checklists • Is there a value for every field in this template instantiation? • Is this statement identifier used consistently? • Are multiple and/or/not clauses absolutely ordered? • Is this fit criterion defined in measureable quantities? • Is this rationale consistent among related requirements?

23. Inspections and reviews conclusion • Pros: • Can be even more effective than code inspection (quality and impact of defects found) • Wide scope • Easily adaptable • Blend of checklist techniques effective • Cons: • Large amount of material • Time investment • Time to tailor technique

24. Queries on a requirements database • Works well for large specifications • Follows schema • Quick consistency and completeness checks • Checklist integration • Easy queries

25. Queries on a requirements database • Validation with a requirements database: • Validation scenarios (use cases) • Simulation (model execution) vs. Animation (visualization)

26. Queries on a requirements database • Simulation Events: • Triggered (E) • Enabled (T, CS) • Permitted (T, CS) • Consistent (T) • EvGemerated (T) • newConfig (T, CS) • Where: • E - event • T - transition • CS - configuration

27. Queries on a requirements database • Automations/Visualizations • Textual – input events entered via command line, model reactions are displayed in text • Diagrammatic – follows transitions along a model diagram • Domain-Specific Visualizations – scene of software environment

28. Queries on a requirements database • Conclusions • Pros: • May provide insight into subtle defects • Can provide visualization for stakeholders • Provides free acceptance test • Easier traceability • Cons: • Requires formal specification • Time-consuming • Translation problem

29. Requirements verification through formal checks • Similar to compiler checks • Types of checks: • Syntax • Type • Static Semantics • Circularity, etc. • Model checking vs. rules of inference/candidate theorem validation

30. Example The Personal Time Tracking System (PTTS) will be used by faculty members at the University of Kentucky to assist them in managing and monitoring their daily schedules. The system will allow faculty members to register recurring and non-recurring tasks as Part of their configuration data, and to record time entries against those tasks. Time entries associated with non-recurring tasks will be entered manually; time entries associated with recurring tasks will be generated automatically. The system will allow faculty members to monitor their schedules using a variety of reports. The Chair of each department will have access to each faculty members’ configuration data, and will be allowed to enter additional tasks. The system will allow the Chair to associate constraints with each of these tasks, requiring faculty members to enter a minimum number of hours per task period. The system will also allow the Chair to monitor faculty member schedules using a variety of reports. This will be a web-based application. [Class Activity: Perform PBR on this document with class divided into roles of tester/coder, usability expert/security expert, faculty/dept. chair, etc.] Source: http://www.cs.clemson.edu/~jasonoh/courses/CpSc372_Spring_05/course_handouts/Assignment%20%231.doc Clemson University (CPSC372: Jason Halstrom)