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.
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.
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 is underway to determine if other regulated industries are similar in their use case for Requirements Management.
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 are currently in the early stages of implementing 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.
The below image illustrates an initial node diagram of the requirements definition.
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.
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 first step is building out the requirements management structure to achieve minimum maturity.
There are currently no customer issues since we are still in the planning phase for requirement management.
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.