Survey of Requirements Tools Lists

For the February 2014 update of our list of requirements management (RM) tools, my colleague Gerald Heller and I researched for other lists of requirements tools, in order to extend and complement our collection. In the following you find the results of our investigation. Each list has its specific strengths and focus areas that are outlined in brief comments on each entry.

Requirements Management Tools

INCOSE’s RM Tools List ( has been the first large RM tools list we know of that was researched systematically. It is supplied with an extensive collection of (vendor-provided) tool characterizations. Unfortunately, the last update is from 2010 and much information stems even from 2008, so that most of the detailed tool information must be regarded outdated.

Volere’s RM Tools List: Vendors provide their own brief tool characterizations. Much information is not fully up to date. But the rather extensive list provides an easy to read overview of the RM Tools landscape.

Iain Alexander’s ’s RM Tools List at includes many tools that are not contained in INCOSE’s and Volere’s collections. A large subsection is on tools for requirements quality analysis.

The Tools Journal’s RM Tools List ( is another list that provides a good overview of tools. But it also most information is not up-to-date.

Capterra’s list of requirements management products ( contains about 40 tools and provides filtering support with regard to tool features.

Ludwig Consulting Services provide a fairly up-to-date list ( that has last been updated in 2012 but also mentions some outdated tools. It includes a brief informative introduction text and contains some tools not provided in the previous lists.

IEEE Software magazine from July/August 2011 includes a tools survey ( that contains an elaborated overview characterization of 37 tools. The authors have set up a web page with brief characterizations of the tools. A PDF version of the article is also available from Vector’s media portal.

Ideation Tools

Ideation tools list at It contains tools from various different areas, many of which can be relevant in certain requirements elicitation and requirements definition activities.

Agile Tools

Lists of agile tools at agileSCOUT: The extensive list, grouped into two web pages on Scrum and Kanban tools, provides a good overview using a screenshot for each tool.

Steve Blank’s list of agile tools is part of his “Startup Tools” list (see subsection “Kanban and Scrum Tools”) and focuses on mostly light-weight tools that can be relevant to software startups:

Business Modeling Tools

Wikipedia page on tools specifically for BPMN notation:

Listly’s BPM tools list ( contains 62 tools, with embedded media (screenshots, video clips) for some of the tools.

Process-Symphony blog presents a list of ten selected tools, along with an evaluation and rating:

BPM-Software blog focuses on free tools:

UML Tools

The wikipedia list of UML tools ( provides tabular tool characterizations and feature overviws. It also contains links to other lists of UML tools.

OOSE’s list of UML tools: The list includes a table of detailed information provided by vendors, dating from 2012/2013.

The list at Listly offers screenshots, brief overview texts and possibilities for user voting and for user comments:

UI Mockup / Wireframing Tools

Steve Blank’s list of wireframing tools as part of his “Startup Tools” list (see subsection “Wireframing Tools”): presents a list of wireframing tools ( along with guidelines and recommendations for tool evaluation.

The App Entrenpeneur website at lists web apps as well as Android and iOS mobile apps with brief one-line characterizations of each tool.

Memeburn’s specialty is a list ( with embedded video clips from most of the tool’s vendors.

Econsultancy provides at wireframing tools and and additional resources.

A commented list of selected tools is presented by ( list tools along with platform and price information. It also contains some less conventional but interesting recommendations.

Last but not least, two lists of free wireframing tools:

Software Requirements Defined

When working with software requirements, it is sometimes  useful to reflect about what exactly software requirements are? As with most software engineering terms, also for software requirements there doesn’t exist a generally agreed-upon definition. So one can best attain a deeper understanding through consulting and comparing multiple alternative definitions.

My favorite definition of software requirements is the one from Sommerville and Sawyer:

Requirements are […] a specification of what should be implemented. They are descriptions of how the system should behave, or of a system property or attribute. They may be a constraint on the development process of the system.

(I. Sommerville und P. Sawyer, Requirements Engineering: A Good Practice Guide, 1. Auflage. John Wiley & Sons, 1997.)

This definition is crisp, easy to read, and covering the most essential aspects of requirements. It does also not stipulate that requirements needed to be documented, which makes it cover also the use of requirements within agile software development.

Perhaps the most frequently cited definition has been developed by a committee of the IEEE Computer Society. It distinguishes three different meanings of requirements. So it is rather precise but also a bit difficult to read and comprehend:

(1) A condition or capability needed by a user to solve a problem or achieve an objective.
(2) A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
(3) A documented representation of a condition or capability as in (1) or (2).

(The Institute of Electrical and Electronics Engineers (IEEE), IEEE Standard Glossary of Software Engineering Terminology/IEEE Std 610.12-1990. IEEE Publications,U.S., 1990. – First edition from 1983)

In the following you find several additional definitions in chronogical order of appearance.  So you can also get an impression of how our view of software requirements has evolved.

Gause & Weinberg, 1989

If you employ other people to help you develop what you want, you’d describe what you want for them. That description is called a problem statement or a set of requirements […]. Obviously, requirements are important because if you don’t know what you want, or don’t communicate what you want, you reduce your chances of getting what you want.

(D. C. Gause und G. M. Weinberg, Exploring Requirements: Quality Before Design. Dorset House Publishing Co Inc.,U.S., 1989.)

Note: Most early literature on requirements does not explicitly define the requirements term but rather circumscribes requirements and their role in software development.

Robertson & Robertson, 1999

Something that the product must do, or a property that the product must have.

(S. Robertson und J. Robertson, Mastering the Requirements Process: Getting Requirements Right. Addison-Wesley Longman, Amsterdam, 1999.)

Wiegers, 1999

A statement of a customer need or objective, or of a condition or capability that a product must possess to satisfy such a need or objective. A property that a product must have to provide value to a stakeholder.

(K. E. Wiegers, Software Requirements, Second Edition, 2nd Ed. Microsoft Press, 2003. – First edition from 1999)

Gottesdiener, 2002

The needs or conditions to be satisfied on behalf of users and suppliers.

(E. Gottesdiener, Requirements by Collaboration: Workshops for Defining Needs. Addison-Wesley Longman, Amsterdam, 2002.)

Cohn, 2004

Software requirements is a communication problem.

(M. Cohn, User Stories Applied: For Agile Software Development. Addison-Wesley Longman, Amsterdam, 2004.)

Note: Most literature on agile development avoids providing explicit definitions of requirements. The authors rather circumscribe agile requirements concepts, they describe the role of requirements-related information during the agile development cycle, or they explain requirements-related agile practices. This is surprisingly similar to the lack of explicit definitions in the early stages of the software engineering discipline during the 1980’ies and during the 1990’ies.

Robertson & Robertson, 2012

Something that the product must do, or a property that the product must have, that is needed or wanted by the stakeholders.

(S. Robertson und J. Robertson, Mastering the Requirements Process: Getting Requirements Right, 3rd revised edition. Addison-Wesley Longman, Amsterdam, 2012.)

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.

Pathways to Requirements Based Testing

Andreas Birk published the article “Pfade zum Requirements-basierten Testen” in issue 17 of the German SQ Magazin. He elaborated several paths how to achieve requirements-based testing. In summary: Test manager can benefit substantially from an established requirements process. Therefore it’s in their best interest to take action and drive the requirements practice in their organizations.
The SQ Magazin is available from the ASQF website.

Agile Metrics Grid

Recently, Gerald Heller an I discussed about metrics used in agile development, agile testing metrics in particular. We found quite a number of relevant metrics and sought a way to structure them. Partly inspired by Brian Marick’s testing quadrants (see Lisa Crispin’s presentation), we ended up with a matrix spanned by two dichotomous axes.

The first axis (horizontal axis) distinguishes between coordinative and analytical metrics usage. Coordinative metrics are well-suited to directly support project activities, information needs, and decisions. Examples are tracking of work item status or burndown. Analytical metrics are used as input to investigations and analyses as they are conducted, for instance, in iteration retrospectives. An example is story cycle time, which shall be investigated at the end of a release in order to look for improvement opportunities for subsequent releases.

The second axis (vertical axis) distinguishes between internal and external metrics target groups. Internal target groups are the members of an agile software development team. External target groups are other stakeholders such as development management and product management.

The following figure shows our proposed agile metrics grid along with a number of categorized agile metrics. The grid helps guiding metric definition and clarifying the role that a given metric plays for agile development.

The agile testing grid is described in more detail in issue 4 of Agile Record, a magazine for agile developers and agile testers.