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

Atlassian Confluence is one of the most widely used Wiki systems among software development teams. Besides other application areas it can be used to support requirements management (RM).

This article surveys relevant information resources and gives basic advice on RM with Confluence. It starts with Confluence-specific topics, touches the integration of Confluence with Atlassian JIRA, and concludes with recommendations on how to use Confluence for RM, also taking into account the inherent complexities of RM.

What is Confluence?

The Atlassian Confluence product homepage lists the main features of the tool and links to additional information. It positions the tool as a central work environment and structured information repository for teams, and for software teams in particular.

Atlassian’s central documentation homepage includes the links to the documentation pages of Confluence’s cloud and server product variants.

How to Use Confluence for Requirements?

For managing requirements, Confluence is superior to office applications, which are most commonly used as simple, entry-level solutions for requirements specification. Among Confluence’s advantages are:

• One central point of reference for all requirements, always up to date
• Version control of requirements changes
• Access control for viewing and eding requirements
• Some automation support for frequent RM tasks
• Collaboration support like automatic notification of team members upon changes

Atlassian, when positioning Confluence as an RM solution, focuses on the so-called Product Requirements Blueprint. This is a template page that ships with Confluence and that provides some basic automation for RM tasks.

The most relevant information resources from Atlassian on RM with Confluence are:

• Documentation page on Product Requirements Blueprint at the Atlassian documentation hub for its latest product version. The page shows how to create a new Confluence page using the Product Requirements Blueprint, and it outlines the main features of the blueprint template.
• Blog article “How to document product requirements in Confluence” explaining the use of the product requirements blueprint. This is an illustrative example of how to set up a page from the blueprint template, and how you can represent requirements and include UI designs.—Be aware that this example is very simplistic. See below for guidelines on more complex specifications.
• The example requirements specification page whose creation is described in the blog article is available as a separate picture file.
• An overview page on “Confluence for Software Teams” includes the link to the above blog article. It contains links to various additional topics like creating customer interview pages and release planning.
• The contents of the blog articles are also available as a PDF ebook titled “Software Team’s Guide to Confluence”.

Confluence and JIRA

The combination and integration of Confluence with its Atlassian sister tool JIRA provides particular advantages for RM, and for software team collaboration and project management in general: You gain coherent and consistent information management, task management, and progress monitoring across the entire application lifecycle and all software development workflows. In addition, there are various automation options around software change, configuration management, project planning, and monitoring.

Atlassian provides a documentation page on how to “Use JIRA applications and Confluence together”. It explains the prerequisites, lists the main integration options and use cases, and provides a summary table of the features and their required products, product variants, and version.

In summary, the main integration mechanisms for JIRA and Confluence are:

• Collect and display JIRA issues on a Confluence page
• Include reports and charts with information from JIRA into Confluence
• Easily create JIRA issues from text contained on Confluence pages
• Navigate from JIRA to Confluence and vice versa using links

Recommendations

Prefer Confluence over office applications

When you specify requirements mainly with office applications, text processors in particular, and already have Confluence in place, then you should consider to switch your software specifications to Confluence. Effort and risk of switching should be fairly small, and immediate gains and benefits very high.

However, keep in mind that every change in work practice and tooling requires some degree of planning, preparation, and guidance: Train and coach users, possibly provide page templates and usage conventions, and monitor how the Confluence spaces and pages develop.

If you, too, manage requirements with spreadsheet applications, you might consider to switch this part to JIRA. Information structuring and management in JIRA are similar to spreadsheets (as far as typical requirements tasks are concerned), and you gain benefits like versioning and integration with Confluence.

Prepare for requirements complexity

Requirements, like the software systems they specify, are inherently complex. Different persons or teams collaborating during requirements definition might have different or even incompatible work practices and documentation styles. No tool can dissolve this. You and your teams must face these challenges and manage them.

Take a look at Atlassian’s example Confluence page for requirements specification using their Product Requirements Blueprint: It is an excellent illustration of what the blueprint template provides for requirements specification. However, it is everything but a realistic specification document.

For instance, even the simplest software system has far more requirements than you want to put into one table on a Wiki page. Requirements belong to different aspects that you might want to separate into different specification documents—e.g., different functional dimensions or subsystems, or separating technical data requirements from user experience design. These specification parts interrelate: So, how do you capture and document dependencies? etc. etc.

Before you “just use” Confluence for requirements specification, consider questions like the following:

• What shall be the scope of specifications put into a Confluence space?—Everything in one space? Each customer variant of the system in a separate space? One space for each major product release?
• What shall be put into a single Confluence page?—Separate pages by functional groups? or by specification dimensions like functionality, legal, data, and user experience?
• How shall individual requirements be described?—As sections in a text flow? As table entries? What attributes / column shall the table have?
• Do we want predefined, detailed page templates?

Prepare to extend your requirements solution over time

Confluence is great for some kinds of requirements specification. But no tool can be suitable for everything. Be aware that you might gradually evolve and extend the ingredients of your requirements solution.

JIRA is a good companion of Confluence. You can add it quite easily even to ongoing projects, and you deepen the integration on the fly. At one point you might possibly switch the lead role between the tools. For instance, start ideation of a new system in Confluence; but when you are in implementation mode, then add new detailed requirements in JIRA.

It can also become necessary or beneficial to further extend the tool platform: There are specialized JIRA add-ons for requirements management. And you possibly need to integrate with other requirements or ALM solutions.

All this can become relevant, and you better should be prepared. However, as long as a simple solution works fine, keep it! Confluence can definitely be a fairly simple, stable, and very smart solution for many requirements tasks.