Requirements Eng (1997) 2:165-169 9 1997 Springer Verlag London Limited

Requirements Engineering

Viewpoints

.,~,'~

~, ~

~:

'

~

=

"

~

....

-4

:; ~ , -

'

~

~'

-

";,

~

;~;

=

:~s

....

:~'~_~

~.,

iI

~.~j_~;.~-~

Towards the Engineering of Requirements T. Gilb ResultPlanningLtd Kolbotn Norway

1. What is Engineering? In the 1980s, Professor Billy Koen of the Department of Mechanical Engineering, Austin, University of Texas, defined the engineering method as 'the use of heuristics to cause the best change in a poorly understood situation within the available resources'. He also stressed the importance of controlling risk by using the heuristics of making only small changes already known to have worked in the past, of planning paths of retreat in case of failure, and of feeding back results to improve future performance [1, p. 301]. Here is my rephrased version of Koen's definition of engineering: Engineering is the use of principles in a systematic way, to find designs, which deliver the requirements, within resource constraints, under conditions of uncertainty.

Correspondence and offprint requests to: Tom Gilb, Result Planning Ltd., Iver Holtersvei 2, N-1410 Kolbotn, Norway. Email: [email protected] site: http://www.Result-Planning.com

Here are some remarks concerning this definition (I'11 discuss the terms 'designs' and 'requirements' later in this article): 9 'Principles' are rules of thumb that guide the choices and actions of engineers. Principles are not rigid laws. They reflect the experience learnt from previous engineering projects. I see professional codes of conduct playing a part as well. 9 'In a systematic way' must include brainstorming and testing random insights. 9 'Deliver' implies a process that continues beyond design stages to project delivery stages. Success is determined by successfully meeting all the specified requirements. 9 'Conditions of uncertainty'9 exist because we must deal with combinations of designs being applied into ever-changing environments. The results are 'complex to predict' and the resulting risk has to be handled. I believe that such a definition of engineering is relevant to Software engineering. However, does current practice measure up? Are we 'engineering'? I consider that the software engineering industry is only just beginning to adopt the engineering practices of the more traditional engineering disciplines. Let me discuss the current state of requirements specification and give some pointers on how, I believe,

166

true engineering of requirements ought to be carried out. Today, too many requirements specifications contain what I shall call 'false' requirements.

2. What are 'False' Requirements? 'False' requirements occur when the requirement specification contains statements which are not really what is needed or desired. This happens when: (i) the requirements are not stated in a quantified and measurable way. It is commonplace to find requirements statements, such as 'reduced costs', 'improved management control', 'high usability' and 'increased customer satisfaction', with no clear definition of what is intended; no homing in on the key issues to reduce ambiguity and no quantification of the current and required levels at future dates. I once analysed about 40 design specifications for a mobile telephone. Almost all of the specifications simply included the wording 'increased ease of service' as one of their justifications. There was no definition, in writing, of the levels and types of serviceability that were to be aimed for. Once pointed out, the mobile telephone engineers agreed with me and we spent a day defining the serviceability requirements. 'Increased ease of service' actually expanded to approximately 18 different types of serviceability, each with its own quantified requirements levels. (ii) design ideas are used in place of the true requirements. I have noticed that there is a strong tendency to specify design ideas under the heading of 'Requirements'. For example, 'an object-orientated database is required', 'an improved handbook is needed' or 'a WINDOWS 95 interface is to be provided'. Usually, there are no clear agreed quantified requirements to even lend any support to the choice of the design. For example, the requirements giving rise to the request for 'an improved handbook' are probably to do with reducing training times and improving the quality of answers given to customers. But you need to explore this and quantify the requirements. Design ideas given as requirements must be treated with caution because they lead to the following negative effects: a. The true requirement is not stated and not known. Further, the actual process of determining the true requirements is highly likely to bring to light new

T. Gilb

requirements or alter the understanding o f what is wanted. b. Alternative better designs are not searched for. c. The overall design cannot be optimized to satisfy a larger set of requirements. (the true requirement and other concurrent requirements). True requirements are best stated m terms of the desired end-state effects, not the means for getting those effects. True requirements are best stated at the highest level of generality consistent with the end state required. This generality will permit a broader and more satisfactory set of design solutions to be considered.

3. What are 'Requirements?' I map 'requirements' under the following categories: 9 Functions: 'what' the system must be able to do. 9 Qualities: 'how well' the function will perform. 9 Costs: what we will budget as 'costs' (any input resource: money, people or time) for creating and maintaining the functions and their qualities. 9 Constraints: any restrictiorL on the freedom of the requirements or the design. I also differentiate between the two essentially different types of requirement statement: 9 Not quantifiable, but testable for presence. 9 Quantifiable (on a scale of measure). Functions are not quantifiable, they tend to be either present or absent. All qualities and costs are quantifiable. Constraints can be of either type.

3.1. Functions Time and again, current practice focuses on specifying functionality. Personally, I find 'functions' of less use when designing than the other categories. This is because it is usually fairly self-evident what functionality is required. It is actually the other categories that determine the choice of design. One further issue concerning functions: they should only be specified in detail on an 'as needs' ba~i~. There is little point specifying the current functionality in great detail if it is not a proposed candidate for imminent redesign. In a fast-moving business environment, change is occurring fairly rapidly and it is essential that any study of functionality should be accurate. So, unless you are planning specific system

Towards the Eng#'~edngof Requirements

167

chpnges, leave the ;functional description at a reaso=ably high leweiL Note, I ,eq~aate 'function' with process'. So, this also applies to the mapping of business processes!

Maintainability: Scale: Average time to repair a failure; from 'failure actually experienced' until 'completely and correctly fixed', including all negative side effects. Meter: Observation by analyst of at least 50 representative failures. Plan [Release Version 1] 10 hours.

Qualities and Costs At flais point, I shall inlroduce some of the terminology of a language I have ,deveJoped for specifying quantified requirements. I call ~t Planguage, which is'short for Planning Language. (Planguage also can be used for evaluating design ideas and planning evolutionary worksteps. It is available free on the Web [2].) I want to demonstrate some of the precision wi~h which requirements ought to be captured. As stated earlier, all quality and cost requirements are 'quanti~abqe'. That is, at least one scale of measure can be found t o help define the requh'ement. I use the parameter 'Scale' for this. All quality and cost requir.emenCrs "aTe also 'measurable'. That is, at least one practical, eeonomic process can b e defined for determining where we are on the specified scale of measure. I use the parameter 'Meter" for this. It is essential that finite limits are set for requirements, otherwise pote.z~ally infinite resources, which 9no one has, could be required to attain the unlimited quality levels. There are several categories of requirement levels~ 9 survival level: the level required for system survival, and for any p~yment to be made or for any value to be acknowledged. I use the parameter 'Must' for this. 9 success level: the level required for eeasonable satisfaction, and full payment or val,a~e. I use the parameter 'Plan' for this. These requirement levels can be specified for any set of conditions, such as time, space (component, market) and event. I call these conditions 'qualifiers' and enclose them in square brackets. For example: Availability: "depends o11 Rch~abillt3 and Maintainability' Reliability: Scale: Mean Time Between Failure per user in online hours per user. Meter: Calculate average time between reported user failure situations. Plan [Release Version 1] 24 hours.

3.2. Constraints Constraints divide a requirements or design territory into two areas: allowed and not allowed. Analysts and designers are free to specify requirements and design only in the 'allowed' area. True constraints do occur and they need to be handled appropriately (they need to be questioned and their consequences considered). However, too often constraints on design are s i a ~ y 'false requirements'; someone gave an example o~ the type o f design they were thinking of and the designer incorrectly failed to translate it into gemeric, higher-level requirements. The following constraint cafL~gories are useful, but not exhaustive: 9 quality level o cost level 9 9 9 9

functionality design political cultural

9 legal

3.3. What Bse is Important about Requirements? Requirements are a mul.fidimensional set of end-state needs, all vying for the same project resources. The fil of design to requirements is not likely to be perfect, thus there is a negotiable 'grey area' between them. Tradeoffs must be made and, maybe, the requirements have to be amended. It is essential to ensure you keep control of what you understand as the critical requirements. These can change over time. Only critical requirements are worth specifying and controlling. Critical requirements, by definition, are those which if not met threaten the survival of the entire system.

168

T. Glib

4. How are 'Requirements' and 'Design' Related?

6. What Can we do to Improve Requirements Engineering Practices?

The notion of requirements implies a defined viewpoint, which could come from several sources, e.g. ser~ior management, a customer, a user, a marketir~g plan. Requirements are a defined viewpoint's inputs to a design process. 'Design' is any set of ideas intended to satisfy a set of requirements. Designs are the outputs of the design process. Consider the following processes:

9 We musl define requirements clearly and unambiguously 9 We must teactz a discipline of specii=icat~on at tI~e systems level. 9 We must dearly connect design to requirements. 9 We must carry out rigorous quality control of requirements and design. 9 We must not allow highly defective (ambiguous, unclear, inconsistent) specification to be used as inputs to other work processes. 9 We must not specify too much detail too early. We must systematically get the benefit of early cycles of evolutionary deliveries, to help us re-specify requiremeats more realistica~l):

1. Architectural Requirements GOES TO [Architect Process] BECOMES Architecture. 2. Architecture and Engineering Requirements GOES TO [Engineering Process] B E C O M E S Engineering Design. 3. Engineering Design GOES TO [Production Engineering PROCESS] BECOMES Manufacturing Desigrt. The design output of one level or stage of work (level of design) becomes the 'requirements" input to the next stage. All requirements are someone's 'design ideas'. Design ideas can be viewed as a set of requirements for the nex! work process. The design process is one of moving, in one or more stages, towards a concrete real system. (Note that, 'design ideas' are only "false requirements' when they are not real constraints or when they are specified instead of the underlying function, quality and cost requirements. At certain levels or stages of work, design ideas do become the true requirements (constraints).)

5. How are 'Requirements' and 'Engineering' Related? Specifying requirements using a method such as Planguage is essential if we are to truly engineer requirements. Only with such specification do we explicitly communicate the quality levels, the cost levels, the constraints and the timescales required. This enables us to have a basis for comparison of the fit of the design ideas against the requirements. In addition, it helps the search for new design ideas as it focuses on the critical qualities that need to be delivered. It can also cope with evolutionary concepts, but that's another story!

GILB PUNCH-LINE We cannot expect to improve software engineering design, testing and quality control until we have considerably improved our ability to articulate quality requirements and other requirements in unambiguously clear testable format, and untU we even understand the distinction between ends and means.

7. What are the Fundamental Principles of Requirements? 1. All requirements are testable for presence in the real world of their implementation. 2. Some requirements are binary in nature, some are scalar variables. 3. All requirements reflect someone's subjective values and priorities. 4. For any given set of requirements, there are other sets of reqt~irements which would probably satisfy the specifier's real needs, values and priorities better or equally well. 5. All requirements are in natural conflict with all others for common resources. 6. Requirements are not static, but are forever changing as the world affecting us changes our needs, values and priorities. 7. Requirements engineering is the systematic process of determining the complete relevant set of values held by stakeholders, and processing them until a satisfactory level of 'delivery of the reqt~ired end states' has been made to them. This implies that it

7owards the Engineenng of Requirements

169

9 must include design, testing, quality control, projact management, specification languages and all other relevant disciplines to enable it to succeed.

Acknowledgement This article was edited ([email protected]).

by

Lindsey

Brodie

References 1. Gilb T. Principles of software engineering management. Addison-Wesley/Longman, 1988 2. A DoD web site containing my new book manuscript (RDM) (http://www.stsc.hill.af.mil/SWTesting/gilb.html) 3. Gilb T. Requirements-driven management: a planninglanguage. Crosstalk (DoD US) June 1997 (electronic downloadable copies at STSC site, http://www.stsc.hill. af.mil/Crosstalk/1997/jun/jun97ind.html) 4. Gilb T. Evolutionary object management. Object Expert UK 1997; January/February: p.24--29 & 72.