Most requirements engineering methods, and software development methods in general, are Taylorian in nature. Around the turn of the 20th century, Taylor introduced the notion of 'scientific management', in which tasks are recursively decomposed into simpler tasks and each task has one 'best way' to accomplish it. By careful observations and experiments this one best way can be found and formalized into procedures and rules. Scientific management has been successfully applied in many a factory operation. The equivalent in requirements engineering is to interview domain experts and observe end users at work in order to obtain the 'real' user requirements. After this, the experts go to work and implement these requirements. During the latter process, there is no further need to interact with the user community. This view of software development is a functional, and rational, one. Its underlying assumption is that there is one objective truth, which merely needs to be discovered during the analysis process.

Though this view has its merits in drawing up requirements in purely technical realms, many universes of discourse involve people as well — people whose model of the world is incomplete, subjective, irrational, and may conflict with the world view of others. In such cases, the analyst is not a passive outside observer of the UoD. Rather, he actively participates in the shaping of the UoD.

It is increasingly being recognized that the Taylorian, functional, approach is not the only, and need not be the most appropriate, approach to the requirements engineering process.

Analysts have a set of assumptions about the nature of the subject of study. Such a set of assumptions is commonly called a 'paradigm'. In our field, these assumptions concern the way in which analysts acquire knowledge (epistemological assumptions) and their view of the social and technical world (ontological assumptions).

The assumptions about knowledge result in an objectivist—subjectivist dimension. If the analyst takes the objectivist point of view, he applies models and methods derived from the natural sciences to arrive at the one and only truth. In the subjectivist position, the analyst's principal concern is to understand how the individual creates, modifies, and interprets the world he is in.

The assumptions about the world result in an order—conflict dimension. The order point of view emphasizes order, stability, integration, and consensus. On the other hand, the conflict view stresses change, conflict, and disintegration. These two dimensions and their associated extreme positions yield four paradigms for requirements engineering and, more generally, information systems development:

Admittedly, these paradigms reflect extreme orientations. In practice, some mixture of assumptions will usually guide the requirements engineering process. Yet it is fair to say that most system development techniques emphasize the functionalist view.

In the subjectivist—objectivist dimension, it is important to realize that a good deal of subjectivism may be involved in the shaping of the UoD. If we have to develop a system to control a copying machine, we may safely take a functional stand. We may expect such a machine to operate purely rationally. In the analysis process, we list the functions of the machine, its internal signals, conditions, and so on, in order to get a satisfactory picture of the system to be developed. Once these requirements are identified, they can be frozen and some waterfall-like process model can be employed to realize the system. If, however, our task is to develop a system to support people in doing their job, such as some office automation system, a purely functional view of the world may easily lead to ill-conceived systems. In such cases, end-user participation in the shaping of the UoD is of paramount importance. Through an open dialog with the people concerned, we may encourage the prospective users to influence the system to be developed. Part of the analyst's job in this case is to reconcile the views of the participants in the analysis process. Continuous feedback during the actual construction phases with possibilities for redirection may further enhance the chance of success. It is the future users who are going to work with the system. It is of no avail to confront them with a system that does not satisfy their needs.

Automation transforms organizations and, thus, affects the organization's employees. It may raise fears and other emotions with the employees affected. For instance, our library system potentially gives people access to a lot more information than they previously had. Some people may prefer to have access only to information related to their tasks and responsibilities. During requirements engineering, we have to be conscious of these effects. The pure functionalist paradigm then is of no avail.

A dissatisfied user will try to neglect the system or, at best, express additional requirements immediately. The net result is that the envisaged gain in efficiency or effectiveness is not reaped.

An illuminating and well-documented example of possible effects of following a fairly radical paradigm is given in (Page et al., 1993); see also Section 1.4.3. Although the computer-aided despatch system for the London Ambulance Service would significantly impact the way ambulance crews carried out their jobs, there was little consultation with them. Some of the consequences of this approach were the following (Page et al., 1993, pp. 40—41):

If the conceptual models of the participants differ, we may either look for a compromise or opt for one of the views expressed. It is impossible to give general guidelines on how to handle such cases. Looking for a compromise can be a tedious affair and may lead to a system that no one is really happy with. Opting for one particular view of the world will make one party happy, but may result in others completely neglecting the system developed. Worse yet, they may decide to develop a competing system.

The two main sources of information for the requirements elicitation process are the users and the (application) domain. These sources both presuppose that there exists something 'out there' to start with, from which requirements can be elicited. In market-driven software development though, this is often not the case; requirements elicitation in such projects is more like requirements invention or problem formulation, guided by marketing and sales considerations.

Figure 9.3 lists a number of elicitation techniques, which are elaborated upon below. The figure also tells us that the user is the major source of information in some techniques, while the domain is predominant in others. Furthermore, the figure indicates whether each technique is particularly useful for modeling the current or the anticipated future situation.

You should generally vacuum a rug in two directions rather than one; likewise, you should use multiple requirements elicitation techniques.

Figure 9.3. Requirements elicitation techniques

Asking: We may simply ask the users what they expect from the system. A presupposition then is that the user is able to bypass his own limitations and prejudices. Asking may take the form of an interview, a brainstorm, or a questionnaire. In an open-ended interview, the user freely talks about his tasks. This is the easiest form of requirements elicitation but it suffers from all of the drawbacks mentioned before. In a structured interview, the analyst tries to overcome them by leading the user, for example through closed or probing questions.

In discussion sessions with a group of users, we often find that some users are far more articulate than others and thus have a greater influence on the outcome. The consensus thus reached need not be well-balanced. To overcome this problem, a Delphi technique may be employed. The Delphi technique is an iterative technique in which information is exchanged in written form until a consensus is reached. For example, participants may write down their requirements, sorted in order of importance. The sets of requirements thus obtained are distributed to all participants, who reflect on them to obtain a revised set of requirements. This procedure is repeated several times until sufficient consensus is reached.

For consumer products, such as word-processing packages, antivirus software or software for your personal administration, users often have the option to give feedback, raise questions, report bugs, and so on, electronically. This type of information is also regularly gathered and stored by sales and marketing people in the course of their contacts with customers. These logs can be mined and in this way provide a valuable source of information when looking for requirements for the next release of that software.

Task analysis: Employees working in some domain perform a number of tasks, such as handling requests to borrow a book, cataloging new books, ordering books, etc. Higher-level tasks may be decomposed into subtasks. For example, the task 'handle request to borrow a book' may lead to the following subtasks:

Task analysis is a technique to obtain a hierarchy of tasks and subtasks to be carried out by people working in the domain. Any of the other techniques discussed may be used to get the necessary information to draw this hierarchy. There are no clear-cut rules as to when to stop decomposing tasks. A major heuristic is that at some point users tend to 'refuse' to decompose tasks any further. For instance, when being asked how the member identification is checked, the library employee may say 'Well, I simply check his id.' At this point, further decomposition is meaningless.

Task analysis is often applied at the stage when (details about) the human—computer interaction component are being decided upon. This underestimates its potency as a general requirements elicitation technique. It also gives the (wrong) impression that users are only concerned with the 'look and feel' of the interface.

Scenario-based analysis: Instead of looking for generic plans, as in interviews or task analysis, the analyst may study instances of tasks. A scenario is a story which tells us how a specific task instance is executed. The scenario can be real or artificial. An example of a real scenario is that the analyst observes how a library employee handles an actual user request. We may ask the library employee to verbalize what he is doing and make an audio or video recording of it. This think-aloud method is a fairly unobtrusive technique to study people at work. It is often used to assess prototypes or existing information systems.

Alternatively, we may construct artificial scenarios and discuss them with the user. As a first shot, we may for example draw up the following scenario for returning a book:

When this scenario is discussed with the library employee, a number of related issues may crop up, either through probing questions from the analyst or because the user contrasts the scenario with daily practice. Example questions that could be raised include such things as:

In essence, this type of story-telling provides the user with an artificial mock-up version of the software eventually to be delivered. It serves as a paper-based prototype to gain a better understanding of the requirements. If tied to UML-type modeling, scenario-based analysis is often called use-case analysis; see Section 10.3.6. Scenarios and use cases are the elicitation methods most often used.

Scenario-based analysis is often done in a somewhat haphazard way. In that case, there is no way of telling whether enough scenarios have been drawn up and a sufficiently accurate and complete picture of the requirements is obtained. Writing good scenarios is by no means easy. Though it may look trivial to 'just record user episodes', a fair amount of domain expertise is needed to get a good and reliable set of scenarios.

Scenarios can be looked at from different perspectives. In the above example scenario for returning a book, the scenario lists a series of actions or events that together make up some episode. The focus then is on the process aspect, showing how the system proceeds through successive states. Alternatively, the same scenario may be looked at from a user perspective: How does the user interact with the system? What functionalities is she offered? Yet another perspective is that the scenario leads to discussions about alternatives from which a certain choice has to be made, as in the questions that the example scenario above raised.

Ethnography: A major disadvantage of eliciting requirements through, for example, interviews is that the analyst imposes his view of how the world is ordered onto the user. Such methods may fail if the analyst and user do not share a category system. The analyst may, for example, ask the following question: 'If a member wants to borrow a book but has an outstanding fine, do you:

This binary choice need not map actual practice. The library employee may, for example, grant the request provided part of the outstanding fine is settled or if he knows the member to be trustworthy.

Thinking-aloud protocols are based on the idea that users have well-defined goals and subgoals, and that they traverse such goal trees in a neat top-down manner. People however often do not have preconceived plans, but rather proceed in somewhat opportunistic ways.

A disadvantage of task analysis is that it considers the individual tasks of individual people, without taking into account the social and organizational environment in which these tasks are executed.

Ethnographic methods are claimed not to have such shortcomings. In ethnography, groups of people are studied in their natural settings. It is well-known from sociology where, for example, Polynesian tribes are studied by living with them for an extended period of time. Likewise, user requirements can be studied by participating in their daily work for a period of time, for example by becoming a library employee. The analyst becomes an apprentice, recognizing that the future users of the system are the real experts in their work. Ethnographic methods are more likely to uncover tacit knowledge than most other elicitation techniques.

Form analysis: A lot of information about the domain being modeled can often be found in various forms being used. For example, to request some conference proceedings from another library, the user might have to fill in a form such as the one in Figure 9.4.

Forms provide us with information about the data objects of the domain, their properties, and their interrelations. They are particularly useful as an input to modeling the data aspect of the system; see also Section 10.1.1.

Library users often have incomplete knowledge of the information sources they are interested in. For example, someone might be looking for the proceedings of the International Conference on Software Engineering that took place in Berlin. Only if the various entries from the above form are used as entities in the underlying data model can such a query be answered easily. In this case, the form directly points at a useful requirement which might otherwise go unnoticed.

Figure 9.4. A sample form

Natural language descriptions Like forms, natural language descriptions provide a lot of useful information about the domain to be modeled. The operating instructions for library employees might for instance contain a paragraph like the one given in Figure 9.5. This text gives us such information as:

Figure 9.5. A sample instruction for library employees

Often, natural language descriptions (and forms) provide the analyst with background information to be used in conjunction with other elicitation techniques such as interviews. Natural language descriptions in particular tend to assume a lot of tacit knowledge by the reader. For example, if form B contains an ISBN, this saves the library employee some work, but the request will probably still be handled if this information is not provided. A practical problem with natural language descriptions is that they are often not kept up to date. Like software documentation, their validity tends to deteriorate with time.

Derivation from an existing system: Starting from an existing system, for instance a similar system in some other organization or a description in a text book, we may formulate the requirements of the new system. Obviously, we have to be careful and take the peculiar circumstances of the present situation into account.

Rather than looking at one particular system, we may also study a number of systems in some application domain. This meta-requirements analysis process is known as domain analysis. Its goal generally is to identify reusable components, concepts, structures, and so on. It is dangerous to look for reusable requirements in immature domains. Requirements may then be reused simply because they are available, not because they fit the situation at hand. They become 'dead wood'. In the context of requirements analysis, domain analysis can be viewed as a technique for deriving a 'reference' model for systems within a given domain. Such a reference model provides a skeleton (architecture) that can be augmented and adapted to fit the specific situation at hand.

Domain analysis is further discussed in Chapter 17, in the context of software reuse.

Business process redesign (BPR): In many software development projects, the people involved jump to conclusions rather quickly: automation is the answer. Even worse, their conclusion might be that automating the current situation is the answer. In business process redesign (or business process reengineering), a rather different strategy is followed. It is an organizational activity to radically redesign business processes to achieve competitive breakthroughs in, e.g. quality, cost, or user satisfaction. In BPR, we depart completely from the existing ways of doing things. BPR involves the following steps:

BPR is not really a requirements elicitation technique proper. It is mentioned here because it emphasizes an essential issue to be addressed during the requirements engineering phase. Business processes should not be driven by information technology. Rather, information technology should enable them. Though a complete BPR effort is not necessary or feasible in many situations, rethinking the existing processes and procedures is a step which is all too often thoughtlessly skipped in software development projects.

As an example, consider our library automation project once again. Careful inspection of the current situation might reveal that things aren't all that bad. However, the impression is that the number of requests that could not be granted has steadily risen in the past years. This is perceived to be the main cause of the increasing number of dissatisfied users. Since service to its customers has high priority, one of the objectives is to decrease the number of requests that cannot be satisfied by 50% within two years. For this to be possible, the library should be allowed to spend the available budget at its own discretion, rather than being triggered by signals from researchers only (this sounds radical, doesn't it). It is therefore decided to augment the existing automated system with modules to keep track of both successful and unsuccessful requests. Based on the insights gained from this measurement process during a period of three months, a decision will be taken as to how large a percentage of the annual budget will be reallocated.

Prototyping Given the fact that it is difficult, if not impossible, to build the right system from the start, we may decide to use prototypes. Starting from a first set of requirements, a prototype of the system is constructed. This prototype is used for experiments, which lead to new requirements and more insight into the possible uses of the system. In one or more ensuing steps, a more definite set of requirements is developed. Prototyping is discussed in Section 3.2.1. Other agile processes follow a similar strategy in which requirements are quickly translated into a running system to be assessed by its users.

Of these requirements elicitation techniques, 'asking' is the least certain strategy, while 'prototyping' is the least uncertain. Besides the experience of both users and analysts, the uncertainty of the process is also influenced by the stability of the environment, the complexity of the product to be developed, and the familiarity with the problem area in question. We may try to estimate the impact of those factors on the vulnerability of the resulting requirements specification, and then decide on a primary method for requirements elicitation based on this estimate.

For a well-understood problem, with very experienced analysts, interviewing the prospective users may suffice. However, if it concerns an advanced and ill-understood problem from within a rapidly changing environment and the analysts have little or no experience in the domain in question, it seems wise to follow an agile process.

Requirements uncertainty is not the only problem project managers have to cope with, and a different process is not the only solution they opt for. Political aspects (such as hidden agendas and conflicts between stakeholders) are often seen as larger risks than mere requirements uncertainty (Moynihan, 2000). Of course, these are related. In both cases, the chances are high that requirements will change. Project managers often follow a formal route to handle disagreements between stakeholders and let the customers sign off the requirements document. Whether this is the answer in the long run is questionable, though.

As the uncertainty decreases, the beneficial effects of user participation in requirements engineering diminish. With greater uncertainty, however, greater user participation does have a positive effect on the quality of requirements engineering.

It is generally wise to have multiple customer—developer links in a software development project, and during requirements engineering in particular. Keil and Carmel (1995) studied the relation between project success and the number and type of such customer—developer links. The authors observed a strong correlation between the number of links and project success: more links implied more successful projects. The relative contribution to project success diminishes as the number of links grows; there is no need to have more than, say, half a dozen links. A further interesting observation from this study is that links with direct users have more impact on project success than links with indirect users such as user representatives or sales people. Finally, it was noted that customer-driven development projects tend to use and prefer different types of link to market-driven development projects. For example, the favorite link for custom development — facilitated teams — was not used by package developers, while the favorite link for package developers — support lines — was seldom used for custom projects.

We should be very careful in our assessment of which requirements elicitation technique to choose. It is all too common to be too optimistic about our ability to properly assess software requirements.

As an example, consider the following anecdote from a Dutch newspaper. A firm in the business of farm automation had developed a system in which microchips were put in cows' ears. Subsequently, each individual cow could be tracked: food and water supply was regulated and adjusted, the amount and quality of the milk automatically recorded and analyzed, etc. Quite naturally, this same technique was next successfully applied to pigs. Thereafter, it was tried on goats. A million-dollar, fully automated goat farm was built. But alas, things did not work out that well for goats. Unlike cows and pigs, goats eat everything, including their companions' chips.

In this section, we discuss two ways to structure a set of requirements. One way to do so is in a hierarchical structure: higher-level requirements are decomposed into lower-level ones. The high-level requirements are often termed goals. The other structuring method links requirements to specific stakeholders. Management may have one set of requirements and the end users may have another set of requirements. These different sets of requirements are called viewpoints. In both cases, elicitation and structuring go hand in hand.

For example, one of the requirements elicited for our library system could be that the system should allow users to search the database for a particular book. By asking ourselves or the stakeholders why this requirement is needed, a higher-level requirement is detected, that is, the necessity of having search facilities. Again asking 'why', a high-level goal of serving the customers is arrived at. Going the other way, by asking how the library system may help serve the customers, a requirement to learn about user preferences and use this knowledge while interacting with the user might emerge. In this way, by asking why and how questions, a hierarchical structure of goals and requirements develops. Figure 9.6 contains an example of such a hierarchical structure.

Figure 9.6. Hierarchy of requirements

Figure 9.6 depicts a refinement structure, in which each requirement is refined (decomposed) into a set of subrequirements that together satisfy the parent requirement. The subrequirements are AND-related: 'search book' and 'search news item' together make up the 'search facilities' requirement.

We may also include other types of relationship. For instance, we may have certain options for a particular requirement and, to that end, have OR-relations next to AND-relations. We may also include other types of link. If we have a requirement to impose fines on customers who return items late, we may conceive this as conflicting with our goal of serving customers and connect these two requirements by a link of type 'conflicts with'.

This so-called goal-driven requirements engineering results in a graph connecting high-level goals to lower-level requirements. This graph can be reasoned about, e.g. to validate that certain goals are indeed reached or to detect conflicts (Lamsweerde, 2001).

It is often useful to collect and organize requirements from different perspectives or viewpoints. Different stakeholders may have different sets of requirements. Different quality concerns may also lead to different sets of requirements, leading for instance to a security viewpoint. The latter type of perspective is usually dealt with during software architecture design, and is discussed in Chapter 11. The techniques discussed in Chapter 10 implicitly denote different viewpoints as well, such as a data viewpoint in the entity—relationship models. Here, we focus on different viewpoints caused by different stakeholders. These different viewpoints may be in conflict, and these conflicts need to be recognized and dealt with during requirements engineering. The computer-aided dispatch system for the London Ambulance Service again provides a clear case of conflicting viewpoints: management wants an effective system; crew members want to get home within a reasonable time after their shift has ended (see also Sections 1.4.3 and 9.1.1). For our library system, conflicts between stakeholders may likewise occur.

Consider, for example, the following issue which may crop up during the requirements elicitation phase for our library system. The system has to offer certain features to register and handle fines. An item not returned in time incurs a fine of, say, $0.25 per day. John, one of the library employees involved in the specification process, takes the following position (denoted 'Pos A' in Figure 9.7): members should be warned about outstanding fines at the earliest possible moment. His argument ('Arg A') is that service is degraded if a member cannot borrow an item because some other member has not returned that item on time. Mary, the library manager, takes a rather different position ('Pos B'): members should not be warned about outstanding fines until the due date has expired one month. Her argument ('Arg B') is that fines are a most welcome addition to the library budget, which is under severe pressure because of the continuing price increase of journal subscriptions.

This situation is depicted in the graph in Figure 9.7. The graph contains nodes of types 'issue', 'position' and 'argument', and directed links of type 'response-to', 'taken-by' and 'supports'. Capturing this type of information in an automated system offers possibilities for storing, tracing and manipulating the very diverse types of information gathered during the requirements engineering phase. An early system along these lines is gIBIS, a system designed to capture design decisions early in the process.

Two viewpoints in particular are important during requirements engineering: the business viewpoint and the personal viewpoint. The business viewpoint is usually propagated by management stakeholders, while the personal viewpoint is usually propagated by end users. However, end users tend to also ascribe to business requirements, at least at an early stage. For instance, when John is asked whether fines are a welcome addition to the subsidy the library gets from the government, a likely answer is 'yes'. This requirement is viewed as a requirement of the business, not a personal requirement of John. Only when he is confronted with the consequences does he realize that this is, after all, not what he wants. And a request to change the system will follow.

Figure 9.7. Representation of conflicting viewpoints

In most cases, not all requirements can be realized, so we have to make a selection. In Section 3.2.3 we mentioned a very simple form of requirements prioritization called triage. A variant often used is known as MoSCoW (the Os are just there to be able to pronounce the word). Using MoSCoW, we distinguish four types of requirement:

The MoSCoW scheme assumes that requirements can be ordered along a single axis and that realizing more requirements yields more satisfied customers. The reality is often more complex. In the Kano model of (Kano, 1993), user preferences are classified into five categories, as listed in Table 9.1. The way customers value the Attractive, Must-be and One-dimensional categories of requirements is depicted in Figure 9.8. This figure shows that offering attractive, so-called killer features is what will really excite your customers. The above quote from Robertson (2002) points in the same direction: amaze your customer by giving him something he never even dreamt of.

In market-driven software development, the product often has a series of releases. The list of requirements for such products is usually derived from sales information, user logs from earlier versions of the system, and other sources of indirect information. One then has to decide which requirements to include in the current version, and which ones to postpone to a future one. Business-case analysis, return on investment estimations, and similar economics-driven argumentations are used to set priorities. This priority setting is to be repeated for each version, since user preferences may change, the market reacts, and so on.

Figure 9.8. The Kano diagram

Finally, the prioritization of requirements is related to the notion of scoping in software product lines. If we want to develop a series of similar library systems, we have to delimit the domain we intend to handle. A smaller domain, say only scientific libraries, is easier to realize, but has a smaller market. A set of products covering a larger domain is more difficult to realize, yet has the promise of larger sales and profits.

Up till now, we have dealt with a situation where the customer phrases requirements, after which a system that satisfies these requirements is developed. With commercial off-the-shelf (COTS) software, the customer has to choose from what is available. In practice, the situation is not always that clear cut and a COTS system may be extended or adapted to suit the customer's needs. For our discussion, we assume it is a pure selection process.

COTS selection is an iterative process comprising the following steps:

Often, the set of components and requirements is too large to make a complete analysis and ranking in one step feasible. An iterative process is then followed, whereby the most important requirements are used to make a first selection from the set of available components. In a next step, a larger list of requirements is assessed against a smaller set of components. And so on.

There are different ways to rank components. A straightforward method is the weighted scoring method (WSM). Each requirement is given a weight and the alternatives are given a score for each requirement, say on a scale from 1 to 5. In Table 9.2, three components labeled A, B, and C are scored on three criteria: performance, supplier reputation, and functionality. In the example, components B and C score highest, and these might next be scrutinized further.

A major drawback of WSM is that every criterion can be compensated for by any other criterion. In the example from Table 9.2, component C makes it to the next round even though it scores very low on functionality. More complex ranking schemes, such as the analytic hierarchy process (AHP) overcome this drawback (Saaty, 1990).

Many years ago, I used to visit a toy store with my son Jasper to browse the shelves with LEGO boxes and pick one we liked, to build a castle, fire engine or aeroplane. Nowadays, children (and probably their fathers too) visit the LEGO website. This site provides a CAD tool, so that you can design your own customized model of your favorite building or car. Once done, you press a button to generate a bill of materials, after which the components needed are gathered, put in a box, and shipped. You may leave the model created in a gallery. Rather than creating a model from scratch, you may browse the gallery and pick a model from there. The models that are most often selected are prepackaged and shipped to the toy stores.

This way, LEGO does not need any 'requirements engineers', people who develop new models and hope that their customers will be thrilled by them. Rather, the requirements engineering process is outsourced to a large community of volunteers: the children (and their fathers). It is called crowdsourcing.

Crowdsourcing as a business model is not uncommon. Wikipedia works that way. Companies may create a portal where users can suggest and vote for product improvements to guide innovation. In the area of software, companies sometimes rely on open source communities for innovations. The open source community then acts as a filter: the requirements that matter seep through and become part of the open source product. Next, the commercial company incorporates the open source software as part of its own product.

Rather than passively waiting for something interesting to happen, we may also try to induce a crowd to collaborate. This is usually done by providing a kernel or platform from which users can develop ideas and products. A user does not have to 'invent' what an online encyclopedia looks like, but can immediately contribute to the existing Wikipedia framework. Likewise, many open source projects start from a kernel developed by a very small community.

The purpose of the requirements specification is to communicate the results of the analysis phase to others. It serves as an anchor point against which subsequent steps can be justified.

The requirements specification is also the starting point for the next phase: design. Consequently, a very precise, even mathematical, description is preferable. On the other hand, the specification must also be understandable to the user. This often means a readable document, using natural language and pictures. In practice, one has to look for a compromise. Alternatively, the requirements specification may be presented in different, but consistent, forms to the different audiences involved.

Besides readability and understandability, various other requirements for this document can be stated (IEEE830, 1998):

As a guideline for the contents of a requirements specification we will follow IEEE Standard 830. This standard does not give a rigid form for the requirements specification. In our opinion, the precise ordering and contents of the elements of this document are less than essential. The important point is to choose a structure which adheres to the above constraints. (IEEE830, 1998) uses a global structure such as that depicted in Table 9.3.

For any nontrivial system, the detailed requirements will constitute by far the largest part of the requirements document. It is therefore helpful to somehow categorize these detailed requirements. This can be done along different dimensions, such as:

As an example, Table 9.4 gives a refinement of the section on specific requirements along the dimension of user classes. Figure 9.9 contains (part of) a possible requirements specification for the library example, following the IEEE guidelines.

The IEEE framework for the requirements specification is especially appropriate in document-driven models for the software development process: the waterfall model and its variants. When a prototyping technique is used to determine the user interface, the IEEE framework can be used to describe the outcome of that prototyping process. The framework assumes a model in which the result of the requirements engineering process is unambiguous and complete. Though it is stated that requirements should be ranked for importance and that requirements that may be delayed until future versions may be included as subsets, this does not imply that a layered view of the system can be readily derived from a requirements document drawn up this way.

Irrespective of the format chosen for representing requirements, the success of a product strongly depends upon the degree to which the desired system is properly described during the requirements engineering phase. Small slips in the requirements specification may necessitate large changes in the final software. In Chapter 1, we described this by saying that software is not continuous.

Figure 9.9. Partial requirements specification for the library example

The importance of a solid requirements specification cannot be stressed often enough. In some cases, up to 95% of the code of large systems has had to be rewritten in order to adhere to the ultimate user requirements.

A fundamental problem with the IEEE framework discussed in Section 9.2.1 is that it describes only the end product. Before this final stage is reached, the 'current' set of requirements is in a constant state of flux. And even after the requirements phase is ended, requirements will change and new requirements will be put forth. The latter phenomenon is known as requirements creep, and is the cause for many run-away projects.

Changes in requirements cannot be circumvented. In many cases, it is not wise to aim for an early freeze of the requirements either. In general, the preferred situation is as depicted in Figure 9.10: over the course of time, the set of requirements becomes more and more stable.

Figure 9.10. Requirements stability over time

Obviously, this evolving set of requirements has to be managed. Requirements management involves three activities:

Each requirement has to have a unique means of identification. The simplest method is to number them. If there is a hierarchical organization, as in a goal-hierarchy, it can be reflected in the numbering scheme. Since requirements are often changed and updated, it is expedient to include versioning information as well. Finally, we may add some attributes to each requirement, such as its status, priority, the main stakeholder involved, and so on. Requirements engineering tools usually have a way of storing requirements in a structured repository.

Changes to requirements have to be managed properly. By viewing each requirement as a configuration item, the rules and procedures of configuration management (Chapter 4) can be applied.

We may connect requirements to solution elements such as design elements or even software components that realize those requirements. In this way, we establish traceability from requirements to code and vice versa. This allows us to trace where requirements are realized (forward traceability), and why certain solutions are chosen (backward traceability). Traceability information is important in all development phases. It can be used to answer a variety of questions, such as:

This way of making explicit the relationship between requirements and solutions is closely related to design space analysis. In design space analysis, the aim is to explicitly model all possible combinations of requirements and solutions. Design space analysis originated in the field of human—computer interaction. A well-known notation for design space analysis is known as 'questions, options, and criteria' (QOC). Questions correspond to requirements; options are the possible answers to those requirements; and criteria refer to the reasons for choosing a particular option. For instance, we may display the result of a news query by a library customer (the question) sorted either by date of publication or by author name (the options). The criterion for using a specific ordering could be the source of the news item; for example, newspaper articles could be sorted by date and journal articles by author name.

On one hand, design space analysis results in a rich structure in which an extensive record is built up of the rationale for a specific solution. Why is this system built the way it is? Which alternatives did we consider but reject? Which requirements survived the tradeoffs we had to make? On the other hand, capturing all this information is expensive and the immediate benefits are difficult, if not impossible, to prove. This is a main reason why design rationale has, by and large, failed to transfer to practice.

The user is, in general, best served by a document which speaks his language, the language that is used within the application domain. In the library example, this would result in using terms such as 'title description' and 'catalog'.

The designer, on the other hand, is best served by a language in which concepts from his world are used. In terms of the library example, he may prefer concepts such as 'record' (an instance of which might be termed 'title description') or 'file'. In one sense, this boils down to a difference in language. However, this difference is of fundamental importance with respect to the later use of the system's description.

If the system is described in the user's language, the requirements specification is mostly phrased in some natural language. If we try to somewhat formalize this description, we may end up with a technique in which certain forms have to be filled in or certain drawing techniques have to be applied.

If, on the other hand, the expert language of the software engineer plays a central role, we often use some formal language. A requirements specification phrased in such a formal language may be checked using formal techniques, for instance with regard to consistency and completeness.

In practice, a strong prevalence of the user's expert language shows itself. We may then use existing concepts from the environment in which the system is going to be used. Admittedly, these concepts are not sharply defined, but in general there are no misconceptions between the experts in the application domain as regards the meaning of those concepts. A description in terms of those concepts can thus still be very precise. Since the first goal of the requirements specification is to get a complete description of the problem to be solved, the user's expert language may be the best language for the requirements specification.

However, there are certain drawbacks attached to the use of natural language. Meyer (1985) gives an example which illustrates very well what may go wrong when natural language is used in a requirements specification. Meyer lists seven sins which may beset the analyst when using natural language:

A possible alternative given by Meyer is to first describe and analyze the problem using some formal notation and then translate it back into natural language. The natural language description thus obtained will, in general, represent a more precise notion of the problem that is readable to the user. Obviously, both these models must be kept up to date.

Quite a number of techniques and accompanying notations have evolved to support the requirements engineering process. Most often, the representation generated is a set of semantic networks. Each such representation has various types of nodes and links between nodes, distinguished by visual clues such as their shape or natural language labels. Nodes typically represent things like processes, stores, objects, and attributes. Nodes are joined by arrows representing relationships such as data flow, control flow, abstraction, part—whole, or is-part-of.

Typical examples of such techniques and their representations are discussed in Chapter 10. Entity—relationship modeling (Section 10.1.1) is a widely known technique to model the data aspect of an information system. Finite state machines (Section 10.1.2) can be viewed as a technique to model the functional aspect. They have much wider applicability though and constitute a basic underlying mechanism for many modeling techniques. In particular, the Unified Modeling Language (UML) owes tribute to them. UML diagrams (Section 10.3) are widely used to model the result of both requirements engineering and design.

The IEEE framework depicted in Table 9.4 lists four types of non-functional requirements: external interface requirements, performance requirements, design constraints and software system attributes. These non-functional requirements can be viewed as constraints placed upon the development process or the products to be delivered.

External interface requirements and design constraints are generally phrased in terms of (non-negotiable) obligations to be met. They are dictated at the start of the project and often concern matters which surpass an individual development project. Examples of such requirements include:

The remaining non-functional requirements are also known as quality requirements. Quality requirements are notoriously difficult to specify and verify. This topic is dealt with extensively in Chapter 6. At this point, we merely wish to re-emphasize two essential issues: quality requirements should be expressed in objective, measurable terms and perfection incurs infinite cost. Like all other requirements, quality requirements should be verifiable. Requirements such as 'the system should be flexible', 'the system should be user-friendly', or 'response times should be fast', can never be verified and should not therefore appear in the requirements specification. Other phraseology can be used such as 'for activities of type A, the system should have a maximum response time of one second in 80% of the cases, while a maximum response time of three seconds is allowed in the remaining 20% of the cases.'

Conversely, extreme levels of quality requirements, such as zero defects or response times of less than 1 second in 100% of the cases, generally incur extremely high costs or are not feasible at all. Given the fact that users find it difficult to express their true requirements, they may be inclined to ask for too much where quality requirements are concerned, 'just to be on the safe side'. To the analyst and developers, it is likewise difficult to assess the feasibility of those requirements. How can we be sure about response times before even one line of code has been written?

Consider the following example of what may and may not be technically feasible. Suppose we have an application in which two kinds of transactions may occur. Those transactions are characterized by their frequency, CPU-time needed, and the number of physical I/O transports. The average I/O access time is also given. Using a statistical distribution describing the dynamics of these systems, one may then answer questions such as, 'how much capacity should the CPU have in order to achieve a response time of at most 2 seconds in X% of cases?' Some given configuration may satisfy the constraints for the case X = 80. A somewhat more stringent requirement (X = 90) may require doubling of the CPU capacity. An even more severe requirement (X = 95) might well not be achievable by the range of machines available.

At first sight, the differences between these requirements seem marginal. They turn out to have a tremendous effect, though. An early and careful analysis of the technical feasibility may yield surprising answers to a number of important questions. Usually, this type of analysis is done at software architecture time. There are many examples of projects in which lots of money was spent on software development efforts which turned out to be not practically feasible (Baber, 1982).