Product Requirements Specification: System Perspective

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.

 

Requirements Management Tools: March 2020 Update

The list of requirements management tools on MakingOfSoftware.com has received a new update: The March 2020 version includes 69 tools, with a selected subset of 13 tools that we find particularly noteworthy.

The list gives an up-to-date overview of the requirements management (RM) tools market. It shall guide teams and organizations when compiling a longlist for tool evaluation and selection.

RM Tools Market: Ongoing Transformation & Consolidation

During our research for this update, we could once again observe that the RM tools market is undergoing a transformation and consolidation process. After the recent acquisition and merger wave, important tool vendors have now restructured their portfolios.

Most notably: Micro Focus has positioned Dimensions RM as its core RM tool, with ALM Octane as a very interesting additional candidate for agile requirements management. Its previous other RM-related products Caliber (former RM flagship) and Atlas (more recent agile tool) have reached end of marketing.

Micro Focus ALM/Quality Center is positioned fully towards test management. When looking for a new RM tool solution, it is not a relevant choice any more. However, if you happen to have it inhouse, it can still effectively support your RM processes. In particular, the tool will pair well with the agile ALM Octane.

Other important portfolio consolidations happened at Broadcom, PTC, and IBM: after Broadcom has acquired CA, it has renamed the tool CA Agile Central into Rally Software. So, it has reinstalled the Rally brand, which CA had acquired and removed some years ago.

PTC Integrity Lifecycle Manager platform has been renamed into PTC Windchill RV&S. And IBM has restructured and rebranded its former IBM Rational portfolio. As a consequence, the two DOORS requirements products are now called IBM Engineering Requirements Management DOORS Family and IBM Engineering Requirements Management DOORS Next.

13 RM Tools in Selected List

Due to the large number of tools, we have again compiled a list of 13 selected tools that we regard particularly noteworthy. Features and technology of these tools are markedly up to date, or the tools obviously have strong market presence. When you want to collect a longlist for your tool evaluation, you might start your research by scanning through this list of selected tools.

Compared to our previous release of the tools list, we have removed Micro Focus ALM/Quality Center from the selected list. As described above, the tool is not a hot candidate any more for new purchases. Existing Micro Focus customers might have a look at Dimensions RM instead, and at ALM Octane for agile development in particular.

A new tool on the list is ReqSuite RM from Osseno Software. Over the past years, ReqSuite RM has gone through a remarkable development and maturation process. It started with novel and very interesting support for business analysis. Today it includes an attractive feature set with most characteristics we find important for an up-to-date RM tool.

Tool Availability & Up-to-Date Information

During the update of the RM tools list, we have conducted the following steps:

  • All tools have been checked for availability and up-to-date web links to tool and vendor pages
  • Several tool entries have been changed (e.g., name changes, new product bundles), several obviously outdated ones have been deleted
  • All tools have been supplied with up-to-date version information (where available, as of late February 2020) and assigned to the relevant tool categories (e.g., RD, RM, Agile)

We have again removed several tools for the following reasons: (a) the tool has been discontinued or is not actively marketed any more, or (b) the tool’s product or vendor websites have not received any substantial updates for more than two years.

  • Atlas
  • Caliber
  • CORE
  • DevSuite
  • Raven
  • RDD-100
  • Rhythm
  • TopTeam Visual Use Case
  • TraceCloud
  • TREND/Analyst
  • Visual Trace Spec

If you want to get an overview of the RM tools market, or want to select a suitable requirements tool for your team and organization, feel free to explore the latest list of requirements management tools:

https://makingofsoftware.com/resources/list-of-rm-tools/

Product Requirements Specification: Product Perspective

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.

Product Requirements Specification: Bridge between Product Management and Development

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.

Product Perspective as Workspace of Product Management

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.

Key Aspects of Product Perspective

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 the 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?

Attention to requirements specification increased during the 1980s and 1990s in order to master the growing complexity of software and systems development. However, starting in the second half of the 1990s, the movement of agile development widely challenged the use of requirements specification documents.–Now, do we need product requirements specifications today?

The answer is: It depends. While a lean and agile approach to requirements and design is indisputably state-of-the-art, it may actually include the use of requirements specification. Because, sometimes, attempting to be too lean and entirely omit requirements specification does more harm than good.

When can you do without product requirements specification?

When is “pure” agile development without traditional requirements specification your best choice? These are situations where agile requirements practices mostly based on user stories will do a good job: One or few closely collaborating teams develop a system that exists in one or few instances only. This is, for instance, the case with low to medium size web services or mobile apps.

In addition to numbers of teams and product instances, you may wish a few more prerequisites to be in place for this approach to work out, for instance: Your development teams should have the opportunity of close customer and user involvement, and you may want your teams to be relatively stable (i.e., low turnover rate) over the system’s entire lifetime.

In this approach your requirements will hardly ever manifest explicitly in written form. User stories rather represent requirements but do not actually define them. Requirements mostly manifest in the implemented product release (or PSI, potentially shippable increment), and in your automated tests. But no kind of requirements statement will survive after the end of its development iteration or agile Sprint. The following figure illustrates this.Development without Product Requirements Specification

When do you need a product requirements specification?

There are quite some situations where you need a product requirements specification. (Of course, you should create and use it in a lean and agile manner.) These situations include:

High support and maintenance demands: Your customers or your business environment often raise questions of the types: Can the system do X or Y? What would be needed to accomplish Z? Having an up-to-date product specification will then tremendously ease your life.

Development of product variants: You develop not only one product but a wide spectrum of similar yet different variants. This is often the case with technical hardware/software devices like sensors or control units. Then you want to reuse existing assets instead of developing similar functionality again and again. Reuse of product requirements along with their implementation gives you the longest lever.

Subcontracted development: Here the degree of needed specification detail can vary, depending on your subcontractor relationship. However, nearly always some kind of requirements specification will form the core of the development contract. You better want to have this contract be clear and precise.

Regulatory compliance: You have no choice but to document your requirements explicitly. Requirements define essential product characteristics and design decisions that must be traced down further to implementation and test. The requirements specification also is the indispensable basis for controlled and auditable product change.

Wherever such situations exist, and they exist in tens of thousands throughout the industries, organizations will need product requirements specifications. These specifications complement product increments and preserve all relevant requirements information, as shown in the next figure.Development with Product Requirements Specification

Unfortunately, our competences to create and manage product requirements specifications have faded across many industries. Agile methods had too often been misunderstood that specification skills were not needed any more. And consequently, specification techniques did not keep pace with new agile approaches and have become outdated.

How can we revitalize effective and up-to-date requirements specification practices? The subsequent issues of this blog series propose an approach to requirements specification that fits well into modern agile product development and product management:

List of RM Tools Updated: September 2017 Version

The September 2017 version of our list of requirements tools is available. It contains a total of 91 requirements management (RM) tools. The previous version dated back from November 2016.

The new September 2017 list contains many updates that show the requirements tool market is currently in a huge transition and transformation phase. Several vendors have merged in the past year, and there are interesting new developments towards support of agile development.

From the 91 tools overall, we feature 14 in a list of selected tools. The selection is based on indicators of market share and market presence. It shall provide focused support to organizations that want to collect a longlist for tool evaluation and selection.

Overall, the main update activities include:

  • All tools have been checked for availability and up-to-date web links to tool and vendor pages
  • Three tools have been added, many tool entries have been changed (e.g., name changes, new product bundles), several obviously outdated ones have been deleted
  • All tools have been supplied with up-to-date version information (where available) and assigned to the relevant tool categories (e.g., RD, RM, Agile)
  • The list of selected tools has been reduced from 25 to 14 tools.

The list of selected tools has been reduced, because our objective is to provide even more focused support to organizations that want to collect a longlist for tool evaluation and selection. So, we have removed tools that apparently have not received significant maintenance over the past years, that have already well-established successor products, or that appear to have little relevance on the market overall.

Added:

  • Specification Wizard
  • OpenProject
  • ALM Octane

Renamed / Rebranded:

This time, quite many tools have been renamed or rebranded. For instance, the former HPE Software product family belongs now to Micro Focus. During this process, the tool HPE ALM has been renamed into ALM Enterprise. All name changes are marked in the list by adding the former name in parentheses. An example: “HelixRM (was TestTrack RM)”

Removed:

We have again removed several tools for the following reasons: (a) the tool has been discontinued, (b) it has turned out that the tool does not show sufficient functionality for requirements definition or management, or (c) the tool’s product or vendor websites have not received any substantial updates for more than two years.

  • Acclaro DFSS
  • Axure RP
  • Cameo Requirements+
  • IBM Notes
  • IdeaShare
  • Justinmind Prototyper
  • LeapSE
  • LiteRM
  • MockupScreens
  • QPack
  • ReqT
  • SPEQit
  • Telerik Platform
  • Troux Architect