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:

  • Product Requirements Specification: Product Perspective (coming soon)
  • Product Requirements Specification: System Perspective (coming soon)
  • Product Requirements Specification: Integrating Product and System Perspective (coming soon)

New Version of RM Tools List: March 2019


The new March 2019 version of our list of requirements tools is available. It replaces the previous version from September 2017. The new list contains a total of 78 requirements management (RM) tools.

We observe that the trend of the previous years has continued: The market consolidates further. Heavy-weights from the early days of tool-based requirements management during the first decade of this century retire. A notable example is Caliber from Micro Focus, which hasn’t received any major update for years. Several tools apparently haven’t gotten enough traction and were withdrawn by their vendors. On the other hand, several products have obviously grown stable customer bases and continue to offer advanced features that enable up-to-date requirements management.

From the 78 tools overall, we feature 13 in a list of selected tools. The selection is based on indicators of market share and market presence. It shall also provide a starting point for developing a longlist for tool evaluation and selection.

The main update activities include:

  • All tools have been checked for availability and up-to-date web links to tool and vendor pages
  • 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 14 to 13 entries

The list of selected tools is kept small, because our objective is to provide 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.

This time, we haven’t added any new tools. The reason is that we didn’t come across convincing new market entrants that appear mature enough yet to represent viable alternatives to established players. However, we have spotted a few interesting newcomers and put them onto our watchlist for future updates of the tools list.

Renamed / Rebranded:

Again, several tools were renamed or rebranded. For instance, the company Jama software had just one requirement management product in the past. Now they have an additional data analytics product. Therefore, the previous “Jama” RM product was renamed to “Jama Connect”. All name changes are marked in the list by adding the former name in parentheses, for example: “Storyteller (was Blueprint)”.

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.

  • Accompa
  • Agile Manager
  • AgiloEnvision VIP
  • Focal Point
  • jUCMNav
  • Mingle
  • MooD Platform
  • ProR (Eclipse RMF/ProR)
  • ReMa
  • ReqPOOL Requirements Manager
  • RMTrak
  • Rommana ALM
  • TopTeam Analyst

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

Requirements Management with Atlassian Confluence

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:

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.

List of RM Tools Updated: November 2016 Version

The November 2016 version of our list of requirements tools is available. It contains a total of 101 requirements management tools. The previous version dated back from February 2016. Several vendors have since released new versions of their tools that we have referenced in the list.

From the 101 tools overall, we feature 25 in a list of selected tools. The selection is based on indicators of market share and market presence.

The extensions and updates to the November 2016 release of our RM tools list include:

  • All tools have been checked for availability and up-to-date web links to tool and vendor pages
  • Some tools have been added, some tool entries have been changed
    (e.g., product name changes, company acquisitions, new product bundles)
  • Several 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)

Overall, the following tools have received major updates between February 2016 to November 2016:

  • codeBeamer Requirements Management
  • Enterprise Architect
  • Innovator for Business Analysts
  • Mingle
  • objectiF RM

Important changes occurred with regard to tool vendors: Siemens completed the acquisition of Polarion. It is now a product of the Siemens corporation. In May Micro Focus completed the acquisition of Serena which added some requirements management and agile tools to the Micro Focus portfolio. In September HPE and Micro Focus announced their intention to spin-merge HPE Software.

Concerning the set of tools included in the list, we have performed the following changes during our November 2016 update:

Added:

  • Atlas from Micro Focus
  • Workspace.com from Workspace.com

Renamed / Rebranded:

  • in-STEP RED now objectiF RPM
  • ontime now axosoft
  • Agilian now Visual Paradigm

Removed:

We have again removed several tools that have been discontinued, or whose product or vendor websites have not received any substantial updates for more than two years.

  • AgileZen – no longer available for purchase
  • Avenqo PEP – inactive
  • Axiom – inactive
  • ArcWay Cockpit – inactive
  • Enfocus Requirements Suite – no product information on website
  • GatherSpace – inactive
  • Objectiver – inactive
  • QFDcapture – inactive
  • TeamPulse – no longer available for purchase
  • X-Tie-RT – not available for purchase
  • YAKINDU Requirements – no product information on website