The Role of Formality in Requirements

1
The Role of Formality in Requirements

• Martyn Thomas

2
What are requirements?

• 1 The regulators view of how they would like the
  world to be? The reactor shall shut down safely
  if there is a problem.
• 2 The operators 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 engineers 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?

3
What do we mean by requirements?
User worlds
Computer system
Application Domain
Engineers view
Regulators view and operators view
See Problem Frames. M.A.Jackson 2001
4
What do we mean by requirements?
That will make something good happen in here ...
We want something to happen in here ...
When some- thing happens in here...
User worlds (informal)
Computer system (formal)
Application Domain (formalisable)
Engineers view
Regulators view and operators view
5
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

6
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

7
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

8
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)

9
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.

10
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.

11
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

12
an aside about Extreme Programming
13
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

14
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.

15
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)

16
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. (Thats what architects do,
  for example)
• Carry as much formality into the design and
  coding as possible, to strengthen verification.

17
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.

18
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
19
Civil Aviation Authority - CDIS Central Control
Function Display Information System
London Terminal Manoeuvring Area (five
airports)
1.5 million flights per annum Tunnel
routing Military and civil flights
London Area Terminal Control Centre
The most reliable system CAA have ever procured
CAA
Most reliable system
DTI SMARTIE Project review
20
CDIS overview Central Control Function Display
Information System
DTI SMARTIE Project review 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
A model of what can be achieved
...has integrated with our systems more easily
than any other system
21
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.

22
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

23
The Path to Security Assurance

• Randolph Johnson
• National Security Agency
• drjohns_at_orion.ncsc.mil

24
The Path to Security Assurance

• TOKENEER Identification Station
• Common Criteria
• Correct by Construction Process
• Praxis Results
• Student Experience
• Lessons Learned
• What is next?

25
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

26
TOKENEER ID Station
27
TIS System View
28
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

29
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.

30
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

31
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

32
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

33
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

34
Process Summary
35
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

36
Assurance Process
37
Statistics of System
38
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!

39
Guiding Principles

• Write right
• Step, dont leap
• Say something once
• Check here before going there
• Argue your corner
• Use the right tools for the job
• Use your brains

40
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

41
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)

42
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

43
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

44
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

45
End of Case study

• and of Randolph Johnsons slides

46
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.

47
Questions / Discussion