PRODUCT DESCRIPTION
PROCESS DESCRIPTION
INTERACTIONS WITH OTHER ACTIVITIES
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.
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.
The Product Requirements Activity requires the following information:
The Product Requirements Activity requires domain and software knowledge and experience in:
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.
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).
....
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 >
....
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.
The Product Requirements Activity consists of four steps shown in Figure DE.2.2.2 -1 Product Requirements Process
Follow these steps for the Product Requirements Activity.
Step: Define the Concept
Step: Describe the Context
Step: Derive the Content
Step: Identify Constraints