►
From YouTube: GitLab Requirements Management Demo
Description
When working on a project, there are always expectations and assumptions that come from customers and other stakeholders.
In this demo, we'll walk through how to create and manage those requirements as well as how to automatically verify and satisfy those requirements using GitLab CI.
A
Hey
everyone
welcome
to
this
session
on
requirements,
management
with
gitlab.
My
name
is
Jeremy
Wagner
and
I'm,
a
Senior
Solutions
architect
here
at
gitlab
and
I'm
part
of
a
team
that
specializes
in
helping
customers
by
understanding
their
business
needs
and
then
turning
those
into
Technical
Solutions
inside
of
gitlab.
A
Now,
when
you're
working
on
a
project,
there's
always
going
to
be
certain
requirements
that
come
from
customers
or
other
stakeholders,
some
of
these
requirements
might
be
industry,
regulations,
best
practices
or
even
product
features.
The
goal
of
requirements
management
is
going
to
be
to
document
these
requirements
and
then
ensure
that
your
product
does
exactly
what
you
think
it
does
and
exactly
what
your
customers
expected
to
in
this
demo
I'm
going
to
show
you
how
to
create
a
requirement
manage
that
requirement,
as
well
as
automatically
verify
and
satisfy
that
using
gitlab
CI.
A
So,
let's
Dive
In
I've
got
a
project
here.
That's
pre-existing,
on
the
left
hand,
menu
you're
going
to
see
the
issues
link
if
I
hover
over
that
and
select
requirements.
This
is
going
to
open
up
a
list
of
open
requirements
for
your
project
to
create
a
new
requirement.
I
can
go
ahead
and
click
new
requirement
on
the
top
right
I'm
going
to
go
ahead
and
give
it
a
title,
and
a
description
now
you'll
see
that
this
supports
markdown.
A
So
if
you're
using
issues
and
merge
requests,
it's
going
to
be
a
very
similar
Editor
to
what
you're
already
used
to
just
go
ahead
and
create
this
requirement
and
you're
going
to
see
it
populate
on
this
list
of
other
open
requirements.
You'll
see
that
it
populates
with
a
unique
identifier,
a
title:
A
Creator,
that's
timestamp
and
an
updated
at
timestamp.
A
One
thing:
you'll
notice
with
this
one:
is
it's
not
satisfied
just
like
this
one
below
it,
but
you'll
see
others
that
are
satisfied
if
I
go
ahead
and
click
this
edit
button,
it's
going
to
give
me
the
option
to
Market
a
satisfied,
so
I
can
manually
say
hey.
This
is
satisfied,
so
let's
go
ahead
and
Mark
this
one
as
satisfied
and
you'll
see
how
that
works.
A
So
now,
we've
manually
marked
number
13s
satisfied,
but
what
happens
if
we
want
to
verify
and
satisfy
this
automatically
using
gitlab
CI?
Let's
go
ahead
and
show
you
that.
So,
let's
take
a
note,
this
is
ID
number
14.,
I'm
gonna
go
ahead
and
open
up
my
gitlab
CI
file,
I'm
gonna
open
this
in
the
web
IDE
and
talk
through
it
here
for
a
second.
A
So
this
is
going
to
be
a
very
simple
CI
file
with
one
stage
verify
requirements
and
inside
that
stage,
I'm
going
to
have
one
job
and
essentially
what
this
job
is
going
to
do.
Is
it's
going
to
create
a
requirements,
Json
file
which
is
going
to
be
the
artifact
that
we
can
ingest
inside
of
gitlab
and
it's
going
to
Mark
a
requirement
as
passed.
So
you
can
see
here
that
I
have
12
hard-coded.
A
But
that's
not
super
useful
when
you're
trying
to
do
this
dynamically
things
like
that,
so
one
way
to
use
this
would
be
to
run
automated
tests
and
then
have
a
test
case
aligned
to
a
requirement
that
way.
You
can
say:
hey.
We've
satisfied
this
user
requirement
by
running
this
test.
It
passed.
So
let's
mark
this
as
satisfied.
That's
one
example:
you
might
see.
A
So
some
of
those
are
some
of
those
ways
that
you
can
can
automate
and
and
ways
you
might
want
to
use
that
to
automatically
satisfy
this,
so
this
pipeline
should
be
wrapping
up
here.
Any
seconds
I'm
going
to
go
ahead
and
click
into
it.
Yep
just
finished
perfect.
So
now,
let's
go
back
to
our
requirements.
A
And
now
we
can
see
that
required.
Number
14
is
satisfied,
so
we
have
checked
that
we
are
developing
internal
and
external
software
applications
securely
and
marked
that
as
satisfied.
Now,
if
we
want
to
export
this
list
and
share
it
with
a
customer
or
something
like
that,
we
can
easily
export
this
as
a
CSV
and
share
it.
However,
we
need
to
now
if
a
requirement
is
no
longer
active,
you
can
archive
it
by
selecting
this
archive
button
here
and
it's
going
to
move
it
to
this
archive
tab
at
gitlab.
A
We
think
requirements
are
durable
for
the
project,
meaning
we
want
to
track
them
with
the
history
of
the
project.
So
you
always
know
what
the
requirements
were
at
any
State,
so
these
are
never
going
to
go
away.
There's
going
to
be
archives,
so
you
can
come
back
and
and
see
what
why
things
were
done
a
certain
way.
Now,
if
it
becomes
active
again,
you
can
easily
just
click,
reopen
that's
going
to
pop
it
over
to
the
open
tab
here
and
we're
back
and
have
an
active
requirement
again.