Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Requirements Management

Requirements Management

Stage Plan
Maturity Planned
Content Last Reviewed 2020-03-27

Introduction and how you can help

Welcome to the category strategy for Requirements Management, part of the Plan stage's Certify group. To provide feedback or ask questions, please reach out to the group's Product Manager, Mark Wood (E-mail).

We believe in a world where everyone can contribute. We value your contributions, so here are some ways to join in!

issues and epics!


The strategy for requirements management within GitLab is to reduce the friction associated with requirements management by providing an intuitive way of creating requirements and allowing these requirements, as well as other existing artifacts within the DevOps platform, to be linked together to enable traceability consistent with the needs of our diverse users.

What is Requirements Management?

It is often necessary to specify behaviors for a system or application. Requirements Management is a process by which these behaviors would be captured so that there is a clearly defined scope of work. A good general overview is provided in an article from PMI.

Requirements management tools are often prescriptive in their process, requiring users to modify their workflows to include traceability.

Aerospace Use Case

Regulated industries often have specific standards which define their development life-cycle. For example, commercial software-based aerospace systems must adhere to RTCA DO-178C, Software Considerations in Airborne Systems and Equipment Certification. While this document covers all phases of the software development life cycle, the concept of traceability (defined as a documented connection) is utilized throughout. This connection must exist between the certification artifacts.

The most common trace paths needed are as follows:

It is important to recognize that all artifacts must be under revision control.

During audits, teams are asked to demonstrate traceability from the customer specification through all downstream, version-controlled artifacts. Teams are often asked to analyze a change in a system level requirement, assessing exactly which downstream artifacts will need to be modified based on that change.

Other Regulated Industries

Further research is underway to determine if other regulated industries are similar in their use case for Requirements Management.

Key Terms / Concepts

Requirements Decomposition - It is up to the developers and architects to decompose (break down) high level requirements into many smaller low level requirements. All of these decomposed requirements would generally trace up to the high level requirement, thus forming a one-to-many (HLR to LLR) relationship.

Derived Requirements - Because regulated industries often require that all functionality within the software trace to a requirement, it is often necessary to create requirements at the LLR / Design level. These requirements, that were not decomposed from a higher level requirement, are called Derived Requirements.

Traceability Matrix - A common artifact that is often required is a traceability matrix. This is a released document which shows all traceability links in the system / sub-system.

What's next & why

We are currently in the final stages of implementing an MVC for Requirements Management within GitLab. We recognize that GitLab is in a unique position to deliver an integrated Requirements Management solution since linking to all aspects (version controlled files, test procedures, etc…) could be accomplished without the need for external tools. This would allow our solution to effectively link to all necessary artifacts within a single product offering.

The first step of this category is building out the initial requirements structure, in particular, at the group level. This would allow a basic tree-structure of requirements. This would allow us to achieve minimum maturity for this category.

Future iterations include integration/linking with artifacts within GitLab such as with test cases and test results, to achieve traceability. These iterations will be working toward achieving viable maturity for this category.

Also related to this category is Release Governance from the Release, in particular the concepts related to evidence & artifact collection.

The below image illustrates an initial node diagram of the requirements definition.

Requirements Node Diagram

Long term goals

Competitive landscape

Top competitors in this area are traditional tools that do requirements management used by business analysts, managers, and similar personas. Jama Connect and IBM Rational DOORS are two popular tools. Both of these tools offer limited integration with version control systems, making linking to necessary artifacts cumbersome. How GitLab can set ourselves apart is by reducing the need for outside tools, thus eliminating much of the friction associated with tracing artifacts to requirements.

Analyst landscape

We have yet to engage more closely with analysts in this area. As this product category is prioritized for improvements as our Plan product and engineering headcount grows, we expect to engage more with analysts.

Top Customer Success/Sales issue(s)

The first step is building out the requirements management structure to achieve minimum maturity.

Top user issue(s) & Epics

Issue / Epic 👍
Multi-level epic and issue relationships tree-view as requirements management 8
Requirements Management: Approve and Baseline 3

Top internal customer issue(s)

Currently, the quality department is experimenting with requirements management. Further collaboration is necessary to understand their needs and whether or not our implementation is useful for their efforts.

Top Vision Item(s)

As we near completion of the Requirements Management MVC, the two more important items are:

These items will complete our initial vision of releasing Requirements Management.

The next step in the vision is to begin working on Requirements Traceability