## Introduction This epic is designed to track the progress of tracing requirements to tests within GitLab. Ideally, Requirements at the Project Level should trace down to tests & test results, and trace back up to [Requirements at the Group Level](https://gitlab.com/groups/gitlab-org/-/epics/707). ## Personas With this goal in mind, we're attempting to solve the following user stories: ### Software Engineer in Test > As a software engineer in test, I need to be able to refer to requirements while writing the tests. > As a software engineer in test from a regulated industry, I need to be able to provide evidence that I am covering the requirements with the tests I'm writing through direct traceability. ### Release Manager > As a release manager, I need to be able to easily understand what level of testing has been completed against requirements so I can make an informed release decisions. ### Systems Engineer (regulated industries) > As a systems engineer, I need to able to easily show test coverage for requirements in order to meet regulatory standards. ### Safety Engineer (regulated industries) > As a safety engineer, I need to be able to show all requirements have been fully tested prior to signing off on a release. ## Proposed Solution The current proposed solution is as follows: 1. A requirement can be set as 'blocking'; 1. If a project has *any* blocking requirements a 'Requirements' job is automatically added to the pipeline; 1. Every MR requires a manual step to check each blocking requirement and OK this job to unblock the pipeline, and 1. Every time a user OKs the job a record is made against all blocking requirements as to who ran the manual test. This way even when the jobs are cleaned up we still have that record. For the initial iteration, we will assume that all requirements are 'blocking', with the opportunity to iterate further on this approach later.