Model-Based Requirements Engineering with Auto-RAID

1. Model-Based Requirements Engineering with Auto-RAID Andreas Fleischmann, Eva Geisberger, Bernhard Schätz Technische Universität München Institut für Informatik 22.09.2005 - QUAM - Informatik 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. Modeling Requirements Weak-Structure Model: “Built-In” Flexibility + Facilitates comprehensability, changeability - Enables ambiguities, inconsistencies - Restricts completeness, feasibility Schätz - AutoRAID

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

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

6. Weak Integration: Unstructured Requirements Schätz - AutoRAID

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

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

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

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

11. Structuring Mechanic Analytic ImpactAnalysis Constructive Manual Tracing Impact Analysis Simulink/ Stateflow DOORS Weak Integration: Quality Assurance Mechanisms Schätz - AutoRAID

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

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

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

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

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

17. Mechanic Analytic Constructive Manual Modeling View Generation TDF DOORS Review Simulink/ Stateflow ASCET-SD Deep Integration: Quality Assurance Mechanisms Structuring ImpactAnalysis Tracing Impact Analysis Schätz - AutoRAID

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

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