Easy approach to requirements syntax ( EARS ) Conference
Adrian Harwood,Alistair Mavin,Philip Wilkinson,Adrian Harwood,Mark Novak
Abstract:The development of complex systems frequently involves extensive work to elicit, document and review stakeholder requirements. Stakeholder requirements are usually written in unconstrained natural language, which is inherently imprecise. During system development, problems in stakeholder requirements inevitably propagate to lower levels. This creates unnecessary volatility and risk, which impact programme schedule and cost. Some experts advocate the use of other notations to increase precision and minimise problems such as ambiguity. However, use of non-textual notations requires translation of the source requirements, which can introduce further errors. There is also a training overhead associated with the introduction of new notations. A small set of structural rules was developed to address eight common requirement problems including ambiguity, complexity and vagueness. The ruleset allows all natural language requirements to be expressed in one of five simple templates. The ruleset was applied whilst extracting aero engine control system requirements from an airworthiness regulation document. The results of this case study show qualitative and quantitative improvements compared with a conventional textual requirements specification. 1. Company background Aircraft engine control systems present a significant systems engineering challenge: the systems are complex, safety-critical and developed in ever-compressed timescales. To satisfy aircraft manufacturers’ requirements and maintain market position, control systems must provide increased functionality and maintain the highest levels of dependability. Rolls-Royce Control Systems develops Full Authority Digital Engine Controllers (FADECs) for civil gas turbine engines. The development and operation of FADECs present numerous challenges [1] including: operation in arduous environments, increased system complexity, evergreater reliability, improved fault tolerance and the need to certify against European and US regulations. A typical modern control system has a dual channel design, contains thousands of components, over 100,000 lines of code and is developed with up to twenty suppliers. 2. Background to the problem Stakeholder requirements are often written by individuals who are not experts in requirements definition. Most commonly, stakeholder requirements are written in unstructured natural language (NL). The flexibility of NL makes it an ideal medium for creative expression, such as drama, poetry and humour. However, unconstrained use of NL is inherently unsuitable for requirements definition for a number of reasons. Some of the problems that can appear in NL requirement documents are: Ambiguity (a word or phrase has two or more different meanings). Vagueness (lack of precision, structure and/or detail). Complexity (compound requirements containing complex sub-clauses and/or several interrelated statements). Omission (missing requirements, particularly requirements to handle unwanted behaviour). Duplication (repetition of requirements that are defining the same need). Wordiness (use of an unnecessary number of words). Inappropriate implementation (statements of how the system should be built, rather than what it should do). Untestability (requirements that cannot be proven true or false when the system is implemented). There are other problems that this study does not consider, including conflicting requirements and missing traceability links. There are two main reasons for their exclusion: firstly these problems are not unique to NL requirements documents, and secondly there are no occurrences of these problems in the case study. 1 There are three common forms of ambiguity: lexical, referential and syntactical [2]. Lexical ambiguity occurs where a word or phrase, which has two or more meanings, is used in a manner that permits a sentence or phrase to be interpreted in more than one way. Referential ambiguity occurs when a word or phrase is used that can be referring to two or more things. Syntactical ambiguity arises when the order of words allows two or more interpretations. To overcome problems associated with NL, some experts advocate the use of other notations for the specification of requirements. These include formal notations such a Z [3] and Petri Nets [4] and graphical notations such as Unified Modeling Language (UML) [5, 6] and Systems Modeling Language (SysML) [7]. There are also numerous scenario-based approaches [summarised in 8], tabular approaches such as Table-Driven Requirements [9] and ConCERT [10, 11] and pseudocode. Advocates of some notations claim that they work for requirements at all system levels, whilst others do not claim universal applicability. UML and SysML are graphical notations used to describe systems, within which different views can be generated depending on user needs. Meanwhile, claims have been made for the effective use of scenarios in many different ways and at different system levels [8] though not necessarily within an integrated framework. However, use of any of these non-textual notations often requires complex translation of the source requirements, which can introduce further errors. Such translation of requirements can serve to create a “language barrier” between developers and stakeholders due to unconscious communication of assumed context. There is also a training overhead associated with the introduction of many notations. Requirements authors are unlikely to seek excessive formality and complex training, and rarely do they require a software tool to help them write. There are many hundreds of general books on requirements engineering. There are also numerous examples of published works specifically about how to write better requirements. These include two well-known papers titled “Writing Good Requirements” [12, 13] that focus on the characteristics of well-formed requirements and the attributes that should be included. There are also templates available, such as VOLERE [14] and SL-07 [15]. Despite this large body of published material, there seems to be little simple, practical advice for the practitioner. It was hypothesised that introducing a small set of simple requirement structures would be an efficient and practical way to enhance the writing of high-level stakeholder requirements. Previous work in the area of constrained natural language includes Simplified Technical English [16], Attempto Controlled English (ACE) [17] and Event-Condition-Action (ECA) [18]. In ECA, the event specifies the signal that triggers the rule and the condition is a logical test that (if satisfied) causes the specified system action. The work reported here is principally concerned with requirements syntax. Although measures were taken to improve the semantics of the requirements, they are not described in this paper. There is no claim made that this approach is universally applicable to all levels of system decomposition. The technique is most suitable to the definition of high-level stakeholder requirements. The remainder of this paper is divided into five sections. Section 3 describes the Case Study. Section 4 defines the Method used and how it was developed. Section 5 summarises the Results. Section 6 is a Discussion of the findings and section 7 describes Future Work.