The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
|Content Last Reviewed||
Requirements Management enables documenting, tracing, and control of changes to agreed-upon requirements in a system. Our strategy is to make it simple and intuitive to create and trace your requirements throughout the entire Software DevOps lifecycle.
We believe we can reduce the friction associated with managing requirements by tying it directly into the tools that a team uses to plan, create, integrate, and deploy their products. This can also provide real-time traceability and remove the need to track requirements across many disparate tools.
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. For less restrictive environments, Requirements Management can take the form of jobs to be done (JTBD) statements, which are satisfied through iterative improvements or additional features.
Requirements management tools are often prescriptive in their process, requiring users to modify their workflows to include traceability. Our goal is to allow for such rigid process where required, but remove these barriers for organizations looking to achieve the process improvements offered by working with requirements in a less formal manner.
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.
Further research has shown that many other regulated industries have similar process requirements. Medical, financial, and automative industries are held to similar standards as their aerospace counterparts.
Traceability - The ability to link requirements to other requirements (both higher level and lower level), design, source code, or verification tests.
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.
We recognize that we cannot immediately replace complex system level requirements management tools given their industry adoption and their extensive analysis capabilities which are well suited to managing very large system / subsystem requirement decomposition. We are therefore focusing on the largest pain point for our users based on extensive user research - tracing software implementation and verification to requirements in an automated manner.
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.
We currently have the ability to import requirements, export requirements and satisfy requirements through testing within our CI/CD Pipelines. Our final piece to making Requirements Management fully functional for our users is allowing requirements to trace to test cases (and in the future, other objects).
Therefore, we are focusing on usability and traceability via the following issues / epics:
The below image illustrates an initial node diagram of the requirements definition.
Once we have made requirements management a great option for single software teams, we plan to continue iterating as follows.
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. While these tools may be necessary for complex system level requirement work, we believe that managing requirements within GitLab can offer a much better user experience for individual teams who are not trying to integrate numerous complex systems.
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.
The next step is building out the requirements management structure to achieve viable maturity.
|Issue / Epic||👍|
|Multi-level epic and issue relationships tree-view as requirements management||16|
|Requirements at the Group Level||11|
|Requirements Management: Approve and Baseline||7|
The quality department experimented with requirements management. After evaluation, the quality department decided not to adopt requirements management at this time.