►
From YouTube: Requirements Management Office Hours - June 26, 2020
Description
Requirements Management office hours are setup to allow everyone to ask questions, and give space for a cross-functional discussion.
User Research Epic Discussed - https://gitlab.com/groups/gitlab-org/-/epics/3708
A
A
A
A
A
I
did
post
a
link
here
and
I'll
post
it
in
the
youtube
as
well,
because
it's
a
public
link
to
our
epic,
our
user
researcher
nick
has
gone,
and
he
did
a
really
great
job
of
doing
a
user
research
study
there's
actually
a
decent
amount
of
good
feedback
from
them
that
we're
going
to
kind
of
work
through
as
a
team.
So
I
think
the
next
steps
for
us
will
be
to
triage
some
of
that
information
coming
in
that
that
epic
now
has
a
decent
number
of.
A
I
think
there's
one
two
three
likes
eight,
eight
or
nine
items
on
that
epic.
They
were
all
feedback
from
the
user
interface
study,
so
I
think
we're
probably
going
to
focus
on
that
moving
forward.
I
think
we
have
some
things
in
13
2
and
we
want
to
do
some
cleanup
in
13
2,
but
13
3
and
onward
will
probably
start
prioritizing
those
user
interface
updates
or
just
user
priorities.
So
I
think
that'll
probably
be
next
on
the
list.
A
A
As
satisfied-
and
I
think
nick
and
I
talked
about
this
too
a
little
bit,
I
think
the
idea
is
there's
really
two
concepts
for
requirements.
There's.
Is
it
satisfied
or
verified
by
testing
and
is
it
implemented,
and
I
think,
where
we've
gotten
a
little
bit
hung
up
is
I
think
a
user
should
be
able
to
manually
mark
a
requirement
as
implemented,
but
maybe
not
satisfied.
A
The
idea
behind
satisfied
was
really
it
was
tested
in
some
capacity.
Now
there
is
a
concept
of
manual
testing
which
makes
this
a
little
bit
interesting,
so
we
kind
of
have
to
work
through
that.
I
agree
that
this
the
states-
I
think
we
probably
want
to
do
another
little
user
research
on
that
or
just
work
through
it
as
a
team,
but
I
think
satisfied,
not
met
or
unknown,
are
all
valid
options,
and
I
think
we
just
want
to
hone
down
onto
what
we
really
want
to
do.
A
There
satisfied
I
liked
a
lot
and
how
we
did
it,
because
it's
not
verified
which
doesn't
use
the
language
that
a
more
regulated
industries
tend
to
use.
I
think
it's
more
open
that
way
and
more
accessible
to
people,
but
I
think
we
want
to
understand
when
we
say
satisfied.
Does
that
mean
that
the
requirement
is
implemented
and
has
been
tested
and
has
proven
to
be
working,
or
does
it
just
mean
that
the
requirement
was
implemented
in
the
code
somewhere?
A
A
I
actually
have
it
on
my
agenda
this
afternoon
to
kind
of
work
through
some
of
these
ideas
of
requirements
states
because
it
is
getting
a
little
bit
confusing
as
we
move
forward,
and
I
want
to
make
sure
we
clarify
that
as
early
as
possible.
So
thank
you
for
bringing
that
up.
If
there's
any
feedback
on
that
elsewhere,
I
may
open
up
an
issue
where
we
may
continue.
The
discussion
on
the
linked
issue,
which
is
the
manually
marketing,
is
required.
It
depends
how
that
discussion
grows.
A
B
I
didn't
put
it
on
the
agenda,
yet
I
will.
I
don't
know
if
you've
seen
this
kind
of
parallel
discussion
going
on
about
in
the
project
management
team,
about
extensible
issues
and
now
we're
also
at
the
point
where
we
have
iterations.
So
we're
talking
about
things
like
the
prefixes
that
we'll
use
for
for
these.
So,
like
I'll,
give
you
an
example
when
we
were
doing
iterations,
we
were
talking
about
a
multi-character
prefix,
there's
also
an
open
issue
around.
B
How
would
we
prefix
like
a
branch
reference
and
we're
kind
of
running
out
of
character,
space
right
for
for
new
prefixes?
So
I'm
kind
of
wondering
what
your
thoughts
are
like?
Would
people
ever
want
to
reference
requirements
from
from
different
places
and
then
have
you
given
anything
kind
of
like
as
well
we're
going
to
end
up
with
so
many
things
that
kind
of
look
like
issues
or
like
they're
kind
of
they
kind
of
all
cluster
in
one
type?
B
If
you
don't
want
to
think
about
them
as
issues
they're,
definitely
not
merge,
requests,
they're,
definitely
not
vulnerabilities,
they're,
definitely
not
branches,
but
they're
broadly
similar,
like
their
issues,
their
epics,
their
requirements,
their
iterations.
They
all
sort
of
act
like
in
similar
ways.
A
I
have
thought
a
lot
about
the
need
to
be
able
to
reference
a
requirement
from
within
an
issue
the
idea
behind
requirements-
and
this
goes
somewhere
back
to
our
previous
discussion
about
the
idea
of
having
requirements
to
be
marked
as
implemented
and
then
satisfied.
There
is
the
concept
where
we
may
want
to
use
within
a
merge
request.
A
I
do
see
the
problem
with
running
into
a
lot
of
special
characters
are
sort
of
already
used
or
the
ones
that
make
sense
are
already
used.
We
don't
want
to
do
some
goofy
thing
like
backslashes
or
forward
slashes,
which
have
other
implications
as
well,
so
we're
kind
of
limited
to
the
character
set
we
can
use.
A
A
I
just
don't
know
how
we
want
to
handle
it
necessarily
because
I
do
think
we
want
to
be
able
to
close
it
or
to
implement
a
requirement
via
merge
request.
Just
like
you
can
close
an
issue
via
emerge
request,
you
could
then
implement
a
requirement
of
your
emerge
request
and
then
you
know
way
down
the
road.
If
you
wrote
an
issue
to
implement
a
requirement,
any
merge
requests
created
against
that
would
automatically
be
tagged
as
hey
this
implements
that
requirement
and
then,
from
a
traceability
perspective.
A
A
I
think
it's
sort
of
a
medium
priority.
We
have
an
exercise
this
afternoon
sort
of
card
sorting,
with
nick
just
had
to
figure
out
priority
where
things
are
so
if
anybody
has
not
been
invited
to
that
and
wants
to
be,
I
think
right
now,
it's
john
it's
the
ems
and
pm's
and
ux
john.
If
you
want
to
broaden
that
out
to
invite
an
engineer
to
I'm
totally
fine
with
that.
B
Yeah
things
should
just
be
open
to
anyone
who
who
has
an
interest
in
this
in
this
area,
like
one
thing
that
was
going
through
my
mind,
yesterday
was
just
like
if
you're
running
out
of
character
space,
why
not
just
use
the
the
pound
or
hash
sign
for
everything
like
like.
I
know
it's
complex
on
the
back
end,
but
from
the
user's
perspective
like
they
don't
really
care
if
they
start
to
type
a
hash,
they
want
the
machine
to
tell
them
to
suggest
back.
Maybe
this
requirement,
maybe
this
issue.
B
Maybe
this
iteration,
they
don't
particularly
particularly
care,
or
they
hope
they
probably
don't
want
to
have
to
think
right.
They
know
all
these
things
are
broadly
similar.
They
don't
want
to
have
to
think.
Oh
am
I
trying
to
link
an
epic
here?
Am
I
trying
to
link
an
issue
or
just
type
and
let
the
machine
figure
it
out.
A
I
completely
agree
with
that.
I
thought
of
that
a
lot
when
we
started
referencing
epics
and
issues
and
the
fact
that
they're
different
I've
oftentimes
been
sitting
there
going
wait
was
that
an
epic
or
an
issue
and
someone
we'll
promote
an
issue
to
an
epic
and
then
you're
even
more
confused,
because
the
links
kind
of
need
to
change
and
the
ability
to
type
like
a
pound
sign
and
then
start
typing
a
number
and
have
it
just
suggest
relevant
things
would
be
fantastic.
A
I
don't
know
how
well
that
functionality
works
right
now.
I
sometimes
get
some
interesting
results
when
I
put
in
like
an
issue
and
then,
when
I'm
trying
to
reference
an
issue
I'll
get
a
lot
of
not
quite
related
issues
or
it'll
sit
there
and
spin,
and
it
won't
give
me
back
older
issues.
So
I
think
there's
probably
some
technical
debt
around
that
we
want
to
look
at,
but
I
think
that'd
be
great,
and
then
you
know
from
that
list.
B
Yeah
I
mean
it's
a
little
different
for
iterations
and
milestones
are
definitely
one
type
of
thing
and
then
like
issues,
requirements,
even
epics,
maybe
might
be
another
kind
of
thing,
and
but
they're
they're
definitely
different
from
commits
right
or
like
like
branches
or
something
right,
so
like
very
different
from
those
things.
So
maybe
things
that
are
kind
of
link
like
cluster
in
some
way
together,
we
could
use
similar
things.
B
We'd
have
to
really
think
about
the
architecture
in
the
back
end
and
how
we
actually
do
like
some
sort
of
key
value
store
to
quickly
recommend
these
things.
But-
and
the
other
thing
was
like,
I
guess,
if
you're
talking
about
linking
things
from
merge,
requests
the
possibility
that
we
would
have
like
a
widget
similar
to
issues
have
you
know
linked
requirements
or
related
requirements
or
blocking
requirements.
A
Problems
with
that
from
a
merge
request
perspective,
the
idea
of
a
merge
request
being
able
to
implement
a
requirement
is
a
pretty
powerful
concept
from
the
requirements
perspective.
But
I
don't
know
if
we
want
to
widgetize
that
to
your
exact
point,
I
I
love
the
idea,
but
then
do
we
suffer
from
ux
overload
and
I
think
we're
kind
of
up
against
that
line
more
than
we'd
like
to
be
in
certain
areas.
I
think
maybe
we
should
talk
to
nick
about
that
as
well.
A
Does
he
have
any
suggestions,
because
this
goes
back
to
your
idea
of
having
just
one
symbol
for
issues,
merger
issues,
requirements
epics?
If
you
had
one
widget
where
you
could
link
things,
and
it
would
show
you
all
the
different
things?
Would
that
be
a
better,
less
cluttered
experience
for
the
user,
where
they
could
just
drop
down
into
a
menu,
and
they
start
typing
a
number
and
it
would
give
them
you
know
related
to
all
sort
of
in
the
same
clump.