The previous two articles of this series on product requirements specification have addressed the two key specification parts: product perspective and system perspective. This part looks at how the two perspectives interrelate and integrate with each other.

Product and system perspectives complement each other

Product and system perspectives are two complementary parts of a product requirements specification. The represent different perspectives on the product, and they establish two separate but integrated workspaces for product management and development. The following diagram shows this big picture: Product management is responsible for defining the product perspective, which is made up of product requirements. It provides a high-level definition of the product. In particular it describes how the product contributes to fulfilling (1) the needs of the product stakeholders and (2) the assumptions of the adjacent systems. Development is responsible for defining the system perspective, which is made up of system requirements. It describes how the product requirements shall be implemented based on specific technologies and platform characteristics.

Link product and system requirements

Product requirements should be explicitly linked with the system requirements that implement them. This is indicated by the dots and arrows in the above diagram. The subsequent diagram illustrates this using an example from smartphone development. Product management emphasizes that usage time will be critical for the success of the next product generation to be developed (i.e., product requirement: “The phone shall have a very high usage time.”). It is up to development, represented by a system architect in this case, to propose how the goal of high usage time can be established. In the example, a combined solution of high battery capacity and fast charging technology is selected. Links from the product requirement to the two system requirements document the technical solution (i.e., combination of system requirements) to the market-driven product requirement. The explicit linking of product and system requirements brings various benefits:

• Support and ease collaboration between product management and development
• Document design decisions and development activities for demonstrating regulatory provisions and quality standards
• Facilitate maintenance by clarifying the context and dependencies of each requirement
• Enable requirements reuse by identifying clusters of requirements that belong together

How to derive system requirements from product requirements

Product requirements are derived from system requirements in close collaboration between product management and development. Therefore, each party must be deeply familiar with their own domain and must have sufficient understanding of the other domain. Product management must be able to validate whether a proposed technical solution is actually viable. And it must assess the implications that a technical solution has for customer, market and business. For instance, this includes price and license implications, or technological trends and preferences in the market. Development must of course excel in technical implementation matters and be able to propose state-of-the-art or leading-edge solutions to the product requirements. At the same time, this requires a sufficient understanding of the entire customer, market and business context. These required competence areas (is responsible vs. must know & understand) are illustrated in the following diagram. The interface between product perspective and system perspective marks the area of collaboration between product management and development. This is where product requirements must be broken down into and mapped to system requirements. How can the interaction between product management and development be organized?—There are two basic models or styles of collaboration: Negotiation of implementation proposals: In a contractor/subcontractor relationship product management (as contractor) defines the product to be developed. Development (as subcontractor) develops an implementation proposal, which is then negotiated with product management until a consensus is reached. Sometimes a formal development contract will be defined. Continuous evolution of solution design: Product management and development jointly work on a central overall product requirements specification (i.e., on their product or system perspectives, respectively). Whenever new features or new technical solution candidates appear, they investigate, discuss, and decide on updates or extensions of the central product requirements specification. The negotiation model can often be found when product development is project-based or customer-driven, or when external development partners are involved. It can work with document-based requirements management, not necessarily mandating the use of a specialized requirements tool (although this would have advantages). However, possibilities for requirements reuse and highly efficient requirements management are limited. The continuous evolution model requires that a tool-based requirements management infrastructure is in place. It must include a requirements repository, workflow and stage gate definitions, as well as versioning and release management on the basis of individual requirements. Typically, product management and development have their separate work areas within the requirements repository (i.e., product and system perspective). Coordination between both areas is accomplished by committees, boards, and work groups with members from each area of domain. Continuous evolution of solution design can often be found in market-driven development of software or software-based products (including high-tech products). It favors a central coherent collection of requirements for the entire product or product line, and it provides a good foundation for efficient requirements reuse.

Divide, Specialize, and Integrate

Product requirements specifications that explicitly distinguish between product and system perspective form the basis for highly effective and efficient requirements management. The two perspectives and their respective requirements collections establish specialized work areas for product management and development, fostering and supporting internal and external collaboration of the two parties. The explicit and central storage of requirements information and trace relationships ensure high transparency and availability of requirements for the entire development organization (e.g., including testing, production planning, and support). Moreover, this approach can lead to high requirements quality and enable requirements reuse. The inherent complexity of requirements management can be mastered by the combination and interplay of three principles:

1. Divide the overall collection of requirements into manageable segments
2. Specialize each requirements segment to a dedicated area of competence and responsibility (i.e., work areas and workspaces)
3. Integrate the requirements segments and their work areas by managing the interfaces and interactions between their explicitly documented requirements collections

The division of requirements into product and system perspective is guided and facilitated by assigning specific characteristics to each perspective. This has been described in the two previous articles of this series on product perspective and on system perspective, respectively. The following table summarizes and compares the characteristics of both perspectives.

If you want to explore these aspects further, you might look up the earlier parts of this article series:

• Product Requirements Specification: When Do You Need It?
• Product Requirements Specification: Product Perspective
• Product Requirements Specification: System Perspective
• Product Requirements Specification: Integrating Product and System Perspective (this article)