MVC: Allow users to create requirements

Problem to solve

Users in regulated industries often require a way to manage requirements. Additionally, users in non-regulated industries often desire a way to assess completeness / correctness through testing - which would lend itself to documenting requirements.

User Stories:

As a product manager in a regulated industry, I need a way of importing customer specifications and ensuring that design, code and testing provides the necessary coverage through traceability.

As a security analyst, I would like a way to define specific security requirements which apply to a product and to be able to quickly see what tests are in place in order to show compliance.

Intended users

Further details

This has already been a requested feature by numerous prospects / customers. Copying from &707 here for visibility.

Background

Ideally, we should begin by defining what makes up a requirement. To begin, it makes sense to think of a requirement as an artifact which describes the specific behavior of the product.

In industries where requirements are flowed to a development team, these teams generally will follow the steps outlined here:

  • Capture and control the customer (high level) requirements. These are generally somewhat generic and not implementation specific, but offer constraints related to how the product will interact with other existing products, or the outside system. (Product Managers / Technical Architects)
  • Decompose the high level requirements into lower level requirements (behaviors). These lower level requirements are linked to the higher level requirements which they satisfy. In many instances, these lower level requirements are made up of the product design. (Technical Architects / Engineers / Designers)
  • Implement the lower level requirements. This often causes iteration on both the implementation and the lower level requirements. (Engineers / Designers)
  • Where necessary, develop testing to verify either the high level requirements, or the lower level requirements. These tests (and associated results) ideally link to the requirements being tested. (Test Engineers)
  • Where necessary, verification results are gathered into a report showing necessary coverage of requirements or compliance. (Quality Engineers / Compliance Engineers)

Because requirements would be a development artifact, they could be considered similar to source code or test procedures. In the future, issues should be able to be written to create and modify requirements through the familiar issues / merge request process.

Proposal

To implement the MVC for Requirements Management, our proposal is to implement an interface that would allow users to perform the following actions:

  1. Create a new requirement - this new requirement would be automatically assigned a unique, non-reusable ID.
  2. View a list of existing requirements - view through the user interface a list of existing requirements.
  3. Edit an existing requirement - edit the text of an existing requirement. The user cannot modify the ID.
  4. Archive an existing requirement - mark an existing requirement as archived so it doesn't show up in a list of requirements.

Requirements will be stored within the database. They will be at the project level for the MVC, but plans are to also allow requirements to be stored at the group level.

In addition to the above interface, we plan to be able to link tests run within the CI/CD pipeline to requirements. The plan is to utilize the output from the pipelines and search for specific pass / fail strings based on the requirement ID. For example, if a requirement were ID number 1234, the output string of 1234 - PASS would indicate that requirement 1234 was covered and passed.

Permissions and Security

Documentation

Documentation would be needed to describe the requirements management feature. Key considerations would include, for the MVC, the following:

  • What is a requirement
  • Adding requirements
  • Archiving requirements
  • Linking requirements to other requirements

Testing

What does success look like, and how can we measure that?

This feature would be successful if we could show a percentage of applicable customers storing their requirements within GitLab instead of an outside tool.

What is the type of buyer?

This feature is for an organization that is looking to manage behaviors in a formal way that can then be used as a basis for design, implementation, testing and potentially certification.

Based on our existing model, this feature would best fit in Ultimate.

Problem Validation

Reach

Currently, the lack of requirements management precludes GitLab from being adopted within some regulated industries. This impacts current customers desiring to broaden GitLab adoption within their organizations as well as potential new customers. A sampling of customers requesting this feature can be seen above.

Therefore, I would put the reach at 3.0 - significant reach.

Impact

Given that this feature provides additional adoption opportunities and aligns with our goals, I would place the impact a 2.0 - high impact.

Confidence

We are confident that within industries where requirement management is a necessity, this feature would be a key selling point. I would place this at 100% - High confidence.

Effort

It is estimated that this problem will require the following:

  • Product Manager - 1 month
  • Designer - 0.5 months
  • Engineering - 1 month

Total effort for MVC is estimated at around 2.5 months.

Total RICE Score

RICE = (3 x 2 x 100%) / 2.5 = 2.4

Edited by Justin Farris