Software Product Lines
Framework Home
Introduction
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Architecture Definition
Architecture Evaluation
Component Development
Mining Existing Assets
Requirements Engineering
Software System Integration
Testing
Understanding Relevant Domains
Using Externally Available Software
Technical Management
Practice Areas
Organizational Management
Practice Areas
Frequently Asked Questions
Glossary
Bibliography

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

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

  1. a condition or capability needed by a user to solve a problem or achieve an objective
  2. 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
  3. 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 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:

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

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

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:

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

Further Reading

[Birk 2003a]
This Fraunhofer Institute report is based on the findings of the Gesellschaft fur Informattik (GI) Working Group, which includes organizations such as Hewlett-Packard, Bosch, RWTH Aachen, and sd&m. Birk and colleagues provide a good description of the problems associated with requirements engineering for software product lines from the industry point of view.

[Davis 1990a] & [Sommerville 1997a]
These are two good textbooks for requirements engineering. Of particular value in Somerville and Sawyer's book is a table that describes the basic, intermediate, and advanced requirements engineering guidelines.

[Dorfman 1997a]
This is a tutorial in book form that is based on the most significant requirements engineering papers of the last two decades.

[Faulk 1997a]
Faulk provides an excellent, brief introduction to requirements engineering, describing such techniques as functional decomposition, structured analysis, operational specification, and object-oriented analysis.

[Schmid 2006a]
A continuing problem with the adoption of software product lines has been the lack of effective tool support for product line requirements engineering. This report describes the Requirements Management for Product Lines (REMAP) software tool. REMAP is a prototype that operates on top of existing requirements engineering tools, such as DOORS, and provides the additional product line support lacking in those existing commercial tools. The earlier work of Schmid and colleagues provides a more complete description of REMAP [Schmid 2005a].

Next Section Table of Contents Previous Section