|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.
In 12.10 we released the MVC for Requirements Management. This currently allows users to perform the basic functions of creating requirements, viewing requirements, and archiving requirements.
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. An extensive round of user research was performed which resulted some great feedback about our initial offerings.
With this in mind, we are planning to implement the following iterations as we move the Requirements Management category towards viable maturity:
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 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||12|
|Requirements at the Group Level||9|
|Requirements Management: Approve and Baseline||4|
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.