MVC of [requirements management category](https://about.gitlab.com/direction/plan/requirements_management/) At the group level, have a new abstraction object called a `requirement`. So there is a list of requirements that you can create. <img src="/uploads/d54385a07464e060965f1fa7323d4002/Screen_Shot_2019-01-10_at_09.46.43.png" height="300px" /> A requirement has a unique identifier and requirement text. It has two states. It is either active or archived. It is unlike an issue or merge request because it is meant to be long-lived. That is, requirements persist and serve to document existing "required" functionality or behavior of a given application. The moment that behavior is no longer necessary, the requirement object should be archived. Requirements can be linked together. In particular, you can have a tree-like structure. So for example, `R1` is satisfied by `R1.1` and `R1.2`. And then `R1.2` is further satisfied by `R1.2.1` and `R1.2.2` and `R1.2.3.` ### Future improvements outside of MVC scope A requirement can be linked to multiple test cases (https://gitlab.com/groups/gitlab-org/-/epics/617). And conversely, a test case can be linked to multiple requirements. In these cases, this can be used to indicate that one more test cases is used to validate that a requirement is (still) being met. That is, a test case can be used to verify that a requirement is still being maintained for a given requirement. A requirement can be linked to multiple issues. That is, an issue can be shown to be the actual change that implemented the requirement in the first case. A requirement can be linked to multiple merge requests, that actually satisfied the requirement with the implementation. Traceability visualizations like traceability graphs or traceability matrices connecting requirements with issues and test cases. Archiving a requirement would need to take into account the links that trace in to the requirement and out from the requirement. ### Feature Rollout Tasks Given that Requirements at a Group Level will be a major feature rollout, the following tasks should be considered (from [Handbook](https://about.gitlab.com/handbook/product/#major-feature-rollout)): - [ ] Feature is drafted in an issue - In progress (gitlab#32733) - [ ] Feature is planned in an upcoming release - [ ] A feature blog post is made - [ ] Feature is implemented and documentation is written - [ ] Feature should appear on the website - [ ] Feature is launched with the release - [ ] Feature is highlighted in a blog post