software engineering applied

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:

• Document management solutions
• Wiki software
• Mind-mapping software
• Custom-built database applications
• Product management software (including portfolio and release management software)
• Project management software
• DSL workbenches
• Variant modeling and variant management tools

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.