1. Intent Specification Intent Specification is used in SpecTRM http://www.safeware-eng.com/index.php/products

2. Intent Specification and SpecTRM SpecTRM  Tool that can use Intent Specification Specification Tools Requirements Methodology  Made for use with development of safety-critical software  Made by Safeware Engineering SpecTRM-RL  Another method that can be used in SpecTRM 2

3. Key benefits 1 Finding errors early in development  Fix with lowest cost and impact on system design Tracing requirements and design rationale throughout system construction and documentation  Safety constraints 3

4. Key benefits 2 Building required system properties into the design from the beginning Building bridges between specialists  System engineering  Software engineering  Safety engineering 4

5. Why Intent Specification? 1 Normal specification are structured in levels of what and how  This helps to cope with complexity Unanswered question  Why? Why are decisions made?  Why did we do it that way…?  Why can’t it do …? Important with changing requirements 5

6. Why Intent Specification? 2 Software-related accidents mostly come from problems with requirements A good specification needs to be organized, readable and reviewable Improved set of practices for writing specifications Can be tailored for needs of the project 6

7. Structure of Intent Specification Nancy Leveson 7

8. Levels and decomposition Level 0: Program Management Information Level 1: System-Level Goals, Requirements, and Constraints Level 2: System Design Principles Level 3: Blackbox Behavior Level 4: Physical and Logical Design Level 5: Physical Implementation Level 6: System Operations Environment Operator System and components Verification and Validation 8

9. The Levels Each level is a complete view of the system Each level is expressed in a different way that motivates the level below Not necessary to complete one level before starting on the next Within a level all aspects of the system are addressed 9

10. Traceability Link down from higher level shows how something been executed Link up from code show why it was made in this way Links between parts at same level that affect each other Example:  Each hazard would link to safety design constraints within the same level  Each safety constraints would link down from level one to level two where decisions comply with safety constraints 10

11. Level 0: Program Management Information Project and safety plans that will guide development of the system Program Management Plans  Project overview  Budgeting  List over personnel and responsibilities System Safety Plan  Describes safety objectives and how they will be achieved  Plans for subsystem safety 11

12. Level 1: System-Level Goals, Requirements, and Constraints 1 Introduction of system being built Historical information  Historical background or precedent  Puts the system in context Environment  Systems are not independent Description  Illustrative examples of where, when and under what circumstances the system will be used 12

13. Level 1: System-Level Goals, Requirements, and Constraints 2 Assumptions  System relies upon for safe operation  Wrong assumptions may lead to accidents Constraints  Assumptions needs to be true System goals  Reason the system is being built 13

14. Level 1: System-Level Goals, Requirements, and Constraints 3 High-Level Requirements  What is the system to do System Limitations  Requirements that cannot be implemented Operator Requirements Hazard Analysis  Assumptions, requirements and constraints for the operator 14

15. Level 1: System-Level Goals, Requirements, and Constraints 4 Hazard Analysis  Generate hazard list and log Hazard List and Assessment  All known hazard for system  More can be found during development and added Design and Safety Constraints  Constraints document things that the system should not do  Limits space of possible design for the system 15

16. Level 1: System-Level Goals, Requirements, and Constraints 5 Non-Safety Constraints Safety constraints  Motivated by safety concerns Verification and Validation  Plans and procedures for reviewing the requirements 16

17. Level 2: System Design Principles Answers why for subcomponent requirements at level 3 System Design Principles  Record design decisions that meet requirements and enforce constraints of level 1 Operator Task Design Principles  Responsibilities for operators Verification and Validation  Information about the validation of the design principles for this level 17

18. Level 3: Blackbox Behavior Describes only the requirements for the behavior of the components as seen from the outside System Blackbox Behavior  Model of subcomponent behavior User Model  User behavior  Find parts of the system that might match poorly with human capability Verification and Validation  Ensures that components will operate in ways that satisfy system-level requirements and design decisions 18

19. Level 4: Physical and Logical Design 1 Describes the physical and logical designs of each subcomponent Contain design specification for subcomponent or reference to design specification  Hardware Design Specifications  Software Design Specifications Physical Interface Design  Describe human factors 19

20. Level 4: Physical and Logical Design 2 Training Plan  Describe how to train operators Operations Plan  Describe how to use the system is to be operated Verification and Validation  Design walkthroughs and results 20

21. Level 5: Physical Implementation 1 Either information of the physical implementation of the system or references to where such information are Software sourcecode Hardware Schematics Hardware Assembly and Installation Instruction 21

22. Level 5: Physical Implementation 2 Operator Training Manuals  Instructions for use  Traceability to ensure hazard mitigation Operator (User) Manuals  As Operator Training Manuals Verification and Validation  Test plans and results  Special plans for test safety-critical behavior 22

23. Level 6: System Operations Learn from operational history of system  Pattern of accidents Track of a system’s operational performance Predict future problems For next version or product 23

24. Use in buisness-crtical systems? 1 Can reduce/drop what intent specification says about  Safety  Hazards Easier to change SW without unforeseen errors  Know why a decision was made  Know what test or simulation needs do be redone and what do not need to be redone Easier to avoid design errors 24

25. Use in buisness-crtical systems? 2 Possible to reuse parts of documentation for another project? Can be used with any programming language Can be used with other methods for developing software?  UML, RUP and XP 25

26. Finished, questions?