A product requirements specification establishes a bridge between product management and development. It defines a product in terms of stakeholder requirements, containing all those requirements that sensibly should be described explicitly and be available permanently.
This is the second article in a series on product requirements specification. It takes a closer look on the product perspective. The next article in this series focuses on the system perspective. (See below at the end of the article for links to the other parts of the series.)
Joint Work Product of Product Management and Development
Product requirements specifications are created and maintained as joint work products (or call them “tools” or “instruments”) of product management and development. Product management has the main overall responsibility and is accountable for it. Development is responsible for the more technical and detailed parts. Both parties, product management and development, must collaborate closely over the entire lifecycle of a specification.
Coordination between product management and development works best, when their areas of responsibility and thus their interfaces are defined clearly. This is an important reason, among others, why separation of a product requirements specification into sections or perspectives is a good idea. The most useful top-level separation is to distinguish (1) product perspective as the workspace of product management and (2) system perspective as the workspace of development.
Characteristics of Product Perspective
For product management, the product requirements specification is the core instrument that (a) defines product management’s response to stakeholder needs and demands, and (b) that communicates to development what shall be the product or the new features to be developed.
The following figure illustrates these relations, with a focus on product perspective. Product management is responsible for defining a product perspective that meets the expectations and needs of the product’s stakeholders. In addition, relevant relations to adjacent systems must be considered and served.
The main characteristics of the product perspective are:
- Describes external view on the product
- Answers *What* …
- Is the product?
- Does the product do?
- Addresses business and usage aspects of the product
- Uses Problem Domain language and concepts
- Is a “Black Box” view
External View & “What?” Questions
The two fundamental characteristics of the product perspective are (1) that it describes an external view on the product, and (2) that it focuses on “What?” questions.
External view on the product: The product perspective defines the product from the stakeholders’ viewpoints, which is an external, “outside” view. Where the product perspective addresses relations to adjacent systems, it focuses again on those properties of the product’s interfaces that are relevant externally.
This external view has two important implications and advantages:
(1) It places emphasis on the product’s stakeholders. The stakeholders shall be able to understand their relevant product requirements without additional technological or implementation-related knowledge. Their acceptance criteria will be the basis for validating the product (i.e., acceptance test).
(2) Technical details and implementation decisions can be delegated fully to development (including their coordination and agreement between development and product management). This offers maximum freedom to the design of effective development and product lifecycle processes.
“What?” questions: Product perspective defines what the product does, not how it does so. This corresponds with the external view of the product. Moreover, it also imposes clear conditions and criteria on the formulation of product requirements.
The following figure illustrates these key aspects of the product perspective: Product management is accountable for product success and must therefore be responsible author of the product perspective. As an external view on the product, the product perspective defines how the product contributes to fulfilling stakeholder needs and adjacent systems assumptions.
Elementary building blocks of the product perspective are product requirements statements. They define the product’s functional behavior, qualities, and constraints in response to stakeholder needs or adjacent systems’ assumptions.
Examples of product requirements are:
- Functional requirement of a music player app: History of played songs
- Quality requirements of technical products: Precision, throughput, and safety
- Constraints on information systems: Compliance with legal regulations or industry standards
Business, Usage, Problem Domain & Black Box
The remaining three characteristics of the product perspective are basically already included into the former ones or implied by them. However, they are important facets that should be considered explicitly. They help to understand better the role of product requirements specifications so that they can be created most effectively.
Business and usage aspects: The characteristic of business and usage perspective emphasizes that the product perspective should be defined with regard to relevant stakeholders’ interests and goals. It also underlines the role of product management, being accountable for the product’s business success.
Problem Domain: A problem domain is a topic area in which a product shall be applied as a solution to some needs, desires, or demands. It is contrasted with solution domain.
A product domain provides important context and framing for defining and understanding the product. Product requirements should be expressed using terminology and concepts of a product’s problem domain. For instance, in the case of a music player app, important problem domain concepts are song, playlist, and volume.
Black Box: The concept of the black box (i.e., opaque surface), as opposed to white box (i.e., transparent), emphasizes that the product perspective shall focus on externally visible characteristics of the product. It corresponds closely to the “What?” questions.
Contents of Product Perspective
Given these characteristics of a product perspective, which specific parts or sections shall it have? Basically, every product perspective should have the following contents:
- Product overview
- Context & scope
- Stakeholders & stakeholder analysis
- Business processes & usage processes
- Product requirements (including use cases)
Product overview gives an initial understanding of the product (i.e., objectives and intention of use) and outlines the essential product structure (i.e., product parts and their organization). Context and scope define what is outside the product and what interacts with it. They also identify the product’s stakeholders, which must be defined and analyzed in sufficient detail.
Business and usage processes describe when, how, and why stakeholders need, use, and interact with the product. They also show how the different product functionalities and parts belong together.
Product overview thus defines the product as a (black) box. The other contents of the product perspective represent the problem domain, and the business and usage aspects.
Finally, a collection of product requirements statements defines the details of the product’s functionality, its qualities, and the important constraints under which it operates (i.e., external view addressing the “What?” aspects).
Besides textual statements, the various parts of the product perspective can take quite different forms: Structured use cases, tabular information, formal languages similar to program code, and many types of graphical models and illustrations.
The subsequent parts of this article series introduce how system perspective complements product perspective, and how the two perspectives depend on each other and interact.
- Product Requirements Specification: When Do You Need It?
- Product Requirements Specification: Product Perspective (this article)
- Product Requirements Specification: System Perspective
- Product Requirements Specification: Integrating Product and System Perspective