The Role of Formality in Requirements

1. The Role of Formality in Requirements Martyn Thomas

2. 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?

3. What do we mean by requirements? User worlds Computer system Application Domain Engineer’s view Regulator’s view and operator’s 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) Engineer’s view Regulator’s view and operator’s 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. (That’s 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. Systems integration Stratus fault tolerant platform Dualled token ring 95 PS2 OS/2 ATCO stations X25, token ring and serial I/O Stratus mainframe 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 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@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. Ada Source Lines Spark annotations LOC/day Core 9,939 16,564 38 Support 3,697 2,240 88 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, don’t 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 Johnson’s 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