Embed Size (px)
Citation preview
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?
User worldsComputer system
Application Domain
Engineer’s view Regulator’s view and operator’s view
See: Problem Frames. M.A.Jackson 2001
What do we mean by requirements?
User worlds(informal)
Computer system
(formal)
Application Domain
(formalisable)
Engineer’s view Regulator’s view and operator’s view
We want something to happenin here ...
When some-thing happensin here...
That will makesomethinggood happenin here ...
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.
… end of aside
So XP carries the risks of:• unnecessary change: even failure to converge on a specification• poor architectural decisions that cannot be “refactored” cost-
effectively• 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)
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 - CDISCentral 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 - CDISCentral Control Function Display Information System
1.5 million flights per annum
‘Tunnel’ routing
Military and civil flights
The most reliable system CAA have ever procured CAA
Most reliable system DTI ‘SMARTIE Project’ review
London Terminal Manoeuvring Area (five airports)
London Area TerminalControl Centre
CDIS overviewCentral Control Function Display Information System
Systems integration
Stratus fault tolerant platformDualled token ring95 PS2 OS/2 ATCO stationsX25, token ring and serial I/OStratus mainframe
Formal methods
VDM core specificationYourdon concurrency spec.CCS Network modelEnglish and graphics user I/F spec.
10 year warranty on critical faults
DTI ‘SMARTIE Project’ review
City University Centre for Software Reliability
200,000 lines of code816 person months 33 elapsed months0.75 faults per KLOV (Vs survey average of 8.2)Zero critical faults
Software support requires 2 staff
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
• 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
ProtectedEnclave
Portal
Display FingerprintReader
TokenReader
TISAlarm
Admin
TIS System View
Displaysimulator
DisplayInterface
BiometricSubsystem
FingerprintReader
simulator
Portalsimulator
PortalLatch
Interface
TIS CoreFunctions
TIS
CryptoLibrary
AlarmsimulatorAlarm
InterfaceCertificate
Library
TokenReader
Interface
TokenReader
simulator
KEY: SimulatedDevice
Softwaresubsystem
TIS Coredeveloped
to EAL5User interaction
AdminInterface
Guard/Administrator
interaction
ProtectedEnclave
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”
OVERVIEW-
Correct 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
SPARKImplementation
INFORMEDDesign
Formal Design
FormalSpecification
SecurityProperties
Proof of SecurityProperties
(Z)
Proof of FormalSpecification
(Z)
Refinement Proofof Formal Design
(Z)
Proof of SecurityProperties
(SPARK Proof)
Proof ofFunctionalProperties
(SPARK Proof)
Static Analysis
AssuranceActivity
KeySystem Test
System TestSpecification
Statistics of System
882,2403,697Support
3816,5649,939Core
LOC/daySpark annotations
Ada Source Lines
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
