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 Made for use with development of safety-critical

software Made by Safeware Engineering

SpecTRM-RL Another method that can be used in SpecTRM

2

Key benefits 1

Finding errors early in developmentFix with lowest cost and impact on system

design Tracing requirements and design rationale

throughout system construction and documentationSafety constraints

3

Key benefits 2

Building required system properties into the design from the beginning

Building bridges between specialistsSystem engineeringSoftware engineeringSafety engineering

4

Why Intent Specification? 1

Normal specification are structured in levels of what and howThis helps to cope with complexity

Unanswered questionWhy?

Why are decisions made? Why did we do it that way…? Why can’t it do …?

Important with changing requirements

5

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

Structure of Intent Specification

Nancy Leveson

7

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

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

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

otherExample:

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

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

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

Level 1: System-Level Goals, Requirements, and Constraints 2 Assumptions

System relies upon for safe operationWrong assumptions may lead to accidents

Constraints Assumptions needs to be true

System goalsReason the system is being built

13

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

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

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

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

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

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

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 ValidationDesign walkthroughs and results

20

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

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

Level 6: System Operations

Learn from operational history of systemPattern of accidents

Track of a system’s operational performance

Predict future problems For next version or product

23

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

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

Finished, questions?Finished, questions?