Model-Based Requirements Engineering with Auto-RAID

1. Model-Based Requirements Engineering with Auto-RAID Bernhard Schätz Technische Universität München Institut für Informatik 08.03.2005 - ReConf 2005

2. Best Practices Best Requirements Practices for System Software: • Formal Requirements • Requirements Inspection • Requirements Tracing • Performance Requirements • Quality/Reliability Requirements • Requirements Notations • Requirements Segmentation • Function Point Measurement • Defect tracking Source: Jones, 2000, Software Assessments, Benchmarks and Best Practices Adding Detailed Structure to Requirements Schätz - AutoRAID

3. Describing Embedded Systems Schätz - AutoRAID

4. Quality Criteria Quality criteria for system specifications (IEEE 830-1998): • Changeability • Traceability • Comprehensibility • Consistency • Completeness • Unambiguity Schätz - AutoRAID

5. Modeling Requirements Weak-Structure Model: “Built-In” Flexibility + Facilitates comprehensability, changeability - Enables ambiguities, inconsistencies - Restricts completeness, feasibility Schätz - AutoRAID

6. Modeling Designs Structured Model: “Built-In” Preciseness + Restricts ambiguities, inconsistencies + Supports completeness, feasibility - Restricts comprehensability, changeability Schätz - AutoRAID

7. Structured Information Precision Flexibility Precision Flexibility Analysis Design Schätz - AutoRAID

8. Mechanic Analytic Constructive Manual Structuring ImpactAnalysis View Generation Modeling Tracing/ImpactAnalysis Analysis Review Quality Assurance Mechanisms Precision Flexibility Analysis Design Schätz - AutoRAID

9. ImpactAnalysis Structuring View Generation Modeling Tracing/ ImpactAnalysis Analysis Review Improving Quality and Efficiency Precision Flexibility View Construction Classification Refinement Analysis Analysis Design Schätz - AutoRAID

10. User-Support Efficient and quality-oriented transition from analysis to design: • Based on activities as performed in a review • Focusing on constructive activities • Supporting each activity by tool-interaction Requires a deep integration of models for analysis and design Schätz - AutoRAID

11. Weak Integration: Unstructured Requirements Model Elements • Generic Requirements • Domain-Specific Design Weak Integration: • Hierarchic Requirement Model • View-Based Design Model • Generic Links Generic Requirement Structure • Description • Title, ID • Rationale • Priority, Status Schätz - AutoRAID

12. Weak Integration: Homogeneous Links Schätz - AutoRAID

13. Weak Integration: Identify Requirements Schätz - AutoRAID

14. Weak Integration: Refine Requirements Schätz - AutoRAID

15. Weak Integration: Link Models Schätz - AutoRAID

16. Weak Integration: Support Support mechanisms: • Management: Import, Refinement, Linking • Analysis: Coverage/Completeness (Refinement, Linking) • Synthesis: Documentation Schätz - AutoRAID

17. Deep Integration: Embedding Specific Requirements Model Elements • Domain-specific requirements • Domain-specific views Deep Integration: • View-based requirements • View-based design model • Homogeneous requirements/design model Requirements as an additional view: • Requirements as structured text • Requirements as domain-specific structure • Requirements as collection of model views Schätz - AutoRAID

18. 3. Specific requirements 3. Specific requirements 3.1 External interface requirements 3.1.1 User interfaces 3.1 External interface requirements 3.1.2 Hardware interfaces 3. Specific requirements 3.1.1 User interfaces 3.1.3 Software interfaces 3.1.4 Communications interfaces 3.1.2 Hardware interfaces 3.1 External interface requirements 3.1.3 Software interfaces 3.2 Functional requirements 3.1.4 Communications interfaces 3.1.1 User interfaces 3.2.1 Mode 1 3.1.2 Hardware interfaces 3.2.1.1 Functional requirement 1.1 3.2 System features 3.1.3 Software interfaces . 3.1.4 Communications interfaces 3.2.1 System Feature 1 . 3.2.1.1 Introduction/Purpose of feature . 3.2 Functional requirements 3.2.1.2 Stimulus/Response sequence 3.2.1. n Functional requirement 1. n 3.2.1.3 Associated functional requirements 3.2.1 Information flows 3.2.2 Mode 2 3.2.1.3.1 Functional requirement 1 3.2.1.1 Data flow diagram 1 . . 3.2.1.1.1 Data entities . . 3.2.1.1.2 Pertinent processes . . 3.2.1.1.3 Topology 3.3 Performance requirements 3.2.1.3. n Functional requirement n . 3.4 Design constraints 3.2.2 System feature 2 . 3.5 Software system attributes . . 3.6 Other requirements . 3.2.2 Process descriptions . 3.2.2.1 Process 1 3.3 Performance requirements 3.2.2.1.1 Input data entities 3.2.2.1.2 Algorithm or formula of process 3.4 Design constraints 3.2.2.1.3 Affected data entities 3.5 Software system attributes . 3.6 Other requirements . . Deep Integration: Structuring Information Quelle: IEEE Standard 1998-830 Schätz - AutoRAID

19. Deep Integration: Embedded Requirements Schätz - AutoRAID

20. Deep Integration: Classify Constraint Schätz - AutoRAID

21. Deep Integration: Motivate Models Schätz - AutoRAID

22. Deep Integration: Construct Model Views Schätz - AutoRAID

23. Deep Integration: Support Support Mechanisms: • Management: Review-based View Generation, Multiple Views • Analysis: Consistency/Completeness (Refinement, Motivation) • Synthesis: View Generation (Motivation, Construction) Schätz - AutoRAID

24. User-Support Deep Integration of Analysis and Design: • Smooth: Based on activities as already performed, e.g., in a review • Quality-oriented: Focusing on constructive, enabling analytic activities • Efficient: Supporting each activity by convenient tool-interaction Schätz - AutoRAID

25. AutoRAID: Partners and Contact Contact: www4.in.tum.de/~autoraid Schätz - AutoRAID