RSP gb toc RSP Return Up Down GoTo Synthesis Opportunistic 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 a work 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 work product family's Decision Model. The Product Requirements describes the set of problems solved by the members of a work product family. By applying the decisions that characterize a particular work product (i.e., its Application Model) to the Product Requirements, a standardized description of that work product is produced. A Product Requirements gives meaning to an Application Model as a description of a member of a work 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 work product family described in Process Requirements. The specification must be adaptable to decisions allowed by the work 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 work product family. Product Requirements also define the meaning of an Application Model created in accordance with the corresponding work 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 a work product ).
Content:
The Product Requirements is an adaptable requirements specification for a work 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 work 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) meaning of work products 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.

Appropriate formal or semi-formal notations depend on the domain being analyzed, the application engineering work products mandated by Process Requirements, and the existing work products available for analysis. For example, when writing the Product Requirements for a family of code, you might want to represent the Product Requirements using a package interface specification like that of Booch (1987). To define behavior precisely, you might choose a semi-formal method as described in Heninger (1980).

1. Overview
The objectives of a System/Segment Specification (SSS) within the TLC domain are as follows:
  • The SSS specifies the requirements for a system or a segment of a system within the domain.
  • The SSS provides a general overview of the TLC system or segment.

....

2. Key Topics and/or Functions
The basic requirements for an SSS are stated in the DID DI-CMAN-80008A. The members of the SSS work product family of the TLC domain vary from or interpret this specification as indicated below.

....

< if there is least one Street S that has S.Pedestrian_Lane.Push_Button_Mechanism = yes then >
The SSS shall identify the push-button device as an external to which the TLC system must interface. It shall define in detail the specific interface to the push button from the TLC system based upon the < TLC_SSS.HW_Platform.Interface > interface.
< endif >

....

< if TLC_SSS.HW_Platform.Platform is TLC1 then >
The SSS shall contain the subparagraph titled Toxic products and formulations (numbered 3.3.1.1) specifying the requirements for the control of the toxic products used in the manufacture of the < Platform > platforms.
< endif >

....

< if TLC_SSS.HW_Platform.Platform is TLC2 or TLC3 then >
The SSS shall omit the subparagraph titled Toxic products and formulations (numbered 3.3.1.1) with the statement "This subparagraph is not applicable to this system."
< endif >

....

Example.2.2.2-1 Fragment of TLC Product Requirements for the System/Segment Specification Work Product Family

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 for the System/Segment Specification Work Product Family illustrates a fragment of a Product Requirements for a DOD-STD-2167A System/Segment Specification document work product family of the TLC domain. This fragment depicts a portion of the concept (e.g., the objectives) and content (e.g., topics) covered in this document. This fragment also depicts the use of parameterization (in terms of appropriate decisions from the work product family's Decision Model shown in Example DE.2.2.1-1 ) to express requirements that characterize particular members of the work product family. For example, the block of text describing the pedestrian lane push-button device topic is only included in the Product Requirements when there is at least one Street in the TLC system which has that device.

Verification Criteria:
  • All implicit requirements must be an elaboration of one or more commonality assumptions.
  • The Product Requirements must elaborate all commonality assumptions that are applicable to the work product family.
  • If decisions that characterize a particular work product are applied to the Product Requirements, the result should be a correct description of that work product.
  • One adaptation of the Product Requirements must describe a work product that is relevant to the targeted project.

PROCESS DESCRIPTION

The Product Requirements Activity consists of four steps shown in Figure DE.2.2.2 -1 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 work product family. For documents, a brief textual description may suffice.
  • Describe the work product's objectives and provide an overview of its content.
  • Examine commonality assumptions to identify additional aspects of concepts that apply to all members of the work product family.
  • Examine variability assumptions to derive additional aspects of concepts that distinguish particular members of the work product family. Capture these requirements by parameterizing concept descriptions in terms of the appropriate decisions from the work 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 work product family. Describe variations in concepts in terms of decisions in the work 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 work product's audience, its expected benefits, and its relation to other work products.
  • Examine commonality assumptions to derive additional context requirements that apply to all members of the work product family.
  • Examine variability assumptions to derive additional context requirements that characterize a particular member of the work product family. Capture these requirements by parameterizing context descriptions in terms of the appropriate decisions from the work product family's Decision Model.
  • Examine Legacy Products to derive additional context requirements that apply to all or some members of the work product family. Describe variations in context in terms of decisions in the work 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 subject matter covered in the work in the " product family.
Input:
  • Domain Definition
  • Decision Model
Result:
Product Requirements: Content
Heuristics:
  • Describe the topics covered by the work product.
  • Examine commonality assumptions to derive requirements that apply to all members of the work product family.
  • Examine variability assumptions to derive additional requirements that characterize particular members of the work product family. Capture these requirements in the Product Requirements by parameterizing content descriptions in terms of the appropriate decisions from the work product family's Decision Model.
  • Examine Legacy Products of the Domain Definition to identify and extract additional common and varying requirements for content. Describe variations in content in terms of decisions in the work 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 any formatting guidelines or other restrictions on the work product.
  • Examine commonality assumptions to derive additional constraints that apply to all members of the work product family.
  • Examine variability assumptions to derive additional constraints that characterize particular members of the work product family. Capture these requirements by parameterizing constraint descriptions in terms of the appropriate decisions from the work product family's Decision Model.
  • Examine Legacy Products to derive additional constraints that apply to all or some members of the work product family. Describe variations in constraints in terms of decisions in the work 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 work products 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 work 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