Transcript The Role of Formality in Requirements

The Role of Formality in
Requirements
Martyn Thomas
What are requirements?
1 The regulator’s view of how they would like the world to be?
The reactor shall shut down safely if there is a problem.
2 The operator’s view of what they want a system to do? I want a
system that monitors temperature and pressure in the reactor
and shuts the system down if either exceeds specified levels for
more than a specified time.
3 The engineer’s view of how they want the system to behave? If
the voltage on line A exceeds 7.2V or ….
All the above?
What if they are inconsistent?
What do we mean by requirements?
Computer
system
Application
Domain
Engineer’s view
See: Problem Frames. M.A.Jackson 2001
User worlds
Regulator’s view and
operator’s view
What do we mean by requirements?
We want
something
to happen
in here ...
When something happens
in here...
Computer
system
Application
Domain
(formal)
(formalisable)
Engineer’s view
That will make
something
good happen
in here ...
User worlds
(informal)
Regulator’s view and
operator’s view
Characteristics of requirements
• Context dependent
– terms and processes can only be understood fully by people who really
understand the application domain. “But everyone knows that X means
X (1) … X(n)”
• ambiguous
• incomplete
– hundreds of unstated knowns and unrecognised unknowns
• inconsistent
– people have genuinely conflicting needs: both different needs of the
same person and the needs of different people
• likely to change during development
– the world changes, or ideas change, or errors and omissions are detected
• likely to change in service
– as above
Requirements Engineering
The purpose of RE is to bridge the gap between the (informal)
users’ needs and the design of a (formal) computer system.
• Resolve ambiguities
• Detect incompleteness and inconsistency
• Remove the need for domain expertise
• Enable system properties to be revealed and explored early
• Provide a clear starting point for architectural and high-level
design, with minimal risk of unnecessary change
• Support change whilst maintaining intellectual control
If requirements are going to change,
why bother to try to get a complete
and accurate statement of them?
• To get the clearest view of costs and timescales
• To allow a large task to be broken down into sub-tasks with
agreed interfaces
• To maximise the probability that architectural design and high
level design will be appropriate for the final system
• To reduce the number of inconsistencies and omissions that may
cause rework when discovered later
• To allow cost-benefit trade-offs
• To allow change-control, so that the project can end
• To allow impact analyses of proposed changes
Formal Methods
By Formal Methods I mean notations that allow some aspect of the
requirements to be expressed abstractly and unambiguously,
together with the tools for manipulating these notations and the
human processes for using them in RE.
Examples are:
• Z
• Finite State Machines
• CSP
• Rely/Guarantee conditions (C.B.Jones)
Abstraction
• The two most important characteristics of a specification
notation are (1) that it should permit problem-oriented
abstractions to be expressed …
• “In this connection it might be worthwhile to point out
that the purpose of abstracting is not to be vague, but
to create a new semantic level in which one can be
absolutely precise”. Dijkstra 1972
• … and (2) that it should have rigorous semantics so that
specifications can be analysed for anomalies and to explore
system properties.
Realism in specification
• “we [must] confine ourselves to the design and
implementation of intellectually manageable programs. … If
someone fears that this restriction is so severe that we
cannot live with it, I can reassure him: the class of
intellectually manageable programs is still sufficiently rich
to contain many very realistic programs for any problem
capable of algorithmic solution.” Dijkstra 1972
• Methods such as VDM and Z support problem-oriented abstractions and
hugely extend the range of systems that are intellectually manageable.
The role of FMs in RE
• Succinct yet precise expression of requirements
• Reduction of ambiguity and incompleteness and detection of
inconsistency
• Better communication between requirements engineers and
designers
• Moving into the formal world whilst the system specification is
still concise and abstract enough to be comprehensible
– formalisation is unavoidable, but usually it is done at the coding stage
where none of the benefits are available
• Providing a basis for system verification
… an aside about
Extreme Programming
Requirements and XP (1)
• eXtreme Programming is the latest manifestation of the Rapid
Development and Agile movements of the 1980s and 1990s.
• It was developed by Kent Beck, “to see what happened if you
took a few principles that seemed to work well and took them to
extremes” personal communication. NAS/CSTB DepCert workshop, 2004.
• The XP principles affecting requirements are:
– Planning Game (no long-term strategies; use cases; estimate next release,
welcome late changes)
– Metaphors to describe the system
– Tests define the specification
– On-site customer to answer questions about the specification
– No written documentation outside the code
Requirements and XP (2)
•
•
•
•
Metaphors are a form of abstraction
Use cases are an incomplete form of specification
Tests are a very incomplete form of specification
Late changes are expensive, unnecessary late changes are
wasteful
• One customer, answering questions in real time, is unlikely to
make consistent and correct decisions about the whole system
• The source code is an inefficient place to document system level
requirements, architectures or design decisions.
So XP carries the risks of:
• unnecessary change: even failure to converge on a specification
• poor architectural decisions that cannot be “refactored” costeffectively
• weak basis for system verification (only testing)
• no basis for arguing high dependability (Kent Beck agrees)
• steep learning curve for new staff and long-term maintenance
• Problems scaling up to large systems (Stephens and Rosenberg
report that C3, the first large scale system to use XP - with Kent
Beck as a project manager - slipped, overran, and was
eventually cancelled)
… end of aside
A practical approach to FMs
• When you write something down, be as precise as you can
• Using several formal notations for different system aspects or
properties is unlikely to cause any problems - so choose the
appropriate tool from your tool-bag.
• Use XP/agile methods to capture requirements, but record the
results formally. The formal spec is for engineers - present it
informally to users for validation, and accept responsibility for
any translation errors. (That’s what architects do, for example)
• Carry as much formality into the design and coding as possible,
to strengthen verification.
A First Case Study: CDIS
• This project was started in the late 1980s. The software is still in
use at LTCC West Drayton, the ATC Control Centre for all the
London airports.
Civil Aviation Authority - CDIS
Central Control Function Display Information System
New generation integrated air traffic display system
Real-time information: Weather, Flight Information, Flight Sequencing, Landing Information
Non-stop safety related
Prime contractor: Praxis
£10m systems integration project
Competitive design - Praxis, Logica, EDS
95 PS/2s, Stratus mainframe, 200,000 lines of code
Civil Aviation Authority - CDIS
Central Control Function Display Information System
1.5 million flights per annum
‘Tunnel’ routing
London
Terminal
Manoeuvring
Area (five airports)
Military and civil flights
London
Area Terminal
Control Centre
The most reliable system CAA have ever procured
Most reliable system
DTI ‘SMARTIE Project’ review
CAA
CDIS overview
Central Control Function Display Information System
Systems integration
DTI ‘SMARTIE Project’ review
Stratus fault tolerant platform
Dualled token ring
95 PS2 OS/2 ATCO stations
X25, token ring and serial I/O
Stratus mainframe
City University Centre for Software Reliability
200,000 lines of code
816 person months
33 elapsed months
0.75 faults per KLOV (Vs survey average of 8.2)
Zero critical faults
Formal methods
VDM core specification
Yourdon concurrency spec.
CCS Network model
English and graphics user I/F spec.
Software support requires 2 staff
10 year warranty on critical faults
A model of what can be achieved
...has integrated with our systems more easily than any other system
A Second Case Study
This is a case study reported by the US National Securities Agency
last year.
The slides have been officially released by the NSA to the National
Academy of Sciences, and are therefore available.
The study was an evaluation of the Correct by Construction
(including SPARK) development methods used by Praxis High
Integrity Systems Ltd.
Praxis is a company that I founded, but with which I have no
commercial links.
SPARK
• SPARK is a subset of the Ada 95 language that contains only
language features that can be analysed statically (i.e. without
running the program).
• The SPARK EXAMINER guarantees freedom from run-time
exceptions (arithmetic overflow, array-bound errors etc).
• The SPARK language permits annotations: these are
syntactically Ada comments but contain formal specifications of
the program state. The EXAMINER generates the proof
conditions for these, and discharges the great majority
automatically.
See High Integrity Software John Barnes 2003
The Path to Security Assurance
Randolph Johnson
National Security Agency
[email protected]
The Path to Security Assurance
•
•
•
•
•
•
•
TOKENEER Identification Station
Common Criteria
Correct by Construction Process
Praxis Results
Student Experience
Lessons Learned
What is next?
Tokeneer Identification Station
background
• Sponsored and evaluated by Research teams token & biometric
and HCSS
• Developed by Praxis Critical Systems
• Tested independently by SPRE Inc., N.M.
• Adapted and extended by student interns
TOKENEER ID Station
Protected
Enclave
Alarm
TIS
Admin
Portal
Display
Token
Reader
Fingerprint
Reader
TIS System View
Certificate
Library
Alarm
simulator
Alarm
Interface
Crypto
Library
Admin
Interface
TIS Core
Functions
Portal
Latch
Interface
Portal
simulator
TIS
Biometric
Subsystem
Display
Interface
Protected
Enclave
Display
simulator
KEY:
Simulated
Device
Software
subsystem
TIS Core
developed
to EAL5
User interaction
Token
Reader
Interface
Token
Reader
simulator
Fingerprint
Reader
simulator
Guard/
Administrator
interaction
Common Criteria
• International standard for secure system development and
evaluation
• Six original countries, now 12+
• ISO/IEC 15408
• Seven Evaluation Assurance Levels
• EAL4 “best commercial practice”
OVERVIEWCorrect by Construction (C by C) Process
• A software engineering process employing good practices and languages
– SPARK (Ada 95 subset with annotations)
– math based formalisms (Z) at early stages for verification of partial correctness.
• A supporting commercial toolset (Z/Eves, Examiner, Simplifier, Proof
Checker) for specifying, designing, verifying/analyzing, developing safety or
security critical software.
C by C S/W ENGINEERING
PROCESS
• Seven Software Engineering Steps to High Assurance Security Software
–
–
–
–
–
–
–
Requirements Analysis
Security Analysis
Specification
Design
Implementation
System Test
Assurance
The Development Approach
• Requirements Analysis Step (REVEAL approach)
– Identify system boundaries
– Clarify dependencies on environment
• Security Analysis
– Develop Security Target & Security Policy Model (CC) using Protection Profile
– Identify key properties to ensure security
– Validating functional spec with security properties
• Specification
– Define and document customer requirements in Z and English with customer feedback
7 Step Process (continued)
• Design (w/ (semi)formal documents)
– Refined functional spec (written in Z)
– INFORMED design document
• Details data store and flow, dependencies of modules (SPARK packages),
etc.
• Links design statements to implementation modules-straightforward and tool
supported
– Provides baseline orthogonal documents for developers and testers– functional
specs(Z), design docs (Z for behavior and environment dependencies), test specs
Development Approach (continued)
• Implementation
– Coding in SPARK Ada with static analyzer (EXAMINER)
• prevents uninitialized variables, buffer overflows, incorrect info flows
• System test
– Incremental builds with increasing functionality
– Specification based testing done by SPRE
• 100% statement coverage tests
• 100% branch coverage tests
Process Summary
Assurance Analysis
• Assurance Analysis on Security Properties
–
–
–
–
–
Formal Z spec
Refinement proof of formal design from formal spec
Static analysis
Proof of functional properties (SPARK proof)
System test
Assurance Process
Security
Properties
Formal
Specification
Proof of Security
Properties
(Z)
Proof of Security
Properties
(SPARK Proof)
Formal Design
INFORMED
Design
Proof of Formal
Specification
(Z)
Refinement Proof
of Formal Design
(Z)
Proof of
Functional
Properties
(SPARK Proof)
System Test
Specification
System Test
Key
Assurance
Activity
SPARK
Implementation
Static Analysis
Statistics of System
Ada Source
Lines
Spark
annotations
LOC/day
Core
9,939
16,564
38
Support
3,697
2,240
88
Additional metrics
•
•
•
•
•
Total effort 260 man days
Total cost – $250k
Total schedule – 9 months
Team – 3 people part-time
Testing criterion – 99.99% reliability with 90% degree of
confidence
• Total critical failures – 0 [Yes, zero!]
Guiding Principles
•
•
•
•
•
•
•
Write right
Step, don’t leap
Say something once
Check here before going there
Argue your corner
Use the right tools for the job
Use your brains
Phase Two - Beginners
• Two undergraduate students studying mathematics & computer
science
+ one computer science graduate student
• 10-12 weeks
• No previous Z
• One had prior exposure to SPARK
Task - Adapt & Extend the System
• Adapt the Praxis code to run in the real demo system (change
Ada & SPARK code with help from SPRE)
• Add new functionality (use entire methodology to add keypad
device and required password)
Support Given
• Training
–
–
–
–
3-4 days on reading and writing Z using Z/Eves
3 days on TOKENEER ID Station
1 day on Ada
4-5 days on SPARK & tools
• Z & SPARK textbooks & manuals
• Email support on SPARK from Praxis
Results Achieved
• Added new functionality to
–
–
–
–
requirements document
functional specification in Z
design document in Z
SPARK code and annotations
• Ran SPARK tools (Examiner & Simplifier)
• Created SparkPlug Eclipse plugin for SPARK tools
WHY use Correct by Construction
S/W Engineering ?
• Meets Common Criteria and ITSEC security requirements for
EAL5 +
• Produces code more quickly and reliably and at lower cost than
traditional methods
• Is commercially supported (ORA Canada, Praxis HIS, Pyrrhus
Software, SPRE Inc.)
• Reasonable learning curve
• C by C is proven and practical
End of Case study
… and of Randolph Johnson’s slides
Conclusions
• Formal methods provide a set of tools that the professional
requirements engineer can use to make requirements
specifications much more precise, and to analyse them for
omissions and inconsistencies.
• Formal specifications largely eliminate misunderstandings
between software engineers.
• Formal specifications are an extremely cost-effective way of
reducing errors and waste.
• Using formality, wherever practical, makes sound engineering
sense.
…Questions / Discussion