Elicit, analyze, and establish customer, product, and product component requirements.
Establishes organizational expectations for collecting stakeholder needs, formulating product and product component requirements, and analyzing and validating those requirements.
Requirements Development describes three types of requirements: customer requirements, product requirements, and product component requirements. Taken together, these requirements address the needs of relevant stakeholders, including needs pertinent to various product lifecycle phases (e.g., acceptance testing criteria) and product attributes (e.g., responsiveness, safety, reliability, maintainability). Requirements also address constraints caused by the selection of design solutions (e.g., integration of commercial off-the-shelf products, use of a particular architecture pattern).
All development projects have requirements. Requirements are the basis for design. The development of requirements includes the following activities:
Requirements Development addresses all customer requirements rather than only product level requirements because the customer can also provide specific design requirements.
Customer requirements are further refined into product and product component requirements. In addition to customer requirements, product and product component requirements are derived from the selected design solutions. Throughout the process areas, where the terms “product” and “product component” are used, their intended meanings also encompass services, service systems, and their components.
Requirements are identified and refined throughout the phases of the product lifecycle. Design decisions, subsequent corrective actions, and feedback during each phase of the product’s lifecycle are analyzed for impact on derived and allocated requirements. The Requirements Development process area includes three specific goals.
The Develop Customer Requirements addresses defining a set of customer requirements to use in the development of product requirements. The Develop Product Requirements specific goal addresses defining a set of product or product component requirements to use in the design of products and product components. The Analyze and Validate Requirements specific goal addresses the analysis of customer, product, and product component requirements to define, derive, and understand the requirements. The specific practices of the third specific goal are intended to assist the specific practices in the first two specific goals. The processes associated with the Requirements Development process area and processes associated with the Technical Solution process area can interact recursively with one another.
Analyses are used to understand, define, and select the requirements at all levels from competing alternatives. These analyses include the following:
This definition of required functionality and quality attributes describes what the product is to do. This definition can include descriptions, decompositions, and a partitioning of the functions (or in object oriented analysis what has been referred to as “services” or “methods”) of the product.
In addition, the definition specifies design considerations or constraints on how the required functionality will be realized in the product. Quality attributes address such things as product availability; maintainability; modifiability; timeliness, throughput, and responsiveness; reliability; security; and scalability. Some quality attributes will emerge as architecturally significant and thus drive the development of the product architecture.
Such analyses occur recursively at successively more detailed layers of a product’s architecture until sufficient detail is available to enable detailed design, acquisition, and testing of the product to proceed. As a result of the analysis of requirements and the operational concept (including functionality, support, maintenance, and disposal), the manufacturing or production concept produces more derived requirements, including consideration of the following:
A hierarchy of logical entities (e.g., functions and subfunctions, object classes and subclasses; processes; other architectural entities) is established through iteration with the evolving operational concept. Requirements are refined, derived, and allocated to these logical entities. Requirements and logical entities are allocated to products, product components, people, or associated processes. In the case of iterative or incremental development, the requirements are also allocated to iterations or increments.
Involvement of relevant stakeholders in both requirements development and analysis gives them visibility into the evolution of requirements. This activity continually assures them that the requirements are being properly defined.
For product lines, engineering processes (including requirements development) may be applied to at least two levels in the organization. At an organizational or product line level, a “commonality and variation analysis” is performed to help elicit, analyze, and establish core assets for use by projects within the product line. At the project level, these core assets are then used as per the product line production plan as part of the project’s engineering activities.
In Agile environments, customer needs and ideas are iteratively elicited, elaborated, analyzed, and validated. Requirements are documented in forms such as user stories, scenarios, use cases, product backlogs, and the results of iterations (working code in the case of software). Which requirements will be addressed in a given iteration is driven by an assessment of risk and by the priorities associated with what is left on the product backlog. What details of requirements (and other artifacts) to document is driven by the need for coordination (among team members, teams, and later iterations) and the risk of losing what was learned. When the customer is on the team, there can still be a need for separate customer and product documentation to allow multiple solutions to be explored. As the solution emerges, responsibilities for derived requirements are allocated to the appropriate teams.
Organizations may choose to purchase a requirements development process and procedures rather than to develop them. Using the Causal Analysis and Resolution process, they can tailor the process to fit their organization.
Special expertise in the application domain, methods for eliciting stakeholder needs, and methods and tools for specifying and analyzing customer, product, and product component requirements may be required.