RSP gb toc RSP Return Up Down GoTo Synthesis Leveraged Domain Engineering
PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES

DE.2.2.2. Product Requirements

Getting Started

The Product Requirements Activity is an activity of the Domain Specification Activity for creating Product Requirements. A requirements specification describes needs that are satisfied by creating an Application Product. Needs are expressed in terms of the required behavior and operational environment of an envisioned application." Similarly, Product Requirements is a requirements specification that is adaptable to the decisions supported by the product family's Decision Model. The Product Requirements describes the set of problems solved by the members of a product family. By applying the decisions that characterize a particular product (i.e., its Application Model) to the Product Requirements, a standardized description of that product is produced. A Product Requirements gives meaning to an Application Model as a description of a member of a product family. The Product Requirements Activity is performed for each work product family in the domain.

Objectives

The objective of the Product Requirements Activity is to define the requirements for a product family. The specification must be adaptable to decisions allowed by the product family's Decision Model.

Required Information

The Product Requirements Activity requires the following information:

Required Knowledge and Experience

The Product Requirements Activity requires domain and software knowledge and experience in:

PRODUCT DESCRIPTION

Name:
Product Requirements
Purpose:
Product Requirements specify the requirements of members of a product family. Product Requirements also define the meaning of an Application Model created in accordance with the corresponding product family's Decision Model. You can use the Product Requirements to understand (and explain to application engineers) the implications of decisions in an Application Model (which describes the problem solved by an application ).
Content:
The Product Requirements is an adaptable requirements specification for a product family. A specification contains four types of information:
  • Concept. An overall characterization of purpose and objectives.
  • Context. A characterization of the relevant environment and relationships within it.
  • Content. A characterization of the expressed or contained substance, meaning or behavior, and scope.
  • Constraints. A characterization of limits and demands on context of use or content.

As a whole, this information is sufficient to characterize each particular member of a product family as implied by the decisions allowed by the family's Decision Model.

Form and Structure:
Product Requirements may be expressed in any well-defined form, for example:
  • Structured, informal text
  • Assertions
  • A formal or semi-formal specification

The assertions form of Product Requirements is a set of assertions that describe the (black-box) behavior of applications in the domain. Assertions may be simple or parameterized to reflect decisions defined in the Decision Model. Assertions can be structured into a hierarchy to facilitate separation of concerns. 




The Traffic Light Control Software System (TLC) controls the
traffic light sequence for an intersection. The streets are
laid out in the following configuration.


< if Traffic_Light_Controller.Geometry = X then > 


                        Street1 
                           | 
                           | 
         Street4 ----------+---------- Street2 
                           | 
                           | 
                        Street3 


< else > 


                        Street1 
                           | 
                           | 
                           +---------- Street2 
                           | 
                           | 
                        Street3 


< endif > 


Each traffic light sequence in the intersection is coordinated with other 
traffic lights in the intersection.  The intersection arms have the following 
characteristics.  


< forall streets S in Traffic_Light_Controller.Geometry > 
        Street (< S.Name >): 
                < if S.Right_Turn_Lanes specified then > 
                - < S.Right_Turn_Lanes.Num_of_Lanes > right turn lanes 
                < endif > 
                < if S.Left_Turn_Lanes specified then > 
                - < S.Left_Turn_Lanes.Num_of_Lanes > left turn lanes 
                < endif > 
                .... 


< endfor > 


.... 


< if there exists at least one Street such that Street.Crosswalk_Button = CB 
then > 


The Crosswalk_Button device interrupts the TLC system each time the crosswalk 
button is pushed.  The message received from this device has the following 
characteristics: 


        .... 


< endif > 


.... 


The TLC system also has an interface to a real-time clock.  The clock is used 
by the TLC system to determine when to activate a traffic light cycle (in the 
absence of any trip mechanisms in the streets) and the duration of each traffic 
light indicator in a traffic light sequence.  A TLC system also uses the 
real-time clock to keep track of the current time-of-day to determine how 
quickly it must respond to signals received from trip mechanisms or pedestrian 
crosswalk push buttons.  


....

Example DE.2.2.2-1. Fragment of TLC Product Requirements

For all forms, parameterization can be used to express the effects of decisions on Product Requirements. A metaprogramming notation can describe text substitution, conditional inclusion, and iteration over repetitive decisions. Example DE.2.2.2-1 Fragment of TLC Product Requirements illustrates a fragment of the TLC domain. This fragment depicts a portion of the content (e.g., externally visible behavior) and context (e.g., inputs from the environment) of systems in the TLC domain. This fragment also depicts the use of parameterization (in terms of appropriate decisions from the product family's Decision Model shown in Example DE.2.2.1-1 ) to express requirements that characterize particular members of the product family. For example, the block of text describing the message format received from the crosswalk button device is only included in the Product Requirements when there is at least one Street in the TLC system which has that device.

Comment:
A black-box description for Product Requirements reduces the tendency to choose software design and implementation solutions prematurely. By parameterizing the description, it will apply equally well to all members of the product family. Figure DE.2.2.2-1 Instantiating Product Requirements illustrates how an Application Model for a product is applied to a parameterized Product Requirements to yield a standardized software-requirements specification for that product.
Verification Criteria:
  • All implicit requirements must be an elaboration of one or more commonality assumptions.
  • The Product Requirements must elaborate all commonality assumptions.
  • If decisions that characterize a particular work product particular system are applied to the Product Requirements, the result should be a requirements specification that describes that system correctly.

PROCESS DESCRIPTION

The Product Requirements Activity consists of four steps shown in Figure DE.2.2.2 -2 Product Requirements Process

Procedure

Follow these steps for the Product Requirements Activity.

Step: Define the Concept

Action:
Describe overall purpose and objectives for the work product family.
Input:
  • Domain Definition
  • Decision Model
Result:
Product Requirements: Concept
Heuristics:
  • Select a requirements method that best supports an abstract description of the product family. For documents, a brief textual description may suffice.
  • Describe an application's purpose and concept of operations. For associated documents, describe objectives and provide an overview of content.
  • Examine commonality assumptions to identify additional aspects of concepts that apply to all members of the product family.
  • Examine variability assumptions to derive additional aspects of concepts that distinguish particular members of the product family. Capture these requirements by parameterizing concept descriptions in terms of the appropriate decisions from the product family's Decision Model.
  • Examine Legacy Products from the Domain Definition to derive additional concept requirements that apply to all or some members of the product family. For common concepts, determine whether these will apply to future members of the product family. Describe variations in concepts in terms of decisions in the product family's Decision Model. If no such decisions exist, then decide whether you want to extend the Decision Model to accommodate these requirements variations.

Step: Describe the Context

Action:
Describe the relevant environment and relationships for the work product family.
Input:
  • Domain Definition
  • Decision Model
Result:
Product Requirements: Context
Heuristics:
  • Describe the environment (e.g., devices, connected systems, users/roles) in which an application operates. Also describe the interface to that environment (e.g., inputs from the environment, outputs to the environment). For documents, describe their audience, expected benefits, and relation to other work products.
  • Examine commonality assumptions to derive additional context requirements that apply to all members of the product family.
  • Examine variability assumptions to derive additional context requirements that characterize a particular member of the product family. Capture these requirements by parameterizing context descriptions in terms of the appropriate decisions from the product family's Decision Model.
  • Examine Legacy Products to derive additional context requirements that apply to all or some members of the product family. For common requirements, determine whether these will apply to future members of the product family. Describe variations in context in terms of decisions in the product family's Decision Model. If no such decisions exist, then decide whether you want to extend the Decision Model to accommodate these requirements variations.

Step: Derive the Content

Action:
Describe the externally visible behavior and information content of applications in the " product family.
Input:
  • Domain Definition
  • Decision Model
Result:
Product Requirements: Content
Heuristics:
  • Define an information model of an application's information content. Describe the externally visible behavior of an application, including conceptual modes of operation and functions that produce output to the environment. For documents, identify the topics to be covered.
  • Examine commonality assumptions to derive requirements that apply to all members of the product family.
  • Examine variability assumptions to derive additional requirements that characterize particular members of the product family. Capture these requirements in the Product Requirements by parameterizing content descriptions in terms of the appropriate decisions from the product family's Decision Model.
  • Examine Legacy Products of the Domain Definition to identify and extract additional common and varying requirements for content. For common content, consider whether these requirements will apply to future members of the product family. Describe variations in content in terms of decisions in the product family's Decision Model. If no such decisions exist, then decide whether you want to extend the Decision Model to accommodate these requirements variations.

Step: Identify Constraints

Action:
Describe limits and demands on members of the work product family.
Input:
  • Domain Definition
  • Decision Model
Result:
Product Requirements: Constraints
Heuristics:
  • Describe environmental limits (e.g., reliability and responsiveness of devices), performance demands (e.g., timing and accuracy goals for inputs and outputs), and design or implementation dictates (e.g., targeting of software to operate on particular computers). For documents, describe any formatting guidelines.
  • Examine commonality assumptions to derive additional constraints that apply to all members of the product family.
  • Examine variability assumptions to derive additional constraints that characterize particular members of the product family. Capture these requirements by parameterizing constraint descriptions in terms of the appropriate decisions from the product family's Decision Model.
  • Examine Legacy Products to derive additional constraints that apply to all or some members of the product family. For common constraints, determine whether these will apply to future members of the product family. Describe variations in constraints in terms of decisions in the product family's Decision Model. If no such decisions exist, then decide whether you want to extend the Decision Model to accommodate these requirements variations.

Risk Management

Risk:
Product Requirements do not capture all Domain Assumptions accurately.
Implication:
A derived requirements specification will not accurately describe the problem that the corresponding work product family member solves.
Mitigation:
Create an Application Model for one or more existing systems and derive their respective requirements specifications. Review the specification with customers, experienced engineers, and domain experts to identify any inaccuracies.

INTERACTIONS WITH OTHER ACTIVITIES

Feedback to Information Sources

Contingency:
The Domain Definition is incomplete, ambiguous, or inconsistent.
Source:
Domain Definition Activity
Response:
Describe the inadequacies in the Domain Definition. Proceed with Product Requirements, and document any assumptions made regarding the inadequate portions of the Domain Definition.

Contingency:
The Domain Plan cannot be satisfied with available technical capabilities.
Source:
Domain Management Activity
Response:
Propose (alternative) revisions to the Domain Plan that better match available capabilities. Complete Product Requirements that satisfy the Domain Plan as closely as possible.

Contingency:
The practices and procedures specified in the Domain Plan are either ineffective or inefficient.
Source:
Domain Management Activity
Response:
Describe the ways in which the practices and procedures are either ineffective or inefficient. Propose revisions to the practices and procedures that will make them more effective.

Contingency:
The Decision Model is incomplete, ambiguous, or inconsistent.
Source:
Decision Model Activity
Response:
Describe the inadequacies in the Decision Model. Proceed with Product Requirements, and document any assumptions made regarding the inadequate portions of the Decision Model.

Feedback From Product Consumers

Contingency:
Product Requirements fail to describe a product family that is consistent with the Domain Definition.
Source:
Domain Management Activity
Response:
Modify the Product Requirements to be consistent with the Domain Definition.

Contingency:
Product Requirements are incomplete, ambiguous, or inconsistent.
Source:
  • Product Design Activity
  • Product Implementation Activity
Response:
Refine the Product Requirements to correct inadequacies.


PHS