►
From YouTube: UX Showcase: Requirements management
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Well,
requirements
management
is
really
the
process
of
documenting
analyzing,
tracing
prioritizing
and
agreeing
on
product
requirements.
So
there's
really
a
lot
there
to
unpack
when
you
look
at
requirements,
management
at
a
whole,
but
really
when
you
boil
it
down
the
purpose
of
requirements.
Management
is
really
just
to
ensure
that
an
organization
is
meeting
the
needs
and
expectations
of
both
its
customers,
as
well
as
internal
and
external
stakeholders.
A
So
when
you
look
at
a
requirement
itself,
that
is
really
just
a
capability
to
which
a
product
outcome
should
conform.
It
really
defines
the
what
or
the
need
and
not
really
the
how
or
the
implementation
requirements
are
also
long-living,
meaning
they
remain
with
the
project.
As
long
as
that
requirement
is
part
of
the
product
and
they
act
as
some.
What
about
an
outline
of
your
product-
and
you
may
be
asking
you
know
how
our
requirement
is
really
different
from
issues
and
one
of
the
best
ways
that
I
can
explain.
A
A
So
that's
you
know
a
very
brief
breakdown
of
what
requirement
management
is,
but
now,
let's
talk
about
how
comes
into
play
with
Gil
Abby.
So
when
I
joined,
certify
work
had
already
been
started
to
validate
the
problem
of
acquirements
management,
so
catherine
hawley
and
mark
had
performed
a
series
of
generative
interviews
really
to
better
understand
the
problems
that
a
lot
of
the
hughster
are
facing
today,
and
you
know
some
of
these
main
problems
are
you
know.
A
Current
tools
are
clunky
and
dated
they're
oftentimes
overly
complex,
especially
compared
to
some
of
the
needs
of
some
of
the
different
organizations,
but
really
they
make
the
main
issue.
Is
they
don't
integrate
well
with
DevOps
tools?
So
organizations
will
be
managing
the
requirements
in
one
system
and
then
you
know
having
to
tie
that
together
with
their
you
know,
source
code
management.
A
That's
done
in
another
system,
so
there's
a
lot
of
it
results
in
a
lot
of
manual
work,
as
well
as
duplication
of
efforts
to
kind
of
tie
those
things
together
and
show
that
a
requirement
is
actually
being
met
within
your
code.
So
it
was
very
clear
that
there
was,
you
know,
an
opportunity
to
provide
a
better
experience
for
our
users
by
having
this
as
part
of
our
product
offering
and
by
providing
them
with
a
better
integration
with
their
existing
tools.
We
can
help
to
eliminate
much
of
this.
A
A
A
A
One
thing
we
were
able
to
do
was
to
leverage
the
issue
object
model,
though,
which
helped
reduce
a
good
portion
of
this
effort
and
gave
us
some
quick
wins
when
it
came
to
development,
and
this
MVC
was
actually
released
in
1210
and
I'm
gonna
go
ahead
and
walk
you
through
the
current
state
of
this.
Just
in
case,
you
haven't
had
a
chance
to
check
it
out
yet.
A
So,
as
you
can
see,
we're
within
a
project
within
get
labs,
the
planned
project
to
be
specific,
and
you
notice
over
here
in
the
left-hand
sidebar,
we
have
a
new
navigation
item
for
requirements
with
just
one
item
underneath
it
for
a
list
it
within
the
main
content
area
of
the
page,
you'll
notice.
We
essentially
have
this
listing
of
requirements
here,
and
you
know,
as
I
mentioned
before,
we
be
kind
of
leverage
that
the
issue
much
object,
model
to
kind
of
get
some
quick
wins
and
be
able
to
develop
something
a
bit
quicker,
so
you'll
notice.
A
So
it
made
a
lot
of
sense
to
have
that
differentiation
here.
It
also
makes
a
little
more
clear
what
you're
looking
at
like
when
you,
when
you
lay
on
the
page.
You
know
that
you're
not
on
initial
estat.
This
point,
an
additional
area
that
we're
kind
of
straying
from
kind
of
an
existing
pattern
is
the
creation
of
new
requirements
and
the
editing
requirements.
A
So,
as
you
know,
with
with
issues
we
currently
have,
you
go
to
create
a
new
issue,
you're
essentially
taken
to
a
separate
page
where
you
have
a
you
know,
quite
a
bit
of
information
to
fill
out
well,
what's
requirements
at
this
point,
we
really
only
have
one
field
and
that's
the
description
of
the
requirement,
so
it
doesn't
really
make
sense
for
a
user
to
go
to
a
separate
page
in
order
to
do
that.
So
what
we've
done
here
is
when
you
go
to
create
a
new
requirement.
A
A
And
then
you
know
once
you've
filled
that
out,
you
can
go
ahead
and
hit
create
and
it
go
ahead.
It
goes
ahead
and
populates
it
directly
into
that
list
without
being
directed
anywhere
else.
You
also
notice
that
we've
also
presented
a
toast
message
here
in
the
bottom
left
as
additional
affordance,
and
this
would
really
be
beneficial,
especially
like
once
they're
sorting
options
in
case.
You
know
the
requirement
isn't
going
to
be
towards
the
top
of
the
page
and
there's
still
that
additional
for
and
still
using
that
the
action
was
actually
completed.
A
A
There's
also
you
know
times
when
you
know
requirements,
maybe
deprioritized
or
its
decided
that
it
won't
be
part
of
our
product
and
in
those
cases
it
makes
sense
to
be
able
to
to
archive
a
requirement
and
you'll
notice
on
the
far
lot
right.
Here
we
have
this
new
icon,
which
Jeremy
helped
create
for
archiving,
and
so
the
user
can
easily.
A
You
know,
select
this
and
it'll
be
moved
over
into
this
archive
tab
that
we
have
available,
and
so
that
way,
there's
still
that
history
of
the
requirement
in
case
you
ever
may
need
to
refer
back
to
it
as
well
as
if
it
ever
has
decided
to
you
know
prioritize
this
requirement.
It
can
always
be
brought
back
by
reopening.
A
One
additional
you
know
consideration
that
I
mentioned
that
we
made
sure
to
include
was
the
the
creation
of
an
empty
state
for
requirements.
So
if
you
haven't
had
any
requirements
created
and
you
go
to
this
cromoz
tab,
we
wanted
to
give
a
little
bit
of
context
and
to
to
whatever
apartment
actually
is
and
so
similar
to
you
know,
issues
and
mrs
there
empty
states
we're
also
presenting
the
user
with
an
empty
state
here,
just
to
provide
that
context,
as
well
as
the
ability
to
easily
create
a
new
requirement
from
that
description
as
well.
A
So
as
you'll
notice
is
pretty
lean
for
our
first
iteration,
but
it
really
kind
of
opens
the
door
to
start
figuring
out.
You
know
what
are
the
next
major
improvements
had
a
user
would
really
be
looking
for,
and
how
can
we
meet
some
of
those
needs
earlier?
Instead
of
you
know,
starting
with
something
large,
we
can
kind
of
iterate
towards
an
ideal
solution.
A
During
the
time
that
a
lot
of
this
work
was
being
done,
we
also
been
conducting
a
series
of
a
research
sessions,
and
the
goal
of
this
was
really
the
validate
at
the
direction
we
were
heading
was
in
line
with
user
expectations,
as
well
as
to
capture
any
usability,
concerns
and
improvements
that
we
can
make
with
the
MVC
being
pretty
lean.
We
were
also
able
to
take
time
during
these
sessions
to
really
help
inform
the
direction
of
requirements
management
and
by
including
some
generative
questions,
as
well
as
running
through
a
card
sort
activity.
A
A
A
In
addition
to
this
work,
I'm,
currently
wrapping
up
the
research
sessions
and
be
working
to
distill
the
findings
that
are
coming
out
of
that
so
I'll
be
creating.
You
know
any
issues
needed
based
on
usability
issues
that
we
identify
as
well,
as
you
know,
leveraging
the
insights
and
prioritization
from
users
to
really
help
inform.
You
know
some
of
the
future
work
that
we're
doing
for
requirements,
management.
A
And
that's
all
I
have
for
you
today,
but
I'm
sure
I'll
be
following
up
here
in
the
future,
as
we
continue
to
iterate
on
this
product,
offering
just
what
I
mention.
If
you
do
have
any
questions
or
want
to
follow
it
with
me,
please
don't
hesitate
to
reach
out
I've
included
both
my
slack
handle
below
as
well
as
requirements
management
channel
that
we
use
for
communication
within
slack
thanks
for
listening.