Requirements reuse with Jama

On May 9th, 2014 Andreas Birk and myself presented the Webinar “Requirements reuse – requirements practices using the tool Jama” (in German)
We did show reuse practices which increase productivity and quality in development on a sustainable fashion.

Themes addressed:

  • Reusing requirements from previous releases
  • Reusing requirements form similar projects
  • Managing company wide guidelines as global requirements across projects
  • Managing product variants

We did show how Jama features help to address those scenarios, but also mentioned the challenges which need to be handled for such situations. The presentation is available on Slideshare.

This picture shows the various challenges an organization might encounter when establishing systematic reuse.
This picture shows the various challenges an organization might encounter when establishing systematic reuse.

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:

Requirements Practices with Jama

On March 22, 2013 Dr. Andreas Birk and Gerald Heller provided a webinar on well established tool based requirements management (RM) practices. Using the tool Jama as an example they visualized how

  • requirements are structured systematically
  • requirements are managed continuously
  • requirements and tests contribute to product success

The focus of the talk was the optimal interworking of tool and requirements practices. What needs to be done to fully utilize the potential of an RM tool? How can the tool help to broaden the RM practices in an organization.

Slides of the webinar are available on Slideshare: Structuring requirements with Jama

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.