Product Requirements Specification: System Perspective

by | 27/03/2020 | software engineering

The system perspective of a product requirements specification defines the solution design of a new product or product release. As a starting point it takes a previously described product perspective and defines all important detailed aspects of solution design and solution technology.

This is the third article in a series on product requirements specification. The previous one has addressed product perspective. The subsequent and last article discusses aspects of integrating product and system perspectives.

System Perspective: Work Product of Development

The system perspective of a product requirements specification is an important instrument of development, especially of those development roles that are responsible for solution design: Architecture, UX design, product owner (depending on role separation with product management), system engineers, lead developers, and to some extent other roles like testing and test management, quality management, and IT security management.

Typically, one or two persons take the lead for defining and coordinating the system perspective. They are responsible for the resulting specification. In agile development, product owners might have core responsibility, with support from UX designers. In development of software-based technical systems, system architects or system engineers often play the key role.

Architects at least take a role as key consultants and contributors. Rather unfrequently they have the organizational lead for defining the system perspective, because of their various other cross-sectional responsibilities. Similarly, testing, test management, and quality management contribute and must be informed.

Purposes: Bridge between Product Perspective and Implementation

For development the system perspective serves four important purposes: (a) It documents development’s response to the product requirements defined by product management (i.e., forming the foundation of a development contract with product management). (b) It supports and facilitates a consistent solution design across the various disciplines involved. (c) It supports and facilitates systematic evaluation of alternative design options. (d) And it communicates to other development roles (esp. to component developers and testers) how the product or new feature shall be implemented.

System Perspective as Workspace of Development

So overall, the system perspective builds a bridge between product perspective and implementation (see figure above). It is defined using system requirements, which are derived from product requirements and can represent major design decisions. The derivation relations should be documented explicitly using trace links (e.g., by cross-references in text documents or relationships in requirements tools).

When using such trace links, the information about relevant product requirements  remains accessible from every system requirement (i.e., following the link up-stream). For instance, it can be identified which primary stakeholder needs, which are usually expressed by product requirement, have led to a specific solution design in the system requirements.

Characteristics of System Perspective

The main characteristics of the system perspective are:

  • Describes internal view of the product
  • Answers *How* …
    • Does the product work?
    • Does the product accomplish its functionality?
    • Does the product provide or achieve its (non-functional or quality) characteristics?
  • Addresses technological, implementation, and operational aspects of the product
  • Uses Solution Domain language and concepts
  • Is a “White Box” view

Internal View & “How?” Questions

Among the characteristics of the system perspective two are essential: (1) It describes an internal view of the product. (2) It focuses on “How?” questions.

Internal view of the product: The system perspective defines the product’s  solution design from the viewpoint of development. It forms a separate workspace where development has full responsibility to design an optimum solution for the given product requirements.

“How?” questions: The system perspective defines how the product shall work and be built. This clear focus on “how?” aspects helps deciding whether a requirement belongs to system perspective (as opposed to product perspective, addressing “what?” questions). It also guides formulation of precise, high-quality system requirements statements.

The following figure illustrates these two aspects of the system perspective: Development (i.e., one or few nominated persons from development) is accountable for solution viability and must be responsible authors of the system perspective or its respective parts (e.g., UX Design responsible for user interface design and all other UX aspects).

Key Aspects of System Perspective

System requirements are the main contents of the system perspective. As an internal view of the product, they define how product requirements shall be implemented. They refer to a certain technological basis and to platforms to be used by development and operations. This technological basis and platforms provide the foundation that underpins the solution design. They must be defined explicitly within the system perspective so that the system requirements can be understood clearly and be formulated in a concise manner.

Examples of system requirements are:

  • Functional requirements of a finance application: When and how various relevant taxation policies shall be considered during calculations
  • Performance requirements of technical products: Which measures for energy management shall be applied in order to ensure long battery life
  • Security and privacy requirements of mobile apps: How personal data shall be stored and transmitted

Technology, Implementation, Solution Domain & White Box

The other three characteristics of the system perspective are implied by the former two. However, emphasizing them helps to understand important facets of system perspective better. They also guide us to writing better system requirements.

Technology, implementation, and operations aspects: These are the typical contents of the system perspective. They all refer to “how?” questions of solution design instead of just “what?” questions (i.e., what shall the product be and look like–focus of the product perspective). Thus they establish the relevant internal view of the product.

Technology is an important aspect of solution design especially for technical products like combined hardware/software systems. Other aspects where technology can make a difference are, for instance, security and system performance.

When should we define implementation aspects as system requirements and not just leave them do the developers’ decisions?–They should be defined explicitly as system requirements whenever there are several alternative solution options, among which a specific one shall be preferred. For instance, one implementation approach (e.g., an algorithm) might offer important competitive advantages (e.g., higher performance).

Aspects of system operations must be considered, because they can have high impact on a product’s long-term cost structure (e.g., dependability or scalability). They also can open up competitive advantages (e.g., availability of operations data). So they should be addressed in system requirements.

Solution Domain: A solution domain is a subject matter area that contributes to solving a given problem. For instance, for the problem how to drive a vehicle, relevant solution domains can be combustion engines or electric engines.

Likewise, solution domains for developing web applications range from internet protocol via programming languages (like C# and Java) and frameworks (like .NET) to specific technology areas (like VPN, cryptography, and blockchains).

A solution domain provides the concepts and building blocks of the solution. It establishes the conceptual and terminological framework for formulating system requirements. In order to understand system requirements correctly, it is important to know the solution domain to which they refer to or belong.

White Box: The notion of a white box stands for a system whose internal mechanics can be viewed (i.e., transparent box that allows to see the inside). System perspective is such a white box. This is different from product perspective, which intentionally shall hide (or abstract from) the internal aspects (denoted black box) in order to reduce complexity and highlight external properties of a product.

This “white box” characteristic of system perspective plays an important role for development: It shall define and expose all relevant internal aspects of solution design, so that everyone involved into implementation can gain a good understanding of how the product shall work, and how it shall be implemented.

Contents of System Perspective

System perspective usually should have the following overall contents:

  • Solution overview
    • Solution architecture
    • Development technology & platforms
    • Operations technology & platforms
  • Architecture and design principles
  • System requirements (including use cases)

System requirements are by far the largest part. Their internal structure usually contains groups of requirements that match the parts of system architecture (e.g., UI, processing, and database) or important subject matter categories of the solution domains.

Solution overview defines the scope of the solution and describes its basic elements. For instance, it indicates relevant solution domains important for designing the solution and for understanding the system requirements. So an important purpose of the solution overview is to frame and introduce the solution to readers of the system perspective (e.g., new development team members, auditors).

Architecture and design principles define essential general, cross-sectional properties of the solution–e.g., software design patterns and UI style guide. These basic rules and policies shall facilitate construction of the solution and ensure solution quality. They also can ease definition of the system perspective, because general principles and policies are defined in a central location and do not need to be repeated in several individual requirements across the specification.

 

The next and last part of this article series discusses how system perspective is derived from product perspective, and how the two perspectives interrelate.