## 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 * [Parker (Product Manager)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Presley (Product Designer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#presley-product-designer) * [Devon (DevOps Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#devon-devops-engineer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### Further details This has already been a requested feature by numerous prospects / customers. Copying from &707 here for visibility. - https://gitlab.my.salesforce.com/0064M00000VtO83?srPos=6&srKp=006 - https://gitlab.my.salesforce.com/0064M00000VtO9H?srPos=7&srKp=006 - https://gitlab.my.salesforce.com/0064M00000VtO7A?srPos=0&srKp=006 - https://gitlab.my.salesforce.com/0066100000S5wEN - https://gitlab.my.salesforce.com/0064M00000VsmWn - https://gitlab.my.salesforce.com/0064M00000W11Jm ## Background <!-- How are we going to solve the problem? Try to include the user journey! https://about.gitlab.com/handbook/journeys/#user-journey --> 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. 1. View a list of existing requirements - view through the user interface a list of existing requirements. 1. Edit an existing requirement - edit the text of an existing requirement. The user cannot modify the ID. 1. 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 <!-- What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?--> ## Documentation <!-- See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements If this feature requires changing permissions, this document https://docs.gitlab.com/ee/user/permissions.html must be updated accordingly. --> 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 risks does this change pose? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? See the test engineering process for further help: https://about.gitlab.com/handbook/engineering/quality/test-engineering/ --> ## What does success look like, and how can we measure that? <!-- Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this. --> 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? <!-- Which leads to: in which enterprise tier should this feature go? See https://about.gitlab.com/handbook/product/pricing/#four-tiers --> 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** <!-- Please describe who suffers from this problem. Consider referring to our personas, which are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/ --> <!-- Please also quantify the problem's reach using the following values, considering an aggregate across GitLab.com and self-managed: 10.0 = Impacts the vast majority (~80% or greater) of our users, prospects, or customers. 6.0 = Impacts a large percentage (~50% to ~80%) of the above. 3.0 = Significant reach (~25% to ~50%). 1.5 = Small reach (~5% to ~25%). 0.5 = Minimal reach (Less than ~5%). --> 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** <!-- How do we positively impact the users above and GitLab's business by solving this problem? Please describe briefly, and provide a numerical assessment: 3.0 = Massive impact 2.0 = High impact 1.0 = Medium impact 0.5 = Low impact 0.25 = Minimal 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** <!-- How do we know this is a problem? Please provide and link to any supporting information (e.g. data, customer verbatims) and use this basis to provide a numerical assessment on our confidence level in this problem's severity: 100% = High confidence 80% = Medium confidence 50% = Low 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** <!-- How much effort do we think it will be to solve this problem? Please include all counterparts (Product, UX, Engineering, etc) in your assessment and quantify the number of person-months needed to dedicate to the effort. For example, if the solution will take a product manager, designer, and engineer two weeks of effort - you may quantify this as 1.5 (based on 0.5 months x 3 people). --> 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 ## Design  Additional designs available here: https://nickbrandt531532.invisionapp.com/public/share/VX10XHBG2F#screens/476363206