Evaluating Requirements Management Tools Available on Docker Hub


Whenever evaluating tools for a particular application, it’s wonderful to see containers ready for use in some container repository. The availability of an application on a public container repository also suggests the company is keeping up with new technologies. For startups and lean companies, containerized infrastructure enables the internal applications team to keep up with rapidly changing company needs. In the treatment of requirements management tools, however, these companies can often implement solutions which are either too much or too little. For example, requirements management wrapped in GitHub may make traceability, visibility, and effective planning difficult. However, a powerful solution like the IBM ecosystem may be far more overhead than it’s worth for small teams. In reality, a solution somewhere in the middle may be perfect. This report explores two requirements management options, which are available for immediate experimentation and use through containers available on Docker Hub. These solutions also feature REST APIs, so they can be integrated with orchestration and automation tools using standard means.

A few guiding questions serve as a lens for the analysis of these two software tools: CodeBeamer and JIRA. The establishment of these guiding questions, presupposed by experience, limits deeper exploratory investigation. However, the benefit is an unbiased and consistent means for evaluation of both the tools. Software companies are diverse - what works great for one company may be a poor fit for other companies. As such, a consistent evaluation criteria for both the software tools should not be seen as a means of determining tool superiority.

  1. How does the tool capture requirements?
  2. If/how requirements can be linked to other requirements or documents (e.g. test cases)?
  3. Does the tool support distributed use by multiple analysts?
  4. Is requirements modeling supported (e.g. use cases, state machines, or graphical representations)?
  5. Can version control and configuration management practices be used with the requirements?
  6. Are there any features for consistency or completeness checking?

Experimental Setup

The Dockerized evaluation versions of the two software packages have some fundamental differences. These differences are mentioned beforehand in case there are any obstacles to further progress for potential users. For example, the JIRA (owned by Atlassian) image on Docker Hub is not provided by Atlassian itself - using third party Docker images may violate a company’s security policy.

Owned byIntland Software GmbHAtlassian
Developed byIntland Software GmbHAtlassian
Development HQStuttgart, GermanySydney, Australia
Available on Docker HubYesYes
Docker Hub Verified PublisherNoNo
Docker Hub Official ImageNoNo
Third Party Image ProviderNoYes
On-Prem OfferingYesYes
SaaS OfferingYesYes

Figure 1: CodeBeamer and JIRA - The Basics



CodeBeamer is more than just a requirements management tool, although requirements management is at the core of the product. More broadly, CodeBeamer can be categorized as an application lifecycle management (ALM) tool.

In a marketing video, the company includes the following in the tool’s scope [1]:

  • Demand Management
  • Requirements Management
  • Development Management
  • Quality Assurance and Testing
  • DevOps

Of course, “Development Management” and some of these other terms are rather vague. Various documentation and marketing content does provide some additional detail on this. However, for the scope of this report, only the “Requirements Management” features are analyzed. After spinning up the Docker container for CodeBeamer, using a straightforward process detailed on the Docker Hub page, a setup wizard is presented to the user. After configuration, a project needs to be created.

Conveniently, both templates and demos are available for project preconfiguration. With templates, the project structure is preconfigured. The demo setup enables not only project structure preconfiguration, but also the population of the database with example data. Marketing materials emphasize the ability of CodeBeamer to handle Agile workflows, as well as Waterfall and Hybrid workflows. This is seen first in the project configuration, where a variety of workflows are supported through the available templates and demos. Included in these options is a SAFe (Scaled Agile Framework) template. For the investigations in this report, an Agile workflow was selected - the “Scrum” template.


Figure 2: CodeBeamer Setup Wizard


Figure 3: CodeBeamer Scrum Template Setup


The marketing materials on atlassian.com don’t provide a concise description for the JIRA tool. That is, unless you count the rather vague “the #1 software development tool used by agile teams” [2]. Perhaps a better description is contained in the metadata of the same page - the HTML meta description. That description captures the proposed value proposition - “plan, track, and manage your agile and software development projects in JIRA. Customize your workflow, collaborate, and release great software” [2].

The Docker image for JIRA evaluation is provided by Danish developer Martin Aksel Jensen, with associated code available in a public GitHub repository [3]. Similar to CodeBeamer, spinning up a Docker container is straightforward when following the documented process. A setup wizard guides the user through getting started. A demo project is available for installation after the basic setup, in order to enable JIRA evaluation with real data. Instead of specifying workflow types during installation or con figuration, JIRA takes a more changeable approach. Namely, the underlying software structure is the same, and can be used for Agile and non-Agile projects alike.

Requirements Management


The requirements management is available under the main menu item “Trackers”. The default view shows a requirements tree for a left panel, a feed-looking view in the middle, and a requirement detail panel on the right. Requirements can be added and edited in this default view, but the features available when doing so are somewhat restricted. Once the requirement has been created through this basic interface, further configuration is possible on the requirement detail page. Within this view, we can begin to connect the CodeBeamer approach back to the initial requirements management evaluation criteria.


Figure 4: CodeBeamer Requirements View


Figure 5: CodeBeamer Quick Insert

How does the tool capture requirements?

The primary means for requirements creation would be the GUI or the REST API. Requirements are stored as work items, as are epics, user stories, tasks, bugs, and test runs. The format consistency / portability may be valuable for easier compliance, tracking, and data management.

If/how requirements can be linked to other requirements or documents (e.g. test cases)?

The Traceability section of the requirement detail page shows extensive traceability capabilities. Requirements can be linked to epics, releases, teams, test sets, test cases, other requirements, and more. Further, parent-child relationships can be used when defining requirements.

Does the tool support distributed use by multiple analysts?

CodeBeamer is targeted at larger enterprises - typically in heavily regulated industries. The software supports a large number of concurrent enterprise users - so long as sufficient memory is allocated to the underlying infrastructure.

Is requirements modeling supported (e.g. use cases, state machines, or graphical representations)?

Use cases and epics can be easily linked with requirements. Further, application-native diagramming features enable the association of visuals / graphics with the requirements. Attachments, images, and tables further extend associated data formatting options.

Can version control and con figuration management practices be used with the requirements?

There is a section for SCM commits within the requirements detail page. Additionally, a history tab shows the automatic handling of versions and history.

Are there any features for consistency or completeness checking?

CodeBeamer has strong traceability, but dedicated requirements consistency/completeness checking tools are not featured in the application. Requirements portability, through compatibility with the Requirements Interchange Format (ReqIF), and the REST API offer opportunities to couple CodeBeamer with more sophisticated requirements analysis tools.


Figure 6: CodeBeamer Diagramming


JIRA uses tasks as the base unit for requirements and other business items. Example task types include bugs, tasks, subtasks, issues, epics, and user stories. However, task types, workflows, and statuses are highly customizable. A number of interfaces can be used for viewing tasks, but the most common view is perhaps a list near the left side of the interface, with the details of the selected task near the right side of the interface. By viewing the task list and task detail view, we can connect the JIRA approach back to the initial requirements management criteria.


Figure 7: JIRA Tasks

How does the tool capture requirements?

Tasks are used to capture requirements. These tasks can be con figured to fit a desired format, but the requirements are not portable using the Requirements Interchange Format (ReqIF).

If / how requirements can be linked to other requirements or documents (e.g. test cases)?

Tasks can be linked to one another through a variety of means, including “is blocked by”, “relates to”, task-subtask relationships, cloning, duplicating, and linking.

Does the tool support distributed use by multiple analysts?

Yes, both the cloud and on-premises offerings are meant to be used concurrently by analysts.

Is requirements modeling supported (e.g. use cases, state machines, or graphical representations)?

Some of the task formats and relationships can be used to generate requirement hierarchies and other structures. However, graphical modeling of requirements is not directly supported. Graphs and diagrams can be attached to tasks, but only more primitive data formats are handled with additional intelligence (e.g. tables and source code).

Can version control and confi guration management practices be used with the requirements?

The “History” portion of the task detail view provides insight on the changes to the task as a whole over time, while the “Activity” portion of the view provides details on even the smallest changes. These forms of history / tracking do not provide version numbers, and other artifacts of more formal versioning, as was seen with CodeBeamer. Further, the concept of “commits” is implemented for task metadata.

Are there any features for consistency or completeness checking?

There are no features for consistency or completeness checking. Custom queries, task metadata structures, and custom workflows may provide the foundation for some level of requirements organization, but certainly there is no clean, easy way to check for consistency / completeness.


Figure 8: JIRA Activity Log


[1] https://intland.com/application-lifecycle-management/

[2] https://www.atlassian.com/software/jira

[3] https://github.com/cptactionhank/docker-atlassian-jira

[4] https://hub.docker.com/r/cptactionhank/atlassian-jira

[5] https://hub.docker.com/r/intland/codebeamer