►
From YouTube: Requirements Management Initial Discussion
Description
Introduction and Q&A between Product Management and Engineering discussing ideas and strategy.
Requirements Manage Strategy Page - https://about.gitlab.com/direction/plan/requirements_management/
A
Hey
it's
working,
okay,
we're
not
recorded
so
yeah.
This
is
something
that
you
know:
I've
done
for
a
long
time,
I'm
happy
to
answer
questions
any
time.
If
people
have
problems,
questions
or
respond
or
overview
hey,
it
went
slack.
I've
had
this
sort
of
a
meeting
so
I
put
together
this
agenda.
I
didn't
really
put
a
whole
lot
into
it.
Other
than
I
have
gone
ahead
and
updated
the
direction
page
for
the
requirements
management
category.
A
Hopefully
that
is
helpful
to
people.
I
am
working
also
on
a
slide
deck
that
I've
sort
of
started.
I,
admit
it's
in
its
infancy.
I'd
be
happy
to
share
that
and
kind
of
walk
through
things
at
our
top
level.
If
people
want
me
to
or
if
you
want
me
to
jump
into
questions,
that's
great
whatever
makes
the
most
sense
for
you
guys
for
everyone.
I'm.
Sorry.
B
C
A
A
Good
very
good
question.
Thank
you.
The
the
biggest
challenge
of
this
is
requirements
at
their
core,
our
set
of
behaviors
and
in
regulated
industries
and
even
non
regulated
industries.
People
are
more
and
more
asking
for
requirement
management
because
they
want
to
be
able
to
define
behaviors
for
their
product
and
then
trace
their
implementation
and
their
verification
or
testing
to
those
that
are
behaviors
so
currently,
and
this
is
not
set
in
stone.
The
concept
would
be
to
have
a
whole
new
sort
of
primitive
called
the
requirement
it
would
either
be
open
or
archived.
A
It
would
have
an
identification
of
some
sort
of
a
unique
number
or
text
doesn't
really
matter.
It
just
has
to
be
unique,
so
people
can
link
to
it
and
would
have
basically
object
text
or
requirement
text
how
this
is
implemented.
I
am
very
open.
I,
don't
want
to
drive
in
colon
tation
details
at
the
end.
These
need
to
be
able
to
link
to
one
another
and
they
need
to
be
able
to
link
to
source
code
test
results,
tests
and
all
that
sort
of
thing.
A
So
whatever
makes
the
most
sense
from
an
implementation
perspective,
I'm
fine
with
as
long
as
there's
an
interface
to
it,
that's
usable
as
we
progressed
I'm
guessing
one
of
the
things
that
most
companies
or
most
products
like
this
are
sorely
lacking,
and
people
really
want
is
a
visualization
of
this
tree
of
requirements.
That
would
be
something
that
would
be
awesome
if
we
could
provide,
because
nobody
does
it
well
right
now.
A
The
other
thing
nobody
does
well
right
now
is
integrate
requirement
management
into
versioning
systems,
the
biggest
players,
the
industry
around
our
IBM,
rational
doors
and
Atlassian,
JIRA
or
Java
implementation.
Jama
is
slightly
better
than
doors.
Doors
is
awful
for
integration.
It
doesn't
agree
with
anybody,
so
you
basically
have
to
create
these
W
modules
and
doors
all
of
your
test
case
names
and
for
all
of
your
file
names
and
then
link
to
those
and
those
represent,
what's
managed
in
your
version
control
system.
A
So
if
you
rename
sling
over
your
version,
control
system
you'd
have
to
then
go
back
and
rename
it
indoors.
It's
a
very
manual
process
and
everybody
hates
it.
We're
very
uniquely
positioned
that
everything
is
self-contained
and
get
led,
which
is
awesome,
so
that's
sort
of
where
we
want
to
take
it
long
term
short
term.
A
Some
of
this
plays
heavily
into
the
idea
of
artifact
retention
and
artifact
curation
I
know
there's
a
another
team
working
that
as
well,
where,
for
instance,
when
you
run
your
CI
CD
testing
right
now,
it
says
pass
or
fail
and
that
saved,
but
it
doesn't
save
off
the
results
implicitly
into
a
file
in
the
version
control
system
and
that's
something
that
they're
working
toward
and
those
were
the
results.
We
would
end
up
tracing
their
deployments
to
because
those
are
the
test
files
or
the
result,
files
that
prove
the
implement
a
requirement
correctly.
D
That
makes
very
so
how
do
we
like
how
the
software
will
be
in
this
case,
it's
clear:
how
do
get
ler
we'll
know
the
requirements
are
met.
So
basically,
is
there
a
way
to
that
these
requirements
depends
on
these
packs.
These
are
heads
or-
or
let's
say
my
software
doesn't
have
any
specs
right
so,
but
in
this
case,
so
how
can
the
software
know
that
the
requirements
are
met?
That's.
A
A
very
good
question
in
general:
it's
all
going
to
be
a
traceability
in
traceability
is
effectively
this
linking
we're
talking
about.
So
if
you
get
a
customer
spec
a
high
level
and
you
decompose
that
down
into
a
bunch
of
requirements,
and
then
you
trace
those
two
issues
where
you
implement
the
code
and
you
trace
those
two
code
file,
he
traced
those
two
test
procedures
and
test
results
in
an
ideal
world.
Those
passing
test
results
would
be
linked
from
that
requirement
and
we
can
roll
that
up
and
say:
okay,
this
straights
to
five
tests.
A
A
A
So
you
have
an
if
statement
to
verify
that
the
true
and
the
false
path
or
hit
as
you
nest
these
they
get
incredibly
complex
and
horrible,
and
you
have
to
verify
that
every
path
is
taken
and
you
have
to
verify
that
every
trial
and
code
traces
do
some
requirements
somewhere,
which
traces
to
some
other
requirement
which
satisfies
the
customer.
That's
the
extreme,
we're
not
looking
to
mark
it
to
the
extreme
anytime
in
your
future.
We're
looking
more
for
companies
who,
let's
say
they
wanted
to
do
an
app
and
they
have
the
gdpr
compliance.
A
They
want
to
verify
that
their
GTR
compliant.
They
can
write
tests
currently
to
do
that
and
they
can
say
to
their
customers.
Yeah.
We
meet
the
gdpr,
it's
a
much
more
powerful
statement.
If
they
say
hey,
we
define
some
requirements
around
it.
We
have
touched
the
trace
to
those
those
tests
are
passing
on
this
build,
so
we
still
have
done
GPR
compliance
to
the
best
of
our
understanding.
If
they
get
it
wrong
and
somebody
comes
ask
them
to
go
hey,
look.
A
We
put
tests
together,
yeah
we're
wrong,
we'll
fix
it,
what
they
did
and
here's
what
we
update,
but
it's
a
much
more
powerful
statement
to
say
that
you
have
actually
thought
through
decompose
and
test
it
to
those,
and
it
shows
a
message
to
your
customer
that
you
really
do
care
and
you
really
have
a
plan
in
place
to
cover
this
stuff,
not
just
some
guys
somewhere
in
my
testing.
Department
says
we're
good
kind
of
thing:
excellent,
okay,
I
think.
The
next
question
is
our
requirement
is
supposed
to
be
group.
A
Scoped
again
that
was
done
to
create
a
more
minimum.
Viable
change
is
to
keep
them
within
a
group
in
the
ideal
world.
How
this
would
generally
work
at
a
large
scale
is
you'd,
have
different
groups
for
different
things,
so
your
customer,
spec
would
probably
be
a
zone.
Group
group
should
have
its
own
requirements.
A
The
software
team
would
have
their
own
group,
which
would
have
the
source
code
and
their
requirements
to
have
all
the
requirements,
and
you
trace
from
the
high
level
requirements
of
the
source
code
group
to
the
system
group
which
would
have
the
system
will
require
less.
So,
in
the
end,
we
will
need
to
look
across
groups
with
this
stuff.
It
was
somebody
had
mentioned.
It
was
much
simpler
to
keep
them
group
scoped
to
start
with
and
I'm
totally
fine
with
that
as
an
MVC.
A
C
Just
added
a
comment:
I
think
that
it
like
we
can't
run
into
this
with
epics
after
the
fact
where
it
would
have
made
more
sense
if
we
had
project
level
epics
that
behave
slightly
differently,
but
we're
on
the
project
level.
That
rolled
up
to
the
group
level
and
I.
Think
since
right
now
code
lives
in
a
project
on
a
repository
like
you,
you're
gonna
have
to
have
both,
and
it's
similar,
like
you're
gonna,
want
to
have
a
group
level
requirement.
That
then,
is
decomposed
into
a
smaller
requirement.
C
Maybe
at
the
project
level
where
the
implementation
is
going
to
happen
right
and
then,
where
the
implementation
happens
is
where
you
have
the
tests
that
satisfy
the
requirement
and
and
all
that's
going
to
live
on
a
project
or
it
will
span
multiple
projects
in
a
lot
of
organizations,
especially
those
of
like
a
services
or
in
the
architecture.
But
you
almost
need
the
both
levels
and
I
would
I
would
say
like
we
should
assume
to
plan
for
both
of
it.
If
that
makes
sense,.
B
A
A
Last
question
from
John
I'm,
not
sure
he's
here
or
not,
given
the
impracticality
of
having
licenses
for
competitor
software.
How
do
you
suggest
people
get
acquainted
with
this
stuff?
That's
a
very
good
question.
Oh
Dores
licenses
run
in
the
tens
of
thousands
and
I.
Think
JAMA
is
similar,
so
you're
right,
it's
very
impractical,
I,
don't
know
the
best
way
to
go
about
that.
I
have
used
both
I
am
very
happy
to
host
in
many
sessions
like
this
as
we
need
and
answer
questions.
A
A
Just
so
that
people
can
kind
of
get
a
feel
for
it
effectively
in
a
regulated
industry
such
as
aerospace,
the
tools,
actually,
the
tools
in
general
are
really
bad.
The
tools
thus
far
are
basically
doors
and
Java,
as
I
mentioned,
and
both
of
them
are
external
tools
that
people
are
trying
to
sort
of
duct
tape
into
a
requirements.
Management
system.
B
C
A
C
Sure
how
our
requirements
gonna
act,
going
to
interact
with
issues
attaching
them
to
issues
and
that
sort
of
thing
that
I
know
that
I
saw
comment,
something
where
all
we
should
have
discussions
on
requirement.
Listen
I
kind
of
understand
like
how
the
relationship
between
the
two
is
gonna
work,
moving
forward
in.
A
My
world
I
don't
see
requirements
and
issues
tracing
to
one
another.
I
think
issues
are
used
to
create
the
requirements.
You
are
at
an
issue
to
address
or
an
issue
to
add
implementation
requirements,
but
the
issue
is
an
implementation
construct
and
a
requirement
is
a
totally
different
construct.
A
requirement
is
more
a
durable
I.
C
A
To
me,
an
issue
is
what
you'd
create
to
create
requirements.
You
create
requirements
under
an
issue,
but
you
don't
really
trace
them
together.
Other
than
this
issue
is
used
to
create
these
requirements,
because
requirements
are
a
durable
construct
that
lasts
for
the
duration
of
a
project.
Basically,
issues
are
intended
to
make
changes
to
that
project.
A
You
write
an
issue
to
change
something
so
in
general,
how
this
has
done
an
industry
that
I've
worked
in
the
industries
I've
seen
is
you
would
write
an
issue
to
say
decompose
the
following
requirements
that
work
would
be
done
under
that
issue.
Those
requirements
would
be
updated,
be
composed
in
the
smaller
requirements.
You
then
write
an
issue
to
implement
those
requirements.
That's
when
the
implementation
would
take
place.
A
You
venerate
an
issue
to
verify
those
requirements
and
that's
when
you
develop
test
procedures,
test
cases
and
you
do
the
verification,
the
issues
kind
of
go
along
and
that's
how
you
modify
these
artifacts.
So
our
requirements
are
considered
artifacts,
your
software's,
your
code
is
an
artifact.
Your
tests
are
artifacts
or
results
or
artifacts
issues
modify
artifacts
in
general,
so
you'd
schedule
all
this
working
issues
and
epics
to
do
the
work,
but
the
artifacts
remain
throughout
the
course
of
the
project
development
cycle
right.
C
D
C
D
C
Yeah
and
the
other
thing
that
I
was
kind
of
thinking
about,
given
the
fact
that
you
know
these
are
longer
term
things.
It's
almost
like
some
form
of
version
control
like
it
would
make
sense
and
I,
don't
know
if
you
can
build
requirements
like
on
top
of
it
themselves,
which
would
make
sense.
It
seems
like
that.
A
Would
be
a
awesome
implementation,
because,
currently,
what
both
Jama
and
doors
do
is
once
you've
developed
all
your
requirements.
You
then
have
to
snap
a
baseline
manually
by
going
in
and
creating
a
baseline,
and
that
baseline
has
to
get
checked
into
your
version
control
system
to
formalize
it
as
an
artifact.
You
cannot
use
the
requirements
in
the
current
working
state
indoors
or
Jama
for
my
understanding
as
your
baseline,
because
there's
no
change
or
change
control
on
those
things.
A
So
building
change
controlling
from
the
get-go
just
like
you'd,
submit
a
merge
request
under
an
issue
to
add
to
the
requirements
would
be
huge,
so
we
can
do
two
quirements
in
a
text-based
file
structure.
That
would
be
awesome
because
then
we're
linking
files
files,
which
is
what
we're
gonna
end
up
doing
down
the
road,
we'll
really
Kreuk,
wireman
code
files,
requirements
to
test
results.
That's
all
linking
to
files
having
requirements
themselves,
be
a
tree
of
files
with
the
ID
being
the
file
name,
for
instance,
and
the
requirement
text
being
in
the
file
is
an
opportunity.
A
C
C
All
the
things
like
here's
the
end
state
right
so
that
way
we
can
work
backwards
and
identify
the
constraints
that
we
need
to
solve
for
to
get
there
and
make
the
right
technical
decisions
now,
because
I've
seen
like
a
lot
of
times
when
we
just
do
this
NBC
thing.
Without
that,
we
end
up
making
small
incremental
changes,
which
is
great.
But
then
we
sacrifice
long
term
like
architecture,
decisions
that
we
have
to
now
go
back
and
fix.
That's
you're.
A
Correct,
that's
like
one
of
my
biggest
risks
with
this
right
now
is:
if
we
take
this
and
we
do
an
MVC
and
then
we
find
out,
oh,
we
need
to
add
virtually
22
requirements
like
what
we
did
it
all
in
a
database
or
something
to
do
that.
Now.
We've
got
to
change
the
architecture.
I
don't
want
to
release
something,
get
people
excited
about
it,
get
them
using
it
and
then
basically
pull
the
rug
out
from
under
them
and
say:
oh
yeah,
and
by
the
way
we
have
to
restructure
all
the
thing
which
we
architected.
A
C
Be
did
like,
if
you
know
in
the
future,
it's
gonna
have
to
do
this
and
do
these
do
these
various
things.
Then
let's
go
ahead
and
say
that
and
now
not
that
we're
gonna
implement
it,
but
then
we
can
work
backwards
from
there
and
kind
of
make
sure
the
MVC.
You
know
the
smallest
thing
adheres
to
the
kind
of
long
term
goals.
I'll.
C
A
A
That's
it's
usually
done
by
hand,
and
the
links
have
to
be
reviewed
by
a
competent
engineer
in
order
to
claim
their
truly
review
test
requirements.
Basically,
so
I
guess
to
me,
there's
up
links
and
down
links
for
in
legs
down
links
depends
how
you
want
to
look
at
it.
There
will
be
test
cases
that
trace
up
to
a
requirement
at
the
implementation
level,
and
that's
generally
how
that
is
handled.
Does
that
make
sense
that
answer
the
question?
Nora
yeah.
C
I
know
one
of
the
reasons
why
I
brought
that
up
is,
it
seems
like
it
could
be
an
opportunity
here
to
kind
of
automate
things
a
little
bit
so
I,
don't
I,
don't
know
if
you're
familiar
with
like
the
gherkin
syntax
and
writing
BDD
tests.
But
it's
it's
more
or
less
like
you
write
a
requirement
and
the
testable
requirement
and
human
readable
language
that
makes
sense.
And
then
you
can
easily
associate
your
steps
to
that.
That
step
through.
C
Then
you
like
that's
how
you
can
link
to
two
things
together
and
it
seems,
like
you
know,
moving
forward
like
that
doing
something
like
that.
I,
don't
know
if
we
use
something
off
the
shelf,
there's
something
better
than
gherkin.
That
allows
us
to
do
that,
but
designing
the
requirements
text
from
the
start
to
also
say
like
this
is
how
we're
gonna
linked
it
to
and
our
goal
is
to
make
it
not
manual.
You
know
right.
A
And
that'll
work
fine
for
non
regulated
industries
for
regular
industry.
Unless
those
tools
are
qualified,
they
can't
be
used,
which
is
why
they
don't
use
any
of
that
stuff
because
tool
claw,
something
like
that
is
incredibly
expensive
next
to
impossible,
because
it's
like
there's
a
lot
of
undefined
Statesmen
was
not
designed
to
be
qualified
so
for
an
unregulated
industry.
Yeah
absolutely
I
think
that's
a
great
opportunity
for
a
lot
of
people
and
I
think
that's.
We
want
to
appeal
to
a
large
degree
as
well
so
I
think
it's
a
great
opportunity.
A
A
Could
to
a
ball
I
mean
there's.
No,
no,
there's
no
reason.
You
can't
do
a
tool.
Call
the
difficult
to
a
tool.
O'clock
comes
that
for
aerospace.
Right
now,
it's
do-178c
specifies
how
you
do
a
tool
call
for
automotive.
It's
a
completely
different
standard
for
system
level
requirements.
It's
the
third
standard,
so
you
end
up
calling
the
same
thing
like
six
times
just
to
meet
and
check
the
box
for
every
standard
which
we
found.
C
E
A
Would
be
excellent
to
offer
to
professional
services
where
they
get
contract
us
to
koala
part
of
our
tool
is
part
two
work
in
their
process
as
an
added
fee.
We
did
that
all
the
time
like
we
contacted
a
Tumulty
was
a
giant
compiler
vendor
and
said
hey.
We
need
a
qualified
compiler,
because
if
you
don't
have
a
qualified
client
in
that
test,
at
the
object
code
level,
which
is
next
to
impossible
and
we
work
with
them
to
create
a
call
for
their
compiler
and
we
paid
them
for
that.
We
do
that.
A
C
Sense,
the
other
question
which
I
haven't
written
yet
is
I
know
when
I
talked
to
one
of
the
aerospace
companies,
bigger
ones
that
uses
get
lab
right
now.
They
also
use
doors,
I,
think
there's
a
presentation
I
can
find
somewhere.
If
you
haven't
seen
it
yet
or
like
the
recorded
video.
But
what
they
do
is
they
do
all
the
requirements
in
get
lab
and
then
they
go
and
they
write
them
all
up
in
some
sort
of
visual
diagram
type
tool.
Maybe
it
was
doors,
but
it
kind
of
is
visual.
F
A
Yeah
absolutely
I
mean,
if
I
having
dealt
with
this
for
eighteen
years
in
a
horrible
state.
If
I
had
my
way,
I
would
love
to
kill
the
right-click
on
the
requirements,
say
visualize
requirement
or
show
me
the
ancestors
in
you
know
the
top
of
my.
They
had
a
view
a
tree.
We
could
click
through
and
see
this
stuff,
and
then
you
could
click
through
and
double
click
on
it.
It
opens
the
test
file
that
you
just
collect
on,
or
you
click
on
the
code
file.
It
opens
the
code
file.
A
C
You
heard
of
Cyprus,
it's
a
I
guess
end
end
testing
framework
for
JavaScript
I
have
I'll
put
this
in
here
idea,
sort
of,
like
add
videos
requirements.
So
what
this
does
is
when
a
it
when
test
for
NCI
it
records
a
video,
and
then
it
will
attach
that
video
to
like
the
the
test
run.
So
that
way
anybody
can
go
and
say
like
here's,
the
test.
C
Like
here's
the
feature,
we
wrote,
here's
a
test
that
passed
and
here's
the
video
that
you
can
watch
showing
the
actual
product
do
the
things
that
we're
testing
against
to
verify
that
it's
working
correctly
and
you
know
when
it
passes
or
when
it
fails
or
whatever,
which
that's
like
a
I,
noticed
a
lot
of
people
who
are
using
that
rave
about
that,
especially
as
the
engineer
table
doesn't
say
that
Kay
a
manager,
you
want
to
know
it's
done.
Here's
a
video
like
right
he's
out.
You
know.
A
That's
an
excellent
point:
I
mean
being
able
to
tie
that
stuff
together,
that
I
know
artifact
collection
and
they
were
working
through
currently.
But
what
type
of
artifacts
we
collect
is
really
powerful
as
well
being
able
to
collect
something
like
a
video
illustrating
a
product
doing
something
is
far
more
powerful
thing
than
saying
here's,
a
bunch
of
a
wall
of
text.
They'll
read
it
you'll
see
that
it
passes
yeah.
C
D
C
You
can
like
work
on
both
sides
of
the
spectrum
and
kind
of
help
them
meet
in
the
middle.
But
that's
my
only
like
general
feedback
at
the
beginning
is
just
like
think
about
and
say
decompose
that,
and
so,
like
you
know,
what's
the
the
smallest
thing
that
we
can
do
to
move
that
forward,
but
making
sure
that
we're
picking
making
it
right
architectural
decisions
do.
A
C
Mean
like
it's,
not
it's
not
it's
the
other
way
around
of
what
do
you
need
to
be
successful
and
what
can
we
provide?
You
I
think
the
engineers
maybe
might
have
a
different
take
on
it
because
they're
making
the
implementation
decisions,
but
like
I'm,
happy
to
participate.
If
that's
helpful
to
you,
but.
A
I
would
like
to
make
sure
that
I
want
to
put
the
bigger
picture.
That's
a
great
feedback.
I
really
appreciate
that
get
more.
The
bigger
picture.
Vision
on
that
page
I
know
were
supposed
to
call
in
Category
strategy
pages,
so
long
term
strategy.
What
do
we
look?
Think
it'll
be
in
a
year?
Think
big
get
something
out
there
and
then
I'd
love
to
make
sure
that
there's
feedback
on
that,
because
I,
don't
I
want
to
make
sure
that
I'm
not
drying
implementation.
That's
very
important
to
me.
A
I
want
to
make
sure
that
we're
leaving
it
open
enough
that
people
can
be
creative
and
come
up
with
great
ideas
that
solve
these
problems.
That's
that's
the
key
point
cool,
so
I'll
go
ahead
and
make
that
update.
I'll,
send
that
out
to
the
same
people
that
are
on
this
call
right
now,
I
started
to
train
a
little
bit
long
and
I
will
get
this
video
posted
out
to
the
YouTube
unfiltered
learning
I
figure
out
how
to
do
that.
Good.