DAG: Directed Acyclic Graph 

FSM: Functional Size Measurement

INCOSE: International Council on Systems Engineering

SADT: Structured Analysis and Design Technique

UML: Unified Modeling Language

The Software Requirements Knowledge Area (KA) is concerned with the elicitation, analysis, specification, and validation of software requirements. It is widely acknowledged within the software industry that software engineering projects are critically vulnerable when these activities are performed poorly.

Software requirements express the needs and constraints placed on a software product that contribute to the solution of some real-world problem. [Kot00]

The term “requirements engineering” is widely used in the field to denote the systematic handling of requirements. For reasons of consistency, though, this term will not be used in the Guide, as it has been decided that the use of the term “engineering” for activities other than software engineering ones is to be avoided in this edition of the Guide.

For the same reason, “requirements engineer,” a term which appears in some of the literature, will not be used either. Instead, the term “software engineer” or, in some specific cases, “requirements specialist” will be used, the latter where the role in question is usually performed by an individual other than a software engineer. This does not imply, however, that a software engineer could not perform the function.

The KA breakdown is broadly compatible with the sections of IEEE 12207 that refer to requirements activities. (IEEE12207.1-96)

A risk inherent in the proposed breakdown is that a waterfall-like process may be inferred. To guard against this, subarea 2 Requirements process, is designed to provide a high-level overview of the requirements process by setting out the resources and constraints under which the process operates and which act to configure it.

An alternate decomposition could use a product-based structure (system requirements, software requirements, prototypes, use cases, and so on). The process-based breakdown reflects the fact that the requirements process, if it is to be successful, must be considered as a process involving complex, tightly coupled activities (both sequential and concurrent), rather than as a discrete, one off activity performed at the outset of a software development project.

The Software Requirements KA is related closely to the Software Design, Software Testing, Software Maintenance, Software Configuration Management, Software Engineering Management, Software Engineering Process, and Software Quality KAs.

At its most basic, a software requirement is a property which must be exhibited in order to solve some problem in the real world. The Guide refers to requirements on “software” because it is concerned with problems to be addressed by software. Hence, a software requirement is a property which must be exhibited by software developed or adapted to solve a particular problem. The problem may be to automate part of a task of someone who will use the software, to support the business processes of the organization that has commissioned the software, to correct shortcomings of existing software, to control a device, and many more. The functioning of users, business processes, and devices is typically complex. By extension, therefore, the requirements on particular software are typically a complex combination of requirements from different people at different levels of an organization and from the environment in which the software will operate.

An essential property of all software requirements is that they be verifiable. It may be difficult or costly to verify certain software requirements. For example, verification of the throughput requirement on the call center may necessitate the development of simulation software. Both the software requirements and software quality personnel must ensure that the requirements can be verified within the available resource constraints.

Requirements have other attributes in addition to the behavioral properties that they express. Common examples include a priority rating to enable trade-offs in the face of finite resources and a status value to enable project progress to be monitored. Typically, software requirements are uniquely identified so that they can be over the entire software life cycle. [Kot00; Pfl01; Som05; Tha97]

A distinction can be drawn between product parameters and process parameters. Product parameters are requirements on software to be developed (for example, “The software shall verify that a student meets all prerequisites before he or she registers for a course.”).

A process parameter is essentially a constraint on the development of the software (for example, “The software shall be written in Ada.”). These are sometimes known as process requirements.

Some software requirements generate implicit process requirements. The choice of verification technique is one example. Another might be the use of particularly rigorous analysis techniques (such as formal specification methods) to reduce faults which can lead to inadequate reliability. Process requirements may also be imposed directly by the development organization, their customer, or a third party such as a safety regulator [Kot00; Som97].

Functional requirements describe the functions that the software is to execute; for example, formatting some text or modulating a signal. They are sometimes known as capabilities.

Nonfunctional requirements are the ones that act to constrain the solution. Nonfunctional requirements are sometimes known as constraints or quality requirements.

Some requirements represent emergent properties of software—that is, requirements which cannot be addressed by a single component, but which depend for their satisfaction on how all the software components interoperate. The throughput requirement for a call center would, for example, depend on how the telephone system, information system, and the operators all interacted under actual operating conditions. Emergent properties are crucially dependent on the system architecture. [Som05]

Software requirements should be stated as clearly and as unambiguously as possible, and, where appropriate, quantitatively. It is important to avoid vague and unverifiable requirements which depend for their interpretation on subjective judgment (“the software shall be reliable”; “the software shall be user-friendly”). This is particularly important for nonfunctional requirements. Two examples of quantified requirements are the following: a call center’s software must increase the center’s throughput by 20%; and a system shall have a probability of generating a fatal error during any hour of operation of less than 1 * 10-8. The throughput requirement is at a very high level and will need to be used to derive a number of detailed requirements. The reliability requirement will tightly constrain the system architecture. [Dav93; Som05]

In this topic, system means “an interacting combination of elements to accomplish a defined objective. These include hardware, software, firmware, people, information, techniques, facilities, services, and other support elements,” as defined by the International Council on Systems Engineering (INCOSE00).

System requirements are the requirements for the system as a whole. In a system containing software components, software requirements are derived from system requirements.

This section introduces the software requirements process, orienting the remaining five subareas and showing how the requirements process dovetails with the overall software engineering process. [Dav93; Som05]

The objective of this topic is to provide an understanding that the requirements process

• Is not a discrete front-end activity of the software life cycle, but rather a process initiated at the beginning of a project and continuing to be refined throughout the life cycle

• Identifies software requirements as configuration items, and manages them using the same software configuration management practices as other products of the software life cycle processes

• Needs to be adapted to the organization and project context

In particular, the topic is concerned with how the activities of elicitation, analysis, specification, and validation are configured for different types of projects and constraints. The topic also includes activities which provide input into the requirements process, such as marketing and feasibility studies. [Kot00; Rob99; Som97; Som05]

This topic introduces the roles of the people who participate in the requirements process. This process is fundamentally interdisciplinary, and the requirements specialist needs to mediate between the domain of the stakeholder and that of software engineering. There are often many people involved besides the requirements specialist, each of whom has a stake in the software. The stakeholders will vary across projects, but always include users/operators and customers (who need not be the same). [Gog93]

Typical examples of software stakeholders include (but are not restricted to)

• Users: This group comprises those who will operate the software. It is often a heterogeneous group comprising people with different roles and requirements.

• Customers: This group comprises those who have commissioned the software or who represent the software’s target market.

• Market analysts: A mass-market product will not have a commissioning customer, so marketing people are often needed to establish what the market needs and to act as proxy customers.

• Regulators: Many application domains such as banking and public transport are regulated. Software in these domains must comply with the requirements of the regulatory authorities.

• Software engineers: These individuals have a legitimate interest in profiting from developing the software by, for example, reusing components in other products. If, in this scenario, a customer of a particular product has specific requirements which compromise the potential for component reuse, the software engineers must carefully weigh their own stake against those of the customer.

It will not be possible to perfectly satisfy the requirements of every stakeholder, and it is the software engineer’s job to negotiate trade-offs which are both acceptable to the principal stakeholders and within budgetary, technical, regulatory, and other constraints. A prerequisite for this is that all the stakeholders be identified, the nature of their “stake” analyzed, and their requirements elicited. [Dav93; Kot00; Rob99; Som97; You01]

This topic introduces the project management resources required and consumed by the requirements process. It establishes the context for the first subarea (Initiation and scope definition) of the Software Engineering Management KA. Its principal purpose is to make the link between the process activities identified in 2.1 and the issues of cost, human resources, training, and tools. [Rob99; Som97; You01]

This topic is concerned with the assessment of the quality and improvement of the requirements process. Its purpose is to emphasize the key role the requirements process plays in terms of the cost and timeliness of a software product, and of the customer’s satisfaction with it [Som97]. It will help to orient the requirements process with quality standards and process improvement models for software and systems. Process quality and improvement is closely related to both the Software Quality KA and the Software Engineering Process KA. Of particular interest are issues of software quality attributes and measurement, and software process definition. This topic covers

• Requirements process coverage by process improvement standards and models

• Requirements process measures and benchmarking

• Improvement planning and implementation [Kot00; Som97; You01]

3. Requirements Elicitation [Dav93; Gog93; Lou95; Pfl01]

3.1 Requirements Sources [Dav93; Gog93; Pfl01]

• Goals. The term goal (sometimes called “business concern” or “critical success factor”) refers to the overall, high-level objectives of the software. Goals provide the motivation for the software, but are often vaguely formulated. Software engineers need to pay particular attention to assessing the value (relative to priority) and cost of goals. A feasibility study is a relatively low-cost way of doing this. [Lou95].

• Domain knowledge. The software engineer needs to acquire, or have available, knowledge about the application domain. This enables them to infer tacit knowledge that the stakeholders do not articulate, assess the trade-offs that will be necessary between conflicting requirements, and, sometimes, to act as a “user” champion.

• Stakeholders (see topic 2.2 Process actors). Much software has proved unsatisfactory because it has stressed the requirements of one group of stakeholders at the expense of those of others. Hence, software is delivered which is difficult to use or which subverts the cultural or political structures of the customer organization. The software engineer needs to identify, represent, and manage the “viewpoints” of many different types of stakeholders. [Kot00]

• The operational environment. Requirements will be derived from the environment in which the software will be executed. These may be, for example, timing constraints in real-time software or interoperability constraints in an office environment. These must be actively sought out, because they can greatly affect software feasibility and cost, and restrict design choices. [Tha97]

• The organizational environment. Software is often required to support a business process, the selection of which may be conditioned by the structure, culture, and internal politics of the organization. The software engineer needs to be sensitive to these, since, in general, new software should not force unplanned change on the business process.

3.2. Elicitation Techniques [Dav93; Kot00; Lou95; Pfl01]

• Interviews, a “traditional” means of eliciting requirements. It is important to understand the advantages and limitations of interviews and how they should be conducted.

• Scenarios, a valuable means for providing context to the elicitation of user requirements. They allow the software engineer to provide a framework for questions about user tasks by permitting “what if” and “how is this done” questions to be asked. The most common type of scenario is the use case. There is a link here to topic 4.2 (Conceptual modeling) because scenario notations such as use cases and diagrams are common in modeling software.

• Prototypes, a valuable tool for clarifying unclear requirements. They can act in a similar way to scenarios by providing users with a context within which they can better understand what information they need to provide. There is a wide range of prototyping techniques, from paper mock-ups of screen designs to beta-test versions of software products, and a strong overlap of their use for requirements elicitation and the use of prototypes for requirements validation (see topic 6.2 Prototyping).

• Facilitated meetings. The purpose of these is to try to achieve a summative effect whereby a group of people can bring more insight into their software requirements than by working individually. They can brainstorm and refine ideas which may be difficult to bring to the surface using interviews. Another advantage is that conflicting requirements surface early on in a way that lets the stakeholders recognize where there is conflict. When it works well, this technique may result in a richer and more consistent set of requirements than might otherwise be achievable. However, meetings need to be handled carefully (hence the need for a facilitator) to prevent a situation from occurring where the critical abilities of the team are eroded by group loyalty, or the requirements reflecting the concerns of a few outspoken (and perhaps senior) people are favored to the detriment of others.

• Observation. The importance of software context within the organizational environment has led to the adaptation of observational techniques for requirements elicitation. Software engineers learn about user tasks by immersing themselves in the environment and observing how users interact with their software and with each other. These techniques are relatively expensive, but they are instructive because they illustrate that many user tasks and business processes are too subtle and complex for their actors to describe easily.

4. Requirements Analysis [Som05]

• Detect and resolve conflicts between requirements

• Discover the bounds of the software and how it must interact with its environment

• Elaborate system requirements to derive software requirements

The traditional view of requirements analysis has been  that it be reduced to conceptual modeling using one of anumber of analysis methods such as the Structured Analysis and Design Technique (SADT). While conceptual modeling is important, we include the classification of requirements to help inform trade-offs between requirements (requirements classification) and the process of establishing these trade-offs (requirements negotiation). [Dav93]

Care must be taken to describe requirements precisely enough to enable the requirements to be validated, their implementation to be verified, and their costs to be estimated.

4.1. Requirements Classification [Dav93; Kot00; Som05]

Requirements can be classified on a number of dimensions. Examples include

• Whether the requirement is functional or nonfunctional (see topic 1.3 Functional and nonfunctional requirements).

• Whether the requirement is derived from one or more high-level requirements or an emergent property (see topic 1.4 Emergent properties) or is being imposed directly on the software by a stakeholder or some other source.

• Whether the requirement is on the product or the process. Requirements on the process can constrain the choice of contractor, the software engineering process to be adopted, or the standards to be adhered to.

• The requirement priority. In general, the higher the priority, the more essential the requirement is for meeting the overall goals of the software. Often classified on a fixed-point scale such as mandatory, highly desirable, desirable, or optional, the priority often has to be balanced against the cost of development and implementation.

• The scope of the requirement. Scope refers to the extent to which a requirement affects the software and software components. Some requirements, particularly certain nonfunctional ones, have a global scope in that their satisfaction cannot be allocated to a discrete component. Hence, a requirement with global scope may strongly affect the software architecture and the design of many components, whereas one with a narrow scope may offer a number of design choices and have little impact on the satisfaction of other requirements.

• Volatility/stability. Some requirements will change during the life cycle of the software, and even during the development process itself. It is useful if some estimate of the likelihood that a requirement change can be made. For example, in a banking application, requirements for functions to calculate and credit interest to customers’ accounts are likely to be more stable than a requirement to support a particular kind of tax-free account. The former reflect a fundamental feature of the banking domain (that accounts can earn interest), while the latter may be rendered obsolete by a change to government legislation. Flagging potentially volatile requirements can help the software engineer establish a design which is more tolerant of change.

Other classifications may be appropriate, depending upon the organization’s normal practice and the application itself.

There is a strong overlap between requirements classification and requirements attributes (see topic 7.3 Requirements attributes).

4.2. Conceptual Modeling [Dav93; Kot00; Som05]

The development of models of a real-world problem is key to software requirements analysis. Their purpose is to aid in understanding the problem, rather than to initiate design of the solution. Hence, conceptual models comprise models of entities from the problem domain configured to reflect their real-world relationships and dependencies.

Several kinds of models can be developed. These include data and control flows, state models, event traces, user interactions, object models, data models, and many others. The factors that influence the choice of model include

• The nature of the problem. Some types of software demand that certain aspects be analyzed particularly rigorously. For example, control flow and state models are likely to be more important for real-time software than for management information software, while it would usually be the opposite for data models.

• The expertise of the software engineer. It is often more productive to adopt a modeling notation or method with which the software engineer has experience.

• The process requirements of the customer. Customers may impose their favored notation or method, or prohibit any with which they are unfamiliar. This factor can conflict with the previous factor.

• The availability of methods and tools. Notations or methods which are poorly supported by training and tools may not achieve widespread acceptance even if they are suited to particular types of problems.

Note that, in almost all cases, it is useful to start by building a model of the software context. The software context provides a connection between the intended software and its external environment. This is crucial to understanding the software’s context in its operational environment and to identifying its interfaces with the environment.

The issue of modeling is tightly coupled with that of methods. For practical purposes, a method is a notation (or set of notations) supported by a process which guides the application of the notations. There is little empirical evidence to support claims for the superiority of one notation over another. However, the widespread acceptance of a particular method or notation can lead to beneficial industry-wide pooling of skills and knowledge. This is currently the situation with the UML (Unified Modeling Language). (UML04)

Formal modeling using notations based on discrete mathematics, and which are traceable to logical reasoning, have made an impact in some specialized domains. These may be imposed by customers or standards or may offer compelling advantages to the analysis of certain critical functions or components.

This topic does not seek to “teach” a particular modeling style or notation but rather provides guidance on the purpose and intent of modeling.

Two standards provide notations which may be useful in performing conceptual modeling–IEEE Std 1320.1, IDEF0 for functional modeling; and IEEE Std 1320.2, IDEF1X97 (IDEFObject) for information modeling.

4.3. Architectural Design and Requirements Allocation [Dav93; Som05]

At some point, the architecture of the solution must be derived. Architectural design is the point at which the requirements process overlaps with software or systems design and illustrates how impossible it is to cleanly decouple the two tasks. [Som01] This topic is closely related to the Software Structure and Architecture subarea in the Software Design KA. In many cases, the software engineer acts as software architect because the process of analyzing and elaborating the requirements demands that the components that will be responsible for satisfying the requirements be identified. This is requirements allocation–the assignment, to components, of the responsibility for satisfying requirements.

IEEE Std 1471-2000, Recommended Practice for Architectural Description of Software Intensive Systems, suggests a multiple-viewpoint approach to describing the architecture of systems and their software items. (IEEE1471-00)

Another term commonly used for this sub-topic is “conflict resolution.” This concerns resolving problems with requirements where conflicts occur between two stakeholders requiring mutually incompatible features, between requirements and resources, or between functional and non-functional requirements, for example. [Kot00, Som97] In most cases, it is unwise for the software engineer to make a unilateral decision, and so it becomes necessary to consult with the stakeholder(s) to reach a consensus on an appropriate trade-off. It is often important for contractual reasons that such decisions be traceable back to the customer. We have classified this as a software requirements analysis topic because problems emerge as the result of analysis. However, a strong case can also be made for considering it a requirements validation topic.

For most engineering professions, the term “specification” refers to the assignment of numerical values or limits to a product’s design goals. (Vin90) Typical physical systems have a relatively small number of such values. Typical software has a large number of requirements, and the emphasis is shared between performing the numerical quantification and managing the complexity of interaction among the large number of requirements. So, in software engineering jargon, “software requirements specification” typically refers to the production of a document, or its electronic equivalent, which can be systematically reviewed, evaluated, and approved. For complex systems, particularly those involving substantial non-software components, as many as three different types of documents are produced: system definition, system requirements, and software requirements. For simple software products, only the third of these is required. All three documents are described here, with the understanding that they may be combined as appropriate. A description of systems engineering can be found in Chapter 12, Related Disciplines of Software Engineering.

This document (sometimes known as the user requirements document or concept of operations) records the system requirements. It defines the high-level system requirements from the domain perspective. Its readership includes representatives of the system users/customers (marketing may play these roles for market-driven software), so its content must be couched in terms of the domain. The document lists the system requirements along with background information about the overall objectives for the system, its target environment and a statement of the constraints, assumptions, and non-functional requirements. It may include conceptual models designed to illustrate the system context, usage scenarios and the principal domain entities, as well as data, information, and workflows. IEEE Std 1362, Concept of Operations Document, provides advice on the preparation and content of such a document. (IEEE1362-98)

5.2. System Requirements Specification [Dav93; Kot00; Rob99; Tha97]

Developers of systems with substantial software and non-software components, a modern airliner, for example, often separate the description of system requirements from the description of software requirements. In this view, system requirements are specified, the software requirements are derived from the system requirements, and then the requirements for the software components are specified. Strictly speaking, system requirements specification is a systems engineering activity and falls outside the scope of this Guide. IEEE Std 1233 is a guide for developing system requirements. (IEEE1233-98)

5.3. Software Requirements Specification [Kot00; Rob99]

Software requirements specification establishes the basis for agreement between customers and contractors or suppliers (in market-driven projects, these roles may be played by the marketing and development divisions) on what the software product is to do, as well as what it is not expected to do. For non-technical readers, the software requirements specification document is often accompanied by a software requirements definition document.

Software requirements specification permits a rigorous assessment of requirements before design can begin and reduces later redesign. It should also provide a realistic basis for estimating product costs, risks, and schedules.

Organizations can also use a software requirements specification document to develop their own validation and verification plans more productively.

Software requirements specification provides an informed basis for transferring a software product to new users or new machines. Finally, it can provide a basis for software enhancement.

Software requirements are often written in natural language, but, in software requirements specification, this may be supplemented by formal or semi-formal descriptions. Selection of appropriate notations permits particular requirements and aspects of the software architecture to be described more precisely and concisely than natural language. The general rule is that notations should be used which allow the requirements to be described as precisely as possible. This is particularly crucial for safety-critical and certain other types of dependable software. However, the choice of notation is often constrained by the training, skills and preferences of the document’s authors and readers.

A number of quality indicators have been developed which can be used to relate the quality of software requirements specification to other project variables such as cost, acceptance, performance, schedule, reproducibility, etc. Quality indicators for individual software requirements specification statements include imperatives, directives, weak phrases, options, and continuances. Indicators for the entire software requirements specification document include size, readability, specification, depth, and text structure. [Dav93; Tha97] (Ros98)

IEEE has a standard, IEEE Std 830 [IEEE830-98], for the production and content of the software requirements specification. Also, IEEE 1465 (similar to ISO/IEC 12119) is a standard treating quality requirements in software packages. (IEEE1465-98)

6. Requirements validation [Dav93]

6.1. Requirements Reviews [Kot00; Som05; Tha97]

Perhaps the most common means of validation is by inspection or reviews of the requirements document(s). A group of reviewers is assigned a brief to look for errors, mistaken assumptions, lack of clarity, and deviation from standard practice. The composition of the group that conducts the review is important (at least one representative of the customer should be included for a customer-driven project, for example), and it may help to provide guidance on what to look for in the form of checklists.

Reviews may be constituted on completion of the system definition document, the system specification document, the software requirements specification document, the baseline specification for a new release, or at any other step in the process. IEEE Std 1028 provides guidance on conducting such reviews. (IEEE1028-97) Reviews are also covered in the Software Quality KA, topic 2.3 Reviews and Audits.

6.2. Prototyping [Dav93; Kot00; Som05; Tha97]

Prototyping is commonly a means for validating the software engineer’s interpretation of the software requirements, as well as for eliciting new requirements. As with elicitation, there is a range of prototyping techniques and a number of points in the process where prototype validation may be appropriate. The advantage of prototypes is that they can make it easier to interpret the software engineer’s assumptions and, where needed, give useful feedback on why they are wrong. For example, the dynamic behavior of a user interface can be better understood through an animated prototype than through textual description or graphical models. There are also disadvantages, however. These include the danger of users’ attention being distracted from the core underlying functionality by cosmetic issues or quality problems with the prototype. For this reason, several people recommend prototypes which avoid software, such as flip-chart-based mockups. Prototypes may be costly to develop. However, if they avoid the wastage of resources caused by trying to satisfy erroneous requirements, their cost can be more easily justified.

6.3. Model Validation [Dav93; Kot00; Tha97]

It is typically necessary to validate the quality of the models developed during analysis. For example, in object models, it is useful to perform a static analysis to verify that communication paths exist between objects which, in the stakeholders’ domain, exchange data. If formal specification notations are used, it is possible to use formal reasoning to prove specification properties.

6.4. Acceptance Tests [Dav93]

An essential property of a software requirement is that it should be possible to validate that the finished product satisfies it. Requirements which cannot be validated are really just “wishes.” An important task is therefore planning how to verify each requirement. In most cases, designing acceptance tests does this.

Identifying and designing acceptance tests may be difficult for non-functional requirements (see topic 1.3 Functional and Non-functional Requirements). To be validated, they must first be analyzed to the point where they can be expressed quantitatively.

Additional information can be found in the Software Testing KA, sub-topic 2.2.4 Conformance testing.

The first level of decomposition of subareas presented in this KA may seem to describe a linear sequence of activities. This is a simplified view of the process. [Dav93]

The requirements process spans the whole software life cycle. Change management and the maintenance of the requirements in a state which accurately mirrors the software to be built, or that has been built, are key to the success of the software engineering process. [Kot00; Lou95]

Not every organization has a culture of documenting and managing requirements. It is frequent in dynamic start-up companies, driven by a strong “product vision” and limited resources, to view requirements documentation as an unnecessary overhead. Most often, however, as these companies expand, as their customer base grows, and as their product starts to evolve, they discover that they need to recover the requirements that motivated product features in order to assess the impact of proposed changes. Hence, requirements documentation and change management are key to the success of any requirements process.

7.1. Iterative Nature of the Requirements Process [Kot00; You01]

There is general pressure in the software industry for ever shorter development cycles, and this is particularly pronounced in highly competitive market-driven sectors. Moreover, most projects are constrained in some way by their environment, and many are upgrades to, or revisions of, existing software where the architecture is a given. In practice, therefore, it is almost always impractical to implement the requirements process as a linear, deterministic process in which software requirements are elicited from the stakeholders, baselined, allocated, and handed over to the software development team. It is certainly a myth that the requirements for large software projects are ever perfectly understood or perfectly specified. [Som97]

Instead, requirements typically iterate towards a level of quality and detail which is sufficient to permit design and procurement decisions to be made. In some projects, this may result in the requirements being baselined before all their properties are fully understood. This risks expensive rework if problems emerge late in the software engineering process. However, software engineers are necessarily constrained by project management plans and must therefore take steps to ensure that the “quality” of the requirements is as high as possible given the available resources. They should, for example, make explicit any assumptions which underpin the requirements, as well as any known problems.

In almost all cases, requirements understanding continues to evolve as design and development proceeds. This often leads to the revision of requirements late in the life cycle. Perhaps the most crucial point in understanding requirements engineering is that a significant proportion of the requirements will change. This is sometimes due to errors in the analysis, but it is frequently an inevitable consequence of change in the “environment”: for example, the customer’s operating or business environment, or the market into which software must sell. Whatever the cause, it is important to recognize the inevitability of change and take steps to mitigate its effects. Change has to be managed by ensuring that proposed changes go through a defined review and approval process, and, by applying careful requirements tracing, impact analysis, and software configuration management (see the Software Configuration Management KA). Hence, the requirements process is not merely a front-end task in software development, but spans the whole software life cycle. In a typical project, the software requirements activities evolve over time from elicitation to change management.

7.2. Change Management [Kot00]

Change management is central to the management of requirements. This topic describes the role of change management, the procedures that need to be in place, and the analysis that should be applied to proposed changes. It has strong links to the Software Configuration Management KA.

7.3. Requirements Attributes [Kot00]

Requirements should consist not only of a specification of what is required, but also of ancillary information which helps manage and interpret the requirements. This should include the various classification dimensions of the requirement (see topic 4.1 Requirements Classification) and the verification method or acceptance test plan. It may also include additional information such as a summary rationale for each requirement, the source of each requirement, and a change history. The most important requirements attribute, however, is an identifier which allows the requirements to be uniquely and unambiguously identified.

7.4. Requirements Tracing [Kot00]

Requirements tracing is concerned with recovering the source of requirements and predicting the effects of requirements. Tracing is fundamental to performing impact analysis when requirements change. A requirement should be traceable backwards to the requirements and stakeholders which motivated it (from a software requirement back to the system requirement(s) that it helps satisfy, for example). Conversely, a requirement should be traceable forwards into the requirements and design entities that satisfy it (for example, from a system requirement into the software requirements that have been elaborated from it, and on into the code modules that implement it).

The requirements tracing for a typical project will form a complex directed acyclic graph (DAG) of requirements.

As a practical matter, it is typically useful to have some concept of the “volume” of the requirements for a particular software product. This number is useful in evaluating the “size” of a change in requirements, in estimating the cost of a development or maintenance task, or simply for use as the denominator in other measurements. Functional Size Measurement (FSM) is a technique for evaluating the size of a body of functional requirements. IEEE Std 14143.1 defines the concept of FSM. [IEEE14143.1-00] Standards from ISO/IEC and other sources describe particular FSM methods.

Additional information on size measurement and standards will be found in the Software Engineering Process KA.

• [Dav93] A.M. Davis, Software Requirements: Objects, Functions and States, Prentice Hall, 1993.

• [Gog93] J. Goguen and C. Linde, “Techniques for Requirements Elicitation,” presented at International Symposium on Requirements Engineering, 1993.

• [IEEE830-98] IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, IEEE, 1998.

• (IEEE14143.1-00) IEEE Std 14143.1-2000//ISO/IEC14143-1:1998, Information Technology—Software Measurement—Functional Size Measurement—Part 1: Definitions of Concepts, IEEE, 2000.

• [Kot00] G. Kotonya and I. Sommerville, Requirements Engineering: Processes and Techniques, John Wiley & Sons, 2000.

• [Lou95] P. Loucopulos and V. Karakostas, Systems Requirements Engineering, McGraw-Hill, 1995.

• [Pfl01] S.L. Pfleeger, “Software Engineering: Theory and Practice,” second ed., Prentice Hall, 2001, Chap. 4.

• [Rob99] S. Robertson and J. Robertson, Mastering the Requirements Process, Addison-Wesley, 1999.

• [Som97] I. Sommerville and P. Sawyer, Requirements Engineering: A Good Practice Guide, John Wiley & Sons, 1997, Chap. 1-2.

• [Som05] I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005.

• [Tha97] R.H. Thayer and M. Dorfman, eds., Software Requirements Engineering, IEEE Computer Society Press, 1997, pp. 176-205, 389-404.

• [You01] R.R. You, Effective Requirements Practices, Addison-Wesley, 2001.

• (Ale02) I. Alexander and R. Stevens, Writing Better Requirements, Addison-Wesley, 2002.

• (Ard97) M. Ardis, “Formal Methods for Telecommunication System Requirements: A Survey of Standardized Languages,” Annals of Software Engineering, vol. 3, 1997.

• (Ber97) V. Berzins et al., “A Requirements Evolution Model for Computer Aided Prototyping,” presented at Ninth IEEE International Conference on Software Engineering and Knowledge Engineering, Knowledge Systems Institute, 1997.

• (Bey95) H. Beyer and K. Holtzblatt, “Apprenticing with the Customer,” Communications of the ACM, vol. 38, iss. 5, May 1995, pp. 45-52.

• (Bru95) G. Bruno and R. Agarwal, “Validating Software Requirements Using Operational Models,” presented at Second Symposium on Software Quality Techniques and Acquisition Criteria, 1995.

• (Bry94) E. Bryne, “IEEE Standard 830: Recommended Practice for Software Requirements Specification,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Buc94) G. Bucci et al., “An Object-Oriented Dual Language for Specifying Reactive Systems,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Bus95) D. Bustard and P. Lundy, “Enhancing Soft Systems Analysis with Formal Modeling,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Che94) M. Chechik and J. Gannon, “Automated Verification of Requirements Implementation,” presented at Proceedings of the International Symposium on Software Testing and Analysis, special issue, 1994.

• (Chu95) L. Chung and B. Nixon, “Dealing with Non-Functional Requirements: Three Experimental Studies of a Process-Oriented Approach,” presented at Seventeenth IEEE International Conference on Software Engineering, 1995.

• (Cia97) P. Ciancarini et al., “Engineering Formal Requirements: An Analysis and Testing Method for Z Documents,” Annals of Software Engineering, vol. 3, 1997.

• (Cre94) R. Crespo, “We Need to Identify the Requirements of the Statements of Non-Functional Requirements,” presented at International Workshop on Requirements Engineering: Foundations of Software Quality, 1994.

• (Cur94) P. Curran et al., “BORIS-R Specification of the Requirements of a Large-Scale Software Intensive System,” presented at Requirements Elicitation for Software-Based Systems, 1994.

• (Dar97) R. Darimont and J. Souquieres, “Reusing Operational Requirements: A Process-Oriented Approach,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (Dav94) A. Davis and P. Hsia, “Giving Voice to Requirements Engineering: Guest Editors’ Introduction,” IEEE Software, vol. 11, iss. 2, March 1994, pp. 12-16.

• (Def94) J. DeFoe, “Requirements Engineering Technology in Industrial Education,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Dem97) E. Demirors, “A Blackboard Framework for Supporting Teams in Software Development,” presented at Ninth IEEE International Conference on Software Engineering and Knowledge Engineering, Knowledge Systems Institute, 1997.

• (Die95) M. Diepstraten, “Command and Control System Requirements Analysis and System Requirements Specification for a Tactical System,” presented at First IEEE International Conference on Engineering of Complex Computer Systems, 1995.

• (Dob94) J. Dobson and R. Strens, “Organizational Requirements Definition for Information Technology,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Duf95) D. Duffy et al., “A Framework for Requirements Analysis Using Automated Reasoning,” presented at Seventh International Conference on Advanced Information Systems Engineering, 1995.

• (Eas95) S. Easterbrook and B. Nuseibeh, “Managing Inconsistencies in an Evolving Specification,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Edw95) M. Edwards et al., “RECAP: A Requirements Elicitation, Capture, and Analysis Process Prototype Tool for Large Complex Systems,” presented at First IEEE International Conference on Engineering of Complex Computer Systems, 1995.

• (ElE95) K. El-Emam and N. Madhavji, “Requirements Engineering Practices in Information Systems Development: A Multiple Case Study,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Fai97) R. Fairley and R. Thayer, “The Concept of Operations: The Bridge from Operational Requirements to Technical Specifications,” Annals of Software Engineering, vol. 3, 1997.

• (Fic95) S. Fickas and M. Feather, “Requirements Monitoring in Dynamic Environments,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Fie95) R. Fields et al., “A Task-Centered Approach to Analyzing Human Error Tolerance Requirements,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Gha94) J. Ghajar-Dowlatshahi and A. Varnekar, “Rapid Prototyping in Requirements Specification Phase of Software Systems,” presented at Fourth International Symposium on Systems Engineering, National Council on Systems Engineering, 1994.

• (Gib95) M. Gibson, “Domain Knowledge Reuse During Requirements Engineering,” presented at Seventh International Conference on Advanced Information Systems Engineering (CAiSE ’95), 1995.

• (Gol94) L. Goldin and D. Berry, “AbstFinder: A Prototype Abstraction Finder for Natural Language Text for Use in Requirements Elicitation: Design, Methodology and Evaluation,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Got97) O. Gotel and A. Finkelstein, “Extending Requirements Traceability: Lessons Learned from an Industrial Case Study,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (Hei96) M. Heimdahl, “Errors Introduced during the TACS II Requirements Specification Effort: A Retrospective Case Study,” presented at Eighteenth IEEE International Conference on Software Engineering, 1996.

• (Hei96a) C. Heitmeyer et al., “Automated Consistency Checking Requirements Specifications,” ACM Transactions on Software Engineering and Methodology, vol. 5, iss. 3, July 1996, pp. 231-261.

• (Hol95) K. Holtzblatt and H. Beyer, “Requirements Gathering: The Human Factor,” Communications of the ACM, vol. 38, iss. 5, May 1995, pp. 31-32.

• (Hud96) E. Hudlicka, “Requirements Elicitation with Indirect Knowledge Elicitation Techniques: Comparison of Three Methods,” presented at Second IEEE International Conference on Requirements Engineering, 1996.

• (Hug94) K. Hughes et al., “A Taxonomy for Requirements Analysis Techniques,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Hug95) J. Hughes et al., “Presenting Ethnography in the Requirements Process,” presented at Second IEEE International Symposium on Requirements Engineering, 1995.

• (Hut94) A.T.F. Hutt, ed., Object Analysis and Design - Comparison of Methods. Object Analysis and Design - Description of Methods, John Wiley & Sons, 1994.

• (INCOSE00) INCOSE, How To: Guide for all Engineers, Version 2, International Council on Systems Engineering, 2000.

• (Jac95) M. Jackson, Software Requirements and Specifications, Addison-Wesley, 1995.

• (Jac97) M. Jackson, “The Meaning of Requirements,” Annals of Software Engineering, vol. 3, 1997.

• (Jon96) S. Jones and C. Britton, “Early Elicitation and Definition of Requirements for an Interactive Multimedia Information System,” presented at Second IEEE International Conference on Requirements Engineering, 1996.

• (Kir96) T. Kirner and A. Davis, “Nonfunctional Requirements for Real-Time Systems,” Advances in Computers, 1996.

• (Kle97) M. Klein, “Handling Exceptions in Collaborative Requirements Acquisition,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (Kos97) R. Kosman, “A Two-Step Methodology to Reduce Requirements Defects,” Annals of Software Engineering, vol. 3, 1997.

• (Kro95) J. Krogstie et al., “Towards a Deeper Understanding of Quality in Requirements Engineering,” presented at Seventh International Conference on Advanced Information Systems Engineering (CAiSE ’95), 1995.

• (Lal95) V. Lalioti and B. Theodoulidis, “Visual Scenarios for Validation of Requirements Specification,” presented at Seventh International Conference on Software Engineering and Knowledge Engineering, Knowledge Systems Institute, 1995.

• (Lam95) A. v. Lamsweerde et al., “Goal-Directed Elaboration of Requirements for a Meeting Scheduler: Problems and Lessons Learnt,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Lei97) J. Leite et al., “Enhancing a Requirements Baseline with Scenarios,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (Ler97) F. Lerch et al.., “Using Simulation-Based Experiments for Software Requirements Engineering,” Annals of Software Engineering, vol. 3, 1997.

• (Lev94) N. Leveson et al., “Requirements Specification for Process-Control Systems,” IEEE Transactions on Software Engineering, vol. 20, iss. 9, September 1994, pp. 684-707.

• (Lut96a) R. Lutz and R. Woodhouse, “Contributions of SFMEA to Requirements Analysis,” presented at Second IEEE International Conference on Requirements Engineering, 1996.

• (Lut97) R. Lutz and R. Woodhouse, “Requirements Analysis Using Forward and Backward Search,” Annals of Software Engineering, vol. 3, 1997.

• (Mac96) L. Macaulay, Requirements Engineering, Springer-Verlag, 1996.

• (Mai95) N. Maiden et al., “Computational Mechanisms for Distributed Requirements Engineering,” presented at Seventh International Conference on Software Engineering and Knowledge Engineering, Knowledge Systems Institute, 1995.

• (Mar94) B. Mar, “Requirements for Development of Software Requirements,” presented at Fourth International Symposium on Systems Engineering, 1994.

• (Mas97) P. Massonet and A. v. Lamsweerde, “Analogical Reuse of Requirements Frameworks,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (McF95) I. McFarland and I. Reilly, “Requirements Traceability in an Integrated Development Environment,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Mea94) N. Mead, “The Role of Software Architecture in Requirements Engineering,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Mos95) D. Mostert and S. v. Solms, “A Technique to Include Computer Security, Safety, and Resilience Requirements as Part of the Requirements Specification,” Journal of Systems and Software, vol. 31, iss. 1, October 1995, pp. 45-53.

• (Myl95) J. Mylopoulos et al., “Multiple Viewpoints Analysis of Software Specification Process,” IEEE Transactions on Software Engineering, 1995.

• (Nis92) K. Nishimura and S. Honiden, “Representing and Using Non-Functional Requirements: A Process-Oriented Approach,” IEEE Transactions on Software Engineering, December 1992.

• (Nis97) H. Nissen et al., “View-Directed Requirements Engineering: A Framework and Metamodel,” presented at Ninth IEEE International Conference on Software Engineering and Knowledge Engineering, Knowledge Systems Institute, 1997.

• (OBr96) L. O’Brien, “From Use Case to Database: Implementing a Requirements Tracking System,” Software Development, vol. 4, iss. 2, February 1996, pp. 43-47.

• (UML04) Object Management Group, Unified Modeling Language, www.uml.org, 2004.

• (Opd94) A. Opdahl, “Requirements Engineering for Software Performance,” presented at International Workshop on Requirements Engineering: Foundations of Software Quality, 1994.

• (Pin96) F. Pinheiro and J. Goguen, “An Object-Oriented Tool for Tracing Requirements,” IEEE Software, vol. 13, iss. 2, March 1996, pp. 52-64.

• (Pla96) G. Playle and C. Schroeder, “Software Requirements Elicitation: Problems, Tools, and Techniques,” Crosstalk: The Journal of Defense Software Engineering, vol. 9, iss. 12, December 1996, pp. 19-24.

• (Poh94) K. Pohl et al., “Applying AI Techniques to Requirements Engineering: The NATURE Prototype,” presented at IEEE Workshop on Research Issues in the Intersection Between Software Engineering and Artificial Intelligence, 1994.

• (Por95) A. Porter et al., “Comparing Detection Methods for Software Requirements Inspections: A Replicated Experiment,” IEEE Transactions on Software Engineering, vol. 21, iss. 6, June 1995, pp. 563-575.

• (Pot95) C. Potts et al., “An Evaluation of Inquiry-Based Requirements Analysis for an Internet Server,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Pot97) C. Potts and I. Hsi, “Abstraction and Context in Requirements Engineering: Toward a Synthesis,” Annals of Software Engineering, vol. 3, 1997. (Pot97a) C. Potts and W. Newstetter, “Naturalistic Inquiry and Requirements Engineering: Reconciling Their Theoretical Foundations,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (Ram95) B. Ramesh et al., “Implementing Requirements Traceability: A Case Study,” presented at Second International Symposium on Requirements Engineering, 1995.

• (Reg95) B. Regnell et al., “Improving the Use Case Driven Approach to Requirements Engineering,” presented at Second IEEE International Symposium on Requirements Engineering, 1995.

• (Reu94) H. Reubenstein, “The Role of Software Architecture in Software Requirements Engineering,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Rob94) J. Robertson and S. Robertson, Complete Systems Analysis, Vol. 1 and 2, Prentice Hall, 1994.

• (Rob94a) W. Robinson and S. Fickas, “Supporting Multi-Perspective Requirements Engineering,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Ros98) L. Rosenberg, T.F. Hammer, and L.L. Huffman, “Requirements, testing and metrics,” presented at 15th Annual Pacific Northwest Software Quality Conference, 1998.

• (Sch94) W. Schoening, “The Next Big Step in Systems Engineering Tools: Integrating Automated Requirements Tools with Computer Simulated Synthesis and Test,” presented at Fourth International Symposium on Systems Engineering, 1994.

• (She94) M. Shekaran, “The Role of Software Architecture in Requirements Engineering,” presented at IEEE International Conference on Requirements Engineering, 1994.

• (Sid97) J. Siddiqi et al., “Towards Quality Requirements Via Animated Formal Specifications,” Annals of Software Engineering, vol. 3, 1997.

• (Span97) G. Spanoudakis and A. Finkelstein, “Reconciling Requirements: A Method for Managing Interference, Inconsistency, and Conflict,” Annals of Software Engineering, vol. 3, 1997.

• (Ste94) R. Stevens, “Structured Requirements,” presented at Fourth International Symposium on Systems Engineering, 1994.

• (Vin90) W.G. Vincenti, What Engineers Know and How They Know It - Analytical Studies form Aeronautical History, John Hopkins University Press, 1990.

• (Wei03) K. Weigers, Software Requirements, second ed., Microsoft Press, 2003.

• (Whi95) S. White and M. Edwards, “A Requirements Taxonomy for Specifying Complex Systems,” presented at First IEEE International Conference on Engineering of Complex Computer Systems, 1995.

• (Wil99) B. Wiley, Essential System Requirements: A Practical Guide to Event-Driven Methods, Addison- Wesley, 1999.

• (Wyd96) T. Wyder, “Capturing Requirements With Use Cases,” Software Development, vol. 4, iss. 2, February 1996, pp. 36-40.

• (Yen97) J. Yen and W. Tiao, “A Systematic Tradeoff Analysis for Conflicting Imprecise Requirements,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (Yu97) E. Yu, “Towards Modeling and Reasoning Support for Early-Phase Requirements Engineering,” presented at IEEE International Symposium on Requirements Engineering, 1997.

• (Zav96) P. Zave and M. Jackson, “Where Do Operations Come From? A Multiparadigm Specification Technique,” IEEE Transactions on Software Engineering,, vol. 22, iss. 7, July 1996, pp. 508-528.

• (IEEE830-98) IEEE Std 830-1998, IEEE Recommended Practice for Software Requirements Specifications, IEEE, 1998.

• (IEEE1028-97) IEEE Std 1028-1997 (R2002), IEEE Standard for Software Reviews, IEEE, 1997.

• (IEEE1233-98) IEEE Std 1233-1998, IEEE Guide for Developing System Requirements Specifications, 1998.

• (IEEE1320.1-98) IEEE Std 1320.1-1998, IEEE Standard for Functional Modeling Language-Syntax and Semantics for IDEF0, IEEE, 1998.

• (IEEE1320.2-98) IEEE Std 1320.2-1998, IEEE Standard for Conceptual Modeling Language-Syntax and Semantics for IDEFIX97 (IDEFObjetct), IEEE, 1998.

• (IEEE1362-98) IEEE Std 1362-1998, IEEE Guide for Information Technology-System Definition-Concept of Operations (ConOps) Document, IEEE, 1998.

• (IEEE1465-98) IEEE Std 1465-1998//ISO/IEC12119:1994, IEEE Standard Adoption of International Standard ISO/IEC12119:1994(E), Information Technology-Software Packages-Quality requirements and testing, IEEE, 1998.

• (IEEEP1471-00) IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Descriptionos Software Intensive Systems, Architecture Working Group of the Software Engineering Standards Committee, 2000.

• (IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology- Software Life Cycle Processes, IEEE, 1996.

• (IEEE14143.1-00) IEEE Std 14143.1-2000//ISO/IEC14143-1:1998, Information Technology-Software Measurement-Functional Size Measurement-Part 1: Definitions of Concepts, IEEE, 2000.