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/

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

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.

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.

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:

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