Requirements are the basis for design. Requirements management processes manage all requirements received or generated by the project, including both technical and nontechnical requirements as well as requirements levied on the project by the organization.
In CMMI Requirements Management (REQM) Process Area provides traceability of requirements from customer requirements to product requirements to product component requirements. Requirements Development (RD) Process Area describes Customer requirements, Product and Product component requirements.
This post is a consolidation of different types of requirements as described in CMMI, starting from Customer requirements to Derived requirements.
Customer needs and constraints are analyzed and elaborated to obtain prioritized customer requirements. In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated.
Customer requirements are further refined and made suitable to be included in the contractual documents or supplier agreements. Contractual requirements include both technical and nontechnical requirements necessary for the acquisition of a product or service.
Product and product component requirements
The customer functional and quality attribute requirements are usually expressed in the customer’s terms and can be nontechnical descriptions. A translation of requirements from customer’s language to developer’s language gives rise to product requirements. Or rather the product requirements are the expression of the customer requirements in technical terms that can be used for design decisions. An example of this translation is found in the first House of Quality Function Deployment, which maps customer desires into technical parameters. For instance, “solid sounding door” may be mapped to size, weight, fit, dampening, and resonant frequencies.
The product architecture provides the basis for allocating product requirements to product components. The developer uses product requirements to guide the design and building of the product or service. Product component requirements are a complete specification of a product or service component, including fit, form, function, performance, and any other requirement.
In short, product and product component requirements are the refined Customer requirements. This refinement of customer requirements converts implicit requirements into explicit derived requirements such as interface requirements.
Derived Requirements are those requirements which are not explicitly stated in customer requirements but are inferred from contextual requirements (e.g., applicable standards, laws, policies, common practices, management decisions) or from requirements needed to specify a product or service component. Derived requirements can also arise during analysis and design of components of the product or service. Derived requirements also address the needs of other lifecycle phases (e.g., production, operations, and disposal) to the extent compatible with business objectives.
As internal components are developed, additional interfaces are defined and interface requirements are established. Interfaces between functions (or between objects or other logical entities) are identified. Interface requirements between products or product components identified in the product architecture are defined. They are controlled as part of product and product component integration and are an integral part of the architecture definition. Before integration, each product component should be confirmed to be compliant with its interface requirements. Interfaces can drive the development of alternative solutions described in the Technical Solution process area.
The blog won’t be complete if the below kinds of requirements are not touched
- Allocated requirement
Requirements are said to be allocated when the higher level requirements are levied on a lower level architectural element or design components.
More generally, requirements can be allocated to other logical or physical components including people, consumables, delivery increments, or the architecture as a whole, depending on what best enables the product or service to achieve the requirements.
- Service requirements
Service requirements are the complete set of requirements that affect service delivery and service system development. Service requirements include both technical and nontechnical requirements.
- Technical requirements
Technical requirements are the properties (i.e., attributes) of products or services to be acquired or developed
- Nontechnical requirements
Nontechnical requirements are the requirements affecting product and service acquisition or development that are not properties of the product or service.
Examples include numbers of products or services to be delivered, data rights for delivered COTS and non- developmental items, delivery dates, and milestones with exit criteria. Other nontechnical requirements may include additional conditions and commitments identified by agreements, needed capabilities, conditions derived from business objectives and work constraints associated with training, site provisions, and deployment schedules etc.