1 / 26

Intent Specification

Intent Specification. Intent Specification is used in SpecTRM http://www.safeware-eng.com/index.php/products. Intent Specification and SpecTRM. SpecTRM Tool that can use Intent Specification Specification Tools Requirements Methodology

fchampagne
Download Presentation

Intent Specification

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. 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 • SpecificationTools 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 • Safetyconstraints 3

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

  5. Why Intent Specification? 1 • Normal specification are structured in levels of what and how • This helps to cope with complexity • Unansweredquestion • 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. Nancy Leveson Structure of Intent Specification 7

  8. Level 0: Program ManagementInformation Level 1: System-Level Goals, Requirements, and Constraints Level 2: System Design Principles Level 3: BlackboxBehavior Level 4: Physical and Logical Design Level 5: Physical Implementation Level 6: System Operations Environment Operator System and components Verification and Validation Levels and decomposition 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 ManagementInformation • 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 • Introductionof system being built • Historicalinformation • 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-LevelRequirements • 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 • HazardAnalysis • Generate hazard list and log • Hazard List and Assessment • All known hazard for system • More can be found during development and added • Design and SafetyConstraints • 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-SafetyConstraints • Safety constraints • Motivated by safetyconcerns • 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: BlackboxBehavior Describes only the requirements for the behavior of the components as seen from the outside • System Blackbox Behavior • Modelof subcomponent behavior • UserModel • Userbehavior • 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 • PhysicalInterface 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 • Softwaresourcecode • 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?

More Related