A Framework for Software Product Line Practice, Version 5.0

Requirements Engineering

"The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements . . . No other part of the work so cripples the resulting system if done wrong. No other part is as difficult to rectify later" [Brooks 1987a].

So wrote Fred Brooks in 1987, and so it remains today [Davis 1990a, Faulk 1997a]. "The inability to produce complete, correct, and unambiguous software requirements is still considered the major cause of software failure today" [Dorfman 1997a].

Requirements are statements of what the system must do, how it must behave, the properties it must exhibit, the qualities it must possess, and the constraints that the system and its development must satisfy. The Institute of Electrical and Electronics Engineers (IEEE) defines a requirement as

a condition or capability needed by a user to solve a problem or achieve an objective
a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document
a documented representation of a condition or capability as in definition 1 or 2 [IEEE 1990a]

Requirements engineering emphasizes the use of systematic and repeatable techniques that ensure the completeness, consistency, and relevance of the system requirements [Sommerville 1997a]. Specifically, requirements engineering encompasses requirements elicitation, analysis, specification, verification, and management, where

Requirements elicitation is the process of discovering, reviewing, documenting, and understanding the user's needs and constraints for the system.
Requirements analysis is the process of refining the user's needs and constraints.
Requirements specification is the process of documenting the user's needs and constraints clearly and precisely.
Requirements verification is the process of ensuring that the system requirements are complete, correct, consistent, and clear.
Requirements management is the process of scheduling, coordinating, and documenting the requirements engineering activities (that is, elicitation, analysis, specification, and verification) [Dorfman 1997a].

Requirements engineering is complex because of the three roles involved in producing even a single requirement: the requestor (referred to as the "user" in the IEEE definition), the developer (who will design and implement the system), and the author (who will document the requirements). Typically, the requestor understands the problem to be solved by the system but not how to develop a system. The developer understands the tools and techniques required to construct and maintain a system but not the problem to be solved by that system. The author needs to create a statement that communicates unambiguously to the developer what the requestor desires. Hence, requirements address a fundamental communications problem.

The communications problem is further compounded by the number and diversity of system requestors. In practice, any system stakeholder has needs and expectations (that is, requirements) for the system. The role of system stakeholder is played by any of the various people or systems involved in or affected by a system's development. This group includes executives (who know the organization's business goals and constraints), end users (who know how the products will be used), marketers (who know the market demands), technical managers (who know the available personnel), and developers (who know the available tools and technology). It can potentially include legal experts, government agencies, and insurance experts. Successful requirements engineering depends on the identification and solicitation of the appropriate community of stakeholders.

Reconciling the diverse needs and expectations of the various system stakeholders necessitates tradeoffs–that is, decisions between potentially conflicting requirements from different stakeholders. Tradeoffs require mechanisms for capturing and analyzing the different stakeholder requirements, for recognizing the conflicting requirements of different stakeholders, for deciding among those conflicting requirements, and for recording the results of those decisions. Tradeoffs are captured as system decisions that are linked to the affected requirements.

Requirements are pervasive, continuously affecting all development and maintenance phases of a system's development by providing the primary information needed during them. The requirements form a trigger mechanism for the development and maintenance efforts. Testing, for instance, depends on a precise statement of quality and behavioral requirements to define the standard of correctness against which to test.

The longer the system's lifetime, the more it is exposed to changes in the requirements that result from changes in the needs and concerns of its stakeholders. For example, the end user's demands can change as a result of new features offered by a competing organization's products. The organization's business goals and constraints can change as a result of market demands, new laws, or new insurance regulations. New technologies and software tools such as operating systems can change the way the system is constructed. Such changes require mechanisms for managing them–that is, a requirements-change-management process. That process is based on the traceability links between the requirements and the system work products and between the requirements and the related decisions and tradeoffs.

The following sections describe requirements engineering for products: Core Asset Development describes other kinds of requirements that also need to be managed for a software product line, such as the production constraints.

Aspects Peculiar to Product Lines

Product line requirements constitute an important and tangible core asset. They define the products in the product line together with the features of and the constraints on those products. These requirements are tightly coupled with the product line's scope definition and evolve together [Clements 2002c, p. 180]. Requirements common across the product line are written with variation points that can be filled in or exercised to create product-specific requirements. These variation points may be small, such as replacing a symbolic name such as "max_nbr_of_users" with a value such as "150," or may be substantial, such as leaving a placeholder for an entire specification of part of the behavior. Sometimes the variation point will map to null for a product, corresponding to a feature that the product does not have. And there must be some mechanism by which the complete set of requirements for a particular product (common plus unique) can be produced quickly and easily, implying that the product-specific requirements are stored as a set of deltas relative to the product-line-wide requirements specification.

Requirements engineering for a product line differs from requirements engineering for single systems as follows:

Requirements elicitation for a product line must capture anticipated variations explicitly over the foreseeable lifetime of the product line. This means that the community of stakeholders is probably larger than for single-system requirements elicitation and may well include domain experts, market experts, and others. Requirements elicitation focuses on the scope, explicitly capturing the anticipated variation by the application of domain analysis techniques, the incorporation of existing domain analysis models, and the incorporation of use cases that capture the variations that are expected to occur over the lifetime of the product line (e.g., change cases [Ecklund 1996a] and use case variation points [Jacobson 1997a]).
Requirements analysis for a product line involves finding commonalities and identifying variations. It may also involve a more vigorous feedback mechanism to the requestors, pointing out where a particular system might achieve economies if it could use more common requirements. And requirements analysis has the product line scope as one of its inputs–an artifact that does not exist outside the product line context. Requirements analysis includes a commonality and variability analysis (a technique used frequently in domain analysis) on the elicited product line requirements to identify the opportunities for large-grained reuse within the product line. Two such techniques are feature-oriented domain analysis (FODA) [Kang 1990a] and use cases [Jacobson 1997a].
Requirements specification now includes documentation of a product-line-wide set of requirements and product-specific requirements. The product-line-wide requirements include symbolic placeholders that the various product-specific requirements documents fill in, expand, or instantiate.
Requirements verification now includes a broader reviewer pool and occurs in stages. First, the common product line requirements must be verified. Later, as each product comes on the scene (or is updated), its product-specific requirements must be verified. But the product-line-wide requirements must also be verified to make sure that they make sense for this product.
Requirements management must now make allowances for the dual nature of the requirements engineering process and the staged (common, specific) nature of the activity. Change-management policies must provide a formal mechanism for proposing changes in the product line and supporting the systematic assessment of how the proposed changes will impact the product line. Change-management policies govern how changes in the product line requirements are proposed, analyzed, and reviewed. The coupling between the product line requirements and the core assets is leveraged by the use of traceability links between those requirements and their associated core assets. Changes in the requirements can then trigger the appropriate changes in the related core assets [Sommerville 1997a]. The "Configuration Management" practice area describes change management in more detail.

Application to Core Asset Development

First of all, the requirements artifacts produced by requirements engineering are important core assets in their own right. Beyond that, requirements engineering creates the product line requirements that feed the development and acquisition of other core assets. The requirements artifacts will help to

determine the feasibility and refine the scope and business case of a product line. The initial version of the business case is frequently based on an informal notion of the scope. Requirements engineering refines the scope, and hence the business case, by determining more precisely the requirements for the product line. That more precise definition of the product line provides input to the business case activity for a correspondingly more precise determination of that product line's feasibility.
lay the groundwork for the product line architecture, which must accommodate the commonalities and variabilities identified in the requirements
ensure that the other core assets support the anticipated variations
determine the schedules and budgets for the product line and its products
create the test cases and other test artifacts for products in the product line

A significant difference in requirements engineering for product lines involves a rapid, initial pass through the requirements for key stakeholders to initiate early design work, capturing the high-level requirements that affect the initial design (that is, the architecturally significant requirements [Jacobson 1997a]). The purpose of this pass is to compress the time to initial delivery and to demonstrate the feasibility of and establish the credibility of the product line approach–in short, to provide an early justification of the investment [Graham 1998a]. Although this early justification is desirable in single-product development, it is more critical for a software product line.

Application to Product Development

Requirements engineering plays a key role in

determining the feasibility of producing a particular product as part of the product line. You can use a statement of the requirements specific to that candidate product to help estimate the cost of developing the product.
the production, testing, and deployment of the particular product. Requirements play a role in these activities just as they do for single-system development.
the evolution of the product line (that is, the incorporation of changes) that results from that product development. Product-specific requirements often "grow up" to become product line requirements if they can be slightly generalized or if they pop up in more than one product. That is the primary mechanism for the evolution of software product lines over time.

To expand on the first point, determining the feasibility of an additional product in a product line is an ongoing activity that is part of building the business case for that product. The initial version of that business case is frequently based on an informal description of the prospective product. Requirements engineering activities–particularly elicitation and analysis–support the business case for the product by determining more precisely the requirements for that product. The product line requirements guide the elicitation of the specific requirements for that product. Requirements analysis determines the variance between the product line and the product-specific requirements. That variance provides input to the business case activity for a correspondingly more precise cost estimate for building the specific product as part of the product line (that is, determination of that product's feasibility).

Example Practices

Domain analysis techniques: These techniques can be used to expand the scope of the requirements elicitation, to identify and plan for anticipated changes, to determine fundamental commonalities and variations in the products of the product line, and to support the creation of robust architectures. (See the "Understanding Relevant Domains" practice area.) One of these techniques, FODA, has been incorporated recently in a newer approach to requirements engineering for product lines. Product Line Analysis (PLA) combines traditional object-based analysis with FODA feature modeling and stakeholder-view modeling to elicit, analyze, specify, and verify the requirements for a product line. Feature modeling facilitates the identification and analysis of the product line's commonality and variability and provides a natural vehicle for requirements specification. Stakeholder-view modeling supports the completeness of the requirements elicitation, while the PLA work products (the object model, use case model, feature model, and product line terminology dictionary) provide incremental verification of the requirements modeling [SEI 2007d, Chastek 2001a].

Stakeholder-view modeling: This technique can be used to support the prioritized modeling of the significant stakeholder requirements for the product line. Viewpoint modeling is based on the recognition that a system must satisfy the needs and expectations of the many system stakeholders, who all have their own perspectives (views) of the system. Each stakeholder view can be modeled separately as a set of system requirements. These models are core assets that support the explicit identification of conflicts and determination of tradeoffs, among the needs of the system stakeholders [Sommerville 1997a].

Feature modeling: This technique can be used to complement object and use case modeling and to organize the results of the commonality and variability analysis in preparation for reuse. Features are user-visible aspects or characteristics of a system that are organized into a tree of And/Or nodes to identify the commonalities and variabilities within the system. Feature modeling is an integral part of the FODA method [Kang 1990a] and the feature-oriented reuse method (FORM) [Kang 1998a]. In the latter, the requirements for a family of related systems are organized according to that family's features. The commonalities and variabilities within those features are then exploited to create a set of reference models (that is, software architectures and components) that can be used to implement the products of that family. Feature modeling has also been integrated into the reuse-driven software engineering business (RSEB) [Jacobson 1997a, Griss 1998a].

Use case modeling: This technique can be used with variation points to capture and describe commonality and variability within product line requirements. A variation point is a location within a use case where a variation (that is, variability) occurs. That variation is captured in a variant that describes the context and mode of the variation. The mechanisms supported for capturing and describing different types of variation within use cases include inheritance, uses, extensions, extension points, and parameterization [Jacobson 1997a].

Change-case modeling: This technique can be used to explicitly identify and capture anticipated changes in a system and to ultimately incorporate them explicitly in the design to enhance its long-term robustness. Change cases are use cases that describe potential future requirements for a system. They are linked to the existing system use cases that will be affected if and when the future requirements are adopted. The inclusion of change cases allows the designers to plan for and more effectively accommodate anticipated changes [Ecklund 1996a].

Traceability of requirements to their associated work products: This technique can be used to ensure that the design and implementation of a system satisfy the requirements for that system. Requirements traceability links the requirements backward to their sources (a stakeholder, for example) and forward to the resulting system development work products (a component, for example). In addition to assisting with the elicitation and verification of requirements, requirements traceability is critical in determining the potential impact of proposed changes in a system [Ramesh 1997a, Sommerville 1997a].

Practice Risks

The major risk associated with requirements engineering is failure to capture the right requirements over the life of the product line. Documenting the wrong or inappropriate requirements, failing to keep the requirements up-to-date, or failing to document the requirements at all puts the architect and the component developers at a grave disadvantage. They will be unable to produce systems that satisfy the customers and fulfill the market expectations. Inappropriate requirements can result from the following:

failure to distinguish between product-line-wide requirements and product-specific requirements: These different kinds of requirements have different audiences in a product line. The core asset builders need to know the requirements they must build to, while the product-specific software builders must know what is expected of them.
insufficient generality: Insufficient generality in the requirements leads to a design that is too brittle to deal with the change actually experienced over the lifetime of the product line.
excessive generality: Overly general requirements lead to excessive effort in producing both core assets (to provide that generality) and specific products (which must turn that generality into a specific instantiation).
wrong variation points: Incorrect determination of the variation points results in inflexible products and the inability to respond rapidly to customer needs and market shifts.
failure to account for qualities other than behavior: Product line requirements (and software requirements in general) should capture requirements for quality attributes such as performance, reliability, and security.

In addition, requirements engineering for a product line is subject to the risks enumerated in the "Understanding Relevant Domains" practice area.