1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
|
---
type: reference, howto
stage: Plan
group: Certify
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
---
# Requirements Management **(ULTIMATE)**
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2703) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.10.
With requirements, you can set criteria to check your products against. They can be based on users,
stakeholders, system, software, or anything else you find important to capture.
A requirement is an artifact in GitLab which describes the specific behavior of your product.
Requirements are long-lived and don't disappear unless manually cleared.
If an industry standard *requires* that your application has a certain feature or behavior, you can
[create a requirement](#create-a-requirement) to reflect this.
When a feature is no longer necessary, you can [archive the related requirement](#archive-a-requirement).
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
For an overview, see [GitLab 12.10 Introduces Requirements Management](https://www.youtube.com/watch?v=uSS7oUNSEoU).
## Create a requirement
A paginated list of requirements is available in each project, and there you
can create a new requirement.
To create a requirement:
1. From your project page, go to **{requirements}** **Requirements**.
1. Click **New requirement**.
1. Enter a descriptive title and click **Create requirement**.
You will see the newly created requirement on the top of the list, as the requirements
list is sorted by creation date in descending order.
## Edit a requirement
You can edit a requirement (if you have the necessary privileges) from the requirements
list page.
To edit a requirement:
1. From the requirements list, click **Edit** (**{pencil}**).
1. Update the title in text input field.
1. Click **Save changes**.
## Archive a requirement
You can archive an open requirement (if you have the necessary privileges) while
you're in the **Open** tab.
From the requirements list page, click **Archive** (**{archive}**).
As soon as a requirement is archived, it no longer appears in the **Open** tab.
## Reopen a requirement
You can view the list of archived requirements in the **Archived** tab.
To reopen an archived requirement, click **Reopen**.
As soon as a requirement is reopened, it no longer appears in the **Archived** tab.
## Search for a requirement from the requirements list page
> - Introduced in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.1.
You can search for a requirement from the list of requirements using filtered search bar (similar to
that of Issues and Merge Requests) based on following parameters:
- Title
- Author username
To search, go to the list of requirements and click the field **Search or filter results**.
It will display a dropdown menu, from which you can add an author. You can also enter plain
text to search by epic title or description. When done, press <kbd>Enter</kbd> on your
keyboard to filter the list.
You can also sort requirements list by:
- Created date
- Last updated
## Allow requirements to be satisfied from a CI job
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2859) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 13.1.
GitLab supports [requirements test
reports](../../../ci/pipelines/job_artifacts.md#artifactsreportsrequirements-ultimate) now.
You can add a job to your CI pipeline that, when triggered, marks all existing
requirements as Satisfied.
### Add the manual job to CI
To configure your CI to mark requirements as Satisfied when the manual job is
triggered, add the code below to your `.gitlab-ci.yml` file.
```yaml
requirements_confirmation:
when: manual
allow_failure: false
script:
- mkdir tmp
- echo "{\"*\":\"passed\"}" > tmp/requirements.json
artifacts:
reports:
requirements: tmp/requirements.json
```
This definition adds a manually-triggered (`when: manual`) job to the CI
pipeline. It's blocking (`allow_failure: false`), but it's up to you what
conditions you use for triggering the CI job. Also, you can use any existing CI job
to mark all requirements as satisfied, as long as the `requirements.json`
artifact is generated and uploaded by the CI job.
When you manually trigger this job, the `requirements.json` file containing
`{"*":"passed"}` is uploaded as an artifact to the server. On the server side,
the requirement report is checked for the "all passed" record
(`{"*":"passed"}`), and on success, it marks all existing open requirements as
Satisfied.
### Add the manual job to CI conditionally
To configure your CI to include the manual job only when there are some open
requirements, add a rule which checks `CI_HAS_OPEN_REQUIREMENTS` CI variable.
```yaml
requirements_confirmation:
rules:
- if: "$CI_HAS_OPEN_REQUIREMENTS" == "true"
when: manual
- when: never
allow_failure: false
script:
- mkdir tmp
- echo "{\"*\":\"passed\"}" > tmp/requirements.json
artifacts:
reports:
requirements: tmp/requirements.json
```
|
