List of RM Tools: New Version Upcoming

In a few days from now, we will publish the next updated version of our list of requirements management (RM) tools. The current version dates from February 2014. In the meantime, many vendors have released new extended versions of their tools, or they have otherwise changed their product strategy or portfolio. We could also add a few more relevant tools to the list.

The main tool updates and events since February deserve some more information and explanation than just an updated version number in the list. For this purpose, we are starting a small series of blog posts that feature interesting and important news from the tool market since last February. We focus on our “selected” subset of tools that we find particularly relevant. The blog posts will appear in roughly chronological order following the dates of the reported tool updates and events.

This is the list of all blog posts of the series that has been completed in the meantime:

The September 2014 update of the RM tools list has been published on September 25.

Agile Requirements Frameworks

by Andreas Birk and Gerald Heller

When agile methods emerged during the 1990s and until quite long into the first decade of the 21st century, agile requirements were widely synonymous with user stories. This was a major contribution and step forward for requirements practices on team level. However, for larger multi-team development efforts, for continuous product development as well as for product- and portfolio-level planning, effective guidance for agile requirements management was still mostly missing. This situation has improved gradually since around 2005 when frameworks for scaling agile appeared on the scene. Most notable examples are: Scaling Software Agility by Dean Leffingwell (2007) and Scaling Lean & Agile Development by Craig Larman and Bas Vodde (2008). Follow-up publications of these authors have provided valuable additional guidance also for requirements management. In particular, Dean Leffingwell published the first comprehensive agile requirements framework in 2010: Agile Software Requirements, the approach is now known as the Scaled Agile Framework (SAFe).

Today, we have quite a variety of agile requirements frameworks. But now it has become difficult to survey the entire scene and find the suitable approaches relevant for one’s own specific software or system development context. For this reason, we want to give an overview here, providing orientation and guidance in the growing field of agile requirements management. You find a survey of those frameworks we find most important along with links for further information. Of course, this selection is subjective, and for sure we have overlooked some important approaches. So we will be grateful, if you can comment on the following list and send us additional hints (feedback link). We will include them into future updates of this list.

Scaled Agile Framework SAFe (Leffingwell)

SAFe has been the first comprehensive framework for agile requirements management, defined by Dean Leffingwell. Published in its initial version in 2010 and partly based on earlier works, we view it still as the most important reference and entry point for agile requirements management. The website provides a very rich collection of valuable information. The book is an excellent introduction and resource on agile requirements. Dean Leffingwell’s earlier book makes a good extension for understanding the large-scale agile development process.

Scaling Lean & Agile Development LeSS (Larman, Vodde)

LeSS does not focus on requirements management in particular, rather it addresses the entire spectrum of agile development activities. However, it includes very many practices and techniques relevant to agile requirements management. A good introduction to LeSS is the May 2013 article in CrossTalk magazine. Additional information provide the homepages and blogs of Craig Larman and Bas Vodde. An interesting experience report is the article on Large Scale Scrum (LeSS) @ J.P. Morgan at InfoQ. The comprehensive resources are the two books on basic concepts (2008) and on practices (2010) of the approach.

Disciplined Agile Delivery DAD (Ambler)

DAD is a “process decision framework” that aims at helping projects and organizations to create their suitable agile development approaches. As such it includes various agile requirements practices along with guidance to design requirements and software delivery processes. The approach is relatively new, dating from 2012. There is an accompanying book available.

Discover to Deliver (Gottesdiener)

Discover to Deliver is an approach to agile product planning and (requirements/business/system) analysis. It extends established product planning and analysis techniques and transforms them into the agile world. A book introduces the approach, and a short 2-minutes video clip explains the essential concepts.

Specification by Example SBE (Adzic, Fowler, and others)

“Specification by example (SBE) is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements.” (Wikipedia) It provides a consistent framework to agile requirements management utilizing high-level tests and test automation. Among the main proponents are Gojko Adzic and Martin Fowler. Gojko Adzic maintains the website and has written a good instructive book on the topic. Martin Fowler has written a concise article that motivates and introduces the approach.

Acceptance Test Driven Development ATDD (Gärtner, Koskela, and others)

ATDD is another consistent approach for accomplishing agile requirements and testing tasks in an integrated fashion. It features several agile requirements practices that can be very useful in the context of other approaches as well (e.g., the Given-When-Then template for specifying system behaviour and tests). A Wikipedia article provides a good introduction. Introductory books are available from Markus Gärtner. Lasse Koskela has written a brief introduction as well as a very instructive book on ATDD.

User Stories Applied (Cohn)

User stories are the nucleous or starting point of all agile requirements management. Mike Cohn’s classical book on the topic provides an excellent introduction and explains the application of use cases in agile development projects.

Use Case 2.0 (Jacobson)

Ivar Jacobson has coined the concept of use cases as early as in the 1980s. With Use Case 2.0 he and his colleagues have refurbished the use cases approach for the agile age. The approach differs partly from other agile requirements frameworks (e.g., stronger emphasize on more or less formal information structure and (only) apparently less emphasis on stakeholder communication procedures). However, this makes it particularly relevant as a source of additional inspiration for agile requirements managers. It also can provide important guidance for environments in which other agile approaches don’t appear suitable (e.g., possibly in development of technical products using model-based approaches). An eBook explains the approach.

Agile Product Canvas (Pichler)

Roman Pichler is the author of the book Agile Product Management with Scrum (2010). Since then he has developed several additional and very useful tools. One of them is the Agile Product Canvas, which collects all important overall product-related requirements information on one easy-to-understand and easy-to-use pane.

Agile Modeling & Agile Documentation (Ambler, Rüping and others)

Quite early during the emergence of agile methods, Scott Ambler and Andreas Rüping had taken attention to aspects beyond coding. First, Scott Ambler wrote a book on agile modeling (2002). He also now maintains a comprehensive website on the topic, which contains a good overview article. Soon later, Andreas Rüping has added another book on agile documentation (2003). In 2012, Andreas Rüping published an updated and extended version of the book (available in German only). These works complement the other frameworks on agile requirements management by providing guidance also for the interfaces of requirements management to adjacent disciplines like graphical modeling (e.g., business process models, UML, SysML), architecture specifications, and user documentation.

At the end of this article, let us emphasize again: We will be very glad, if you share your thoughts on agile requirements management with us. Do you disagree with (parts of) what we have written here? Would you have additional framework suggestions? Do you have agile requirements experiences that you want to share with others? Don’t hesitate to contact us via

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.