What Software Tools Support Requirements Management?

Requirements Management (RM) is a very complex task that can only be accomplished with the support of suitable tools. Even small software projects need at least some manual tools like index cards or flip charts for supporting clarification and communication of requirements.

This blog article investigates what kinds of software tools can be used for supporting requirements management. Specialized RM tools are spreading across the industry since a few years. (Look up our list of RM tools for examples.) We will see that they are only one of many different kinds of tools (although an important one) that support requirements practices.

This list of tool categories has matured over a series of inspiring discussions with my colleague Gerald Heller. I highly appreciate his contributions and comments.

Specialized RM tools have evolved dramatically over the past years: Functionalities of the individual tools have grown and improved very much, and the number of viable tool solutions has grown significantly. These tools define each requirement as a record of attributes (i.e., record-based RM), can link requirements with each other, and provide analysis, reporting, and document generation functionality. Perhaps most important, specialized RM tools allow for concurrent editing and change tracking. Increasingly, RM tools also offer to edit requirements in a manner very similar to text processors (i.e., document-oriented RM).

It is important to emphasize that specialized RM tools are not plug-and-play solutions. Rather, they are platforms that must be customized to the specific information structures, processes, and context factors of the specific software development or requirements management organization.

Within the family of specialized RM tools, two different groups can be distinguished: Traditional record-based RM tools and agile RM tools. Agile RM tools provide the specific concepts and processes for efficient agile requirements. According to common agile practices, they link requirements (mostly in the form of agile user stories) with tasks. So they represent a combination of RM functionality, project management, and issue tracking.

Specialized requirements development tools (RD; also denoted requirements definition tools) address the early phases of eliciting, analyzing, and documenting requirements. They provide functionality like brainstorming support and structured group discussions. RD tools evolve as an important addition to RM tools. On the long run, both tool types might merge into combined RD and RM tools.

For a more detailed discussion of RM and RD tools, you can refer to Gerald’s blog article on RM/RD tool characteristics.

Office applications and suites are still the most widely used tools for developing requirements specifications and managing individual requirements. Their advantage is that they are ubiquitous and everybody knows how to use them. Their severe disadvantages are that they are lacking any specialized RM functionality like treating each requirement as a separate entity and requirements traceability, and that parallel editing of documents is not supported. So, I recommend to use office applications (albeit in a well-planned and structured manner) as an entry solution for systematic RM, but to move to specialized tool support when needs become more complex.

Word processors are the office application most commonly used for RM, particularly for developing RM specification documents. It is highly recommended to define the structure of the documents prior to starting actual specification work, for instance by using templates and example documents. A person should be assigned to ensuring that the document structure is always considered and evolved when needed.

Several years ago, I witnessed a project that very systematically approached requirements management with Microsoft Word. They defined a master document, which consisted of several sub-documents. Each sub-document was written and managed by a separate team, enabling efficient work distribution. However, nowadays specialized RM tools with their advanced report generation features are the most efficient solution for such situations.

Spreadsheet software allows managing each requirements as a separate compound object of attributes and attribute values. This comes at the expense that a requirements can only be presented as lists or tables. Document-like views are hardly possible.

Presentation software is also quite often used for defining specification documents in the form of slide presentations. However, such specifications tend to stay on high levels of abstraction. People usually don’t put much detail into these specifications. This can be acceptable for smaller work packages in stable environments. But it will definetely be insuffient for any larger development effort.

Visual modeling tools for developing and managing graphical models in notations like Unified Modeling Language (UML), Business Process Process Model and Notation (BPMN), or Systems Modeling Language (SysML) are an important pilar of many specificiations. However, in most situations they should not be the sole environment for defining requirements. Rather, visual modeling tools should be used together with and integrated well with specialized RM solutions.

Issue tracking software (also denoted request, problem, or defect tracking software), especially in its variant of work item tracking software, is also a frequently used solution for implementing and supporting RM. In particular for situations where individual requirements need to be managed instead of large compound specification documents, issue tracking software can be a very viable solution for RM.

The tool categories described above might be the most relevant ones, covering the vast majority of RM tool applications. However, there are also several other categories of software tools that can be used effectively to support RM:

In addition, there are some tool families that can add specific value to RM tools:

  • ALM suites integrate RM functionality with support for many other development activities and phases.
  • Testing and test management software enable or facilitate requirements-based testing.
  • Configuration management and revision control tools add specifically to office applications and partly compensate for a shortcoming of office applications when compared to specialized RM tools.
  • Software engineering platforms and integration middleware integrate RM tools with other tools along the development lifecycle.

Having now unfolded the wide spectrum of RM tool support, what do we learn? First, there is not one single best way to tool-based RM. Rather, every organization must consider its specific situation and constraints (e.g., tool solutions in place for other development and management areas) and develop its customized RM tool solution.

Second, specialized RM and RD tools provide a reliable basis for RM, and they will continue to becoming increasingly important. The wide variety of different RM tools creates new challenges: How can we systematically evaluate and select the tool most suitable for us? How can we consolidate a grown tool landscape that includes many different RM tools? How can we align the usage of a consolidated RM tool across several independent entities of a larger software organization?

So it is clear: Tool-based RM will progress further, and we are looking forward to a highly interesting (while challenging) future.

RM Tools – What Are They Anyway?

There is time for a new class of requirements tools. Those do not only support classical requirements management, but also requirements activities, that help to improve the collective understanding of requirements through illustration and collaboration and therefore ultimately serve to build better products.

There are quite a few requirements management (RM) tools out in the market. Did you ever wonder what qualifies them as an RM tool? This question is of specific interest, when you are in the process of selecting a requirements management tool for your organization.

A good starting point for the evaluation of tools is to get insights about your driving needs.

  • What should the tool do for you?

Sometimes, I simply hear “support the RM process”. In other situations I get statements like:

    • ease the documentation burden
    • provide access to requirements for all stakeholder
    • speed-up requirements discussions

The latter situation is better, because it is always helpful working towards your own goals. What is it that you want to accomplish? If you know this, then you get a clear guidance what are the most important features of any given tool for you.
The statement “support the RM process” is more tricky and interesting to explore.

What is Requirements Management?

At first glance one might think, that’s not a big deal because RM is defined. We only need to look at the published definition, check the associated activities and voilà we have something we can compare tool features against. But when you dig into the details about RM you might get puzzled. Definitions about RM aren’t so clear and consistent. When Andreas Birk and I did a recent research about RM definitions we found out, that definitions substantially differ. Below are some prominent examples for Requirements Management:

Karl Wiegers, In search for excellent requirements, 2004:

Manage versions of requirements documents
Adopt and enforce a change control process
Store requirement attributes
Track the status of each requirement
Trace requirements into designs, code, and tests

BABoK Guide, Version 2.0

The activities, that control requirements development,
including requirements change control,
requirements attributes definition, and
requirements traceability

IREB CPRE Foundation Level, May 2009

Adding Attributes to Requirements
Creating Views of Requirements
Prioritizing Requirements
Tracing Requirements
Requirements Versioning
Dealing with Change Requests

Already from these three examples we can see that there is a floating boundary between support of requirements development and requirements management. So, where do we go from here? A good approach is to distill commonalities from the definitions and construct a criteria list:

Requirements management should support all activities to

    • define and structure requirements
    • discuss requirements
    • prioritize requirements
    • maintain status on requirements
    • track changes of requirements
    • version requirements
    • trace relationships between requirements and other development artefacts
    • communicate about requirements

That provides a great start. We now have some objective criteria to check whether a tool can call itself a requirements management tool. Comment: Will Microsoft Word qualify as RM tool?

But, we aren’t done – these are just the basics.

Beyond Basic Requirements Management

When we look at the feature lists of prominent “RM Tools” we will notice, that vendors typically provide a much richer set of features. There are several reasons for that. On one side rich feature sets are business differentiators. If product A provides “killer features” that other products don’t have, it will have some competitive advantage for the company who sells A.
On the other side a rich feature set for RM may also be rooted in the nature of the requirements management process. Being a central part of product development, requirements management has many interfaces to adjacent processes and tools.

Tool vendors have the option to either provide interfaces to the adjacent processes or incorporate support for these adjacent processes directly in the tool.

Especially products, that are out in the market for quite some time, often show the latter approach. In recent years the term “Application Lifecycle Management” (ALM) became prominent. It is used in situations where a tool provides support for several (or all) phases in the application lifecycle.
While this may suit some companies it imposes challenges too. Often companies have already deployed tools in adjacent areas and are then forced to evaluate what tool solution should be used going forward.

Therefore, ALM in a single tool may only be beneficial for some companies.

New Trend: Visualization and Collaboration

Another trend I observe, is that tools provide more support for the early phases of requirements engineering. In these phases requirements aren’t that clear, but are under constant development. That’s why Carnegie Mellons Software Engineering Institute (SEI) summarizes these activities as “Requirements Development”. There is constant morphing between wishes, ideas, requirements and solution prototyping. To support these activities tools should provide support for

    • ideation
    • conceptualization
    • joint understanding
    • collaboration

When requirements aren’t that clear often visualizations help to move forward. In recent years more and more tools offer visualization features for requirements representation. This may range from support for rich media formats like pictures and movies, to support for sketches, storyboards, mockups and finally to support for modeling activities with varying degree of formal notations.
An optimal complement to visualization concepts are collaboration features. Requirements engineering demands interaction between stakeholders. Fortunately the trend to social media software has also spread to the requirements tools market. Use of social media functionality improves requirements understanding and reduces the risk building the wrong product. This is a great advance in requirements engineering.

In summary, I believe that there is time for a new class of requirements tools. Those do not only support classical requirements management, but also requirements activities, that help to improve the collective understanding of requirements through illustration and collaboration and therefore ultimately serve to build better products.

Watch out for these type of tools when selecting a requirements tool.