intent specification intent specification is used in spectrm
TRANSCRIPT
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
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