Finish it in 2 days, no reference needed
Software Engineering
Do any of the 10 steps that Jordan Hirsch gives in “What the Heck Are We Building?” (see
reading assignment) particularly resonate with you? Do you disagree with any of them? Is
so, tell us why. Did you think the cartoon was accurate?
What
The
Heck
Are
We
Building?
10
Steps
To
Successful
Requirements
Gathering
By
Jordan
Hirsch
(posted
on
Phase
2
Technology
web
site
November
21,
2013)
There’s
a
common
refrain
that
gets
uttered
at
the
end
of
unsuccessful
projects:
“The
requirements
weren’t
clear.”
Fingers
start
pointing,
blame
gets
thrown
around,
and
no
one
ends
up
happy.
Thankfully,
there’s
a
simple
way
to
alleviate
that
problem,
and
it’s
as
obvious
as
it
is
challenging:
requirements
gathering.
Depending
on
your
project
methodology,
you
may
do
this
step
at
the
beginning
during
a
Discovery
phase,
you
may
do
it
during
the
project
within
each
sprint
or
build
cycle,
or
you
may
skip
it
altogether
and
hope
for
the
best.
That
last
option
is
a
simple
way
to
sabotage
your
project
and
guarantee
a
lot
of
late
nights
and
awkward
status
meetings.
This
doesn’t
have
to
be
you!
Successful
requirements
gathering
is
both
an
art
and
a
science,
but
there
are
some
general
steps
you
can
take
to
keep
this
all-‐important
step
of
your
project
on
the
right
path.
Here
are
some
guidelines
that
we
try
to
follow
at
Phase2:
1.
Establish
Goals
&
Objectives
Early
This
step
can
feel
redundant:
of
course
we
know
why
we’re
doing
this
project…don’t
we?
Even
if
you
think
you
know,
write
it
down,
and
get
your
client
to
sign
off
on
it.
Without
clearly
stated
goals
and
objectives,
you
are
lacking
a
framework
to
guide
future
decision-‐making.
How
do
you
know
if
a
newly
introduced
requirement
actually
fits
in
your
project?
Simple:
does
it
help
accomplish
a
goal,
or
does
it
satisfy
an
objective?
If
so,
it’s
probably
a
good
fit.
If
not,
it’s
a
good
candidate
for
a
future
release.
2.
Write
It
Down
When
you’re
in
the
midst
of
stakeholder
interviews
and
document
review,
you
can
often
feel
like
you
have
a
great
grasp
on
things.
But
then
a
week
goes
by,
and
some
details
start
to
get
a
little
fuzzy,
and
you
realize
you
don’t
quite
have
a
full
grasp
of
X,
Y,
or
Z.
It
sounds
obvious,
but
making
sure
that
you
are
taking
detailed
notes
during
your
stakeholder
interviews
is
a
powerful
step
in
successful
requirements
gathering.
And
it’s
not
enough
to
just
write
everything
down,
as
you’ll
see
in
#3…
3.
Be
Transparent
Sure,
you
understand
the
requirements.
And
your
client
understands
the
requirements.
But
does
your
client
understand
your
understanding
of
the
requirements?
After
every
meeting,
go
through
your
notes
and
clean
them
up
–
then
share
them
with
the
project
team,
including
the
client.
This
transparency
not
only
helps
make
sure
everyone’s
on
the
same
page,
it
fosters
a
sense
of
project
buy-‐in
all
the
way
through
your
project,
beginning
with
the
requirements.
And
it
circumvents
the
issue
of
someone
saying
“hey,
you
agreed
to
X
but
it’s
not
here!”
6
weeks
into
the
project.
If
it’s
not
in
the
notes,
it
didn’t
happen.
4.
Talk
To
the
Right
People
A
project
can
often
have
“hidden”
stakeholders.
Ask
probing
questions
in
your
kickoff
and
initial
meetings
with
your
client
to
try
and
get
to
who
the
real
users
are
–
often
those
people
are
not
going
to
be
the
main
decision-‐makers,
but
their
buy-‐in
is
essential
to
a
successful
project.
Disgruntled
users
who
are
forced
to
use
a
system
every
day
that
was
designed
without
their
input
are
a
key
ingredient
for
a
failed
project.
5.
Get
Detailed
Don’t
assume
that
you
understand
everything,
even
if
it
seems
obvious.
A
seemingly
simple
requirement
such
as
“we
want
a
blog”
can
mask
all
sorts
of
underlying
assumptions,
requirements,
etc.
What
are
the
fields
for
a
blog
post?
How
are
authors
managed?
What
about
tagging?
Categories?
How
are
the
posts
displayed?
Are
they
aggregated
into
an
archive?
Is
there
an
RSS
feed?
Who
are
the
authors
and
what
is
their
level
of
technical
proficiency?
Etc.
etc.
etc.
The
devil
truly
is
in
the
details,
but
you
can
catch
him
by
the
tail
if
you
ask
a
lot
of
questions
and
don’t
rely
on
assumptions.
6.
Confirm,
Confirm,
Confirm
This
ties
into
“be
transparent”
but
is
not
entirely
the
same
thing.
Just
sharing
your
notes
with
a
client
is
great,
but
far
more
valuable
is
actually
having
a
quick
review
with
them
and
getting
their
official
sign-‐off.
This
is
true
for
meeting
notes,
user
stories,
diagrams,
wireframes,
really
any
kind
of
requirements
artifact
that
you
are
creating.
Radio
silence
is
not
an
indicator
of
success
–
get
actual
confirmation
from
your
client
that
you
are
representing
the
requirements
correctly
in
whatever
format
you’re
using,
then
move
on.
7.
Be
An
Active
Listener
Making
someone
feel
heard
is
one
of
the
greatest
things
you
can
do
for
them.
But
it
goes
beyond
just
listening
to
what
they
say
–
you
also
need
to
listen
to
what
they
don’t
say,
and
how
they
say
things,
and
read
their
body
language,
etc.
This
is
called
“active
listening”
and
it’s
a
key
component
both
of
successful
requirements
gathering
and
improvised
comedy,
among
other
things.
Don’t
assume
that
you’re
always
getting
the
whole
story
–
listen
for
little
cues
that
reveal
pain
points,
desires,
unstated
goals,
and
assumptions.
8.
Focus
On
Requirements,
Not
Tools
Be
careful
when
you
are
gathering
requirements
that
you
are
really
focusing
on
and
listening
to
what
your
client
needs,
not
what
your
tool-‐of-‐choice
happens
to
do
best.
Even
if
you
know
you
are
going
to
be
using
a
certain
product,
you
need
to
adapt
the
product
to
the
user,
not
the
other
way
around.
Listen
and
gather
first,
then
determine
where
the
gaps
are
between
your
client’s
needs
and
any
existing
product
you
may
have
in
mind.
Remember:
requirements
are
about
the
WHAT,
not
the
HOW.
9.
Prioritize
In
an
agile
methodology,
we
work
towards
a
Minimum
Viable
Product
(MVP),
which
encapsulates
the
least
amount
of
functionality
that
would
count
as
a
successful
product
at
launch.
Even
when
following
a
non-‐agile
methodology,
prioritizing
is
your
friend
when
you
are
gathering
requirements.
It’s
easy
for
requirements
gathering
sessions
to
turn
into
wishlist
gathering
sessions,
where
stakeholders
tell
Santa
(i.e.
you)
everything
they
want.
The
point
isn’t
to
ignore
that
information
(in
fact
it
often
reveals
goals
and
assumptions
if
you’re
using
Active
Listening)
but
rather
to
clearly
and
transparently
prioritize
what
you’re
hearing
and
delineating
what
is
in
scope
for
your
initial
launch
and
what
is
not.
You
definitely
want
to
track
wish-‐list
items,
“nice-‐to-‐haves,”
etc.
but
prioritizing
helps
you
focus
your
efforts
and
helps
you
make
decisions
if
time
gets
short
and
something
has
to
go.
10.
Remember
That
You
Didn’t
Get
Everything
Even
the
best
requirements
gatherer
is
going
to
miss
things.
Why?
Because
you
and
your
clients
are
human
beings,
and
human
beings
make
mistakes.
You
will
think
of
things
later
that
you
forgot
to
ask.
Your
client
will
think
of
things
that
they
forgot
to
mention.
Things
will
change.
Priorities
will
shift.
The
good
news
is
that
if
you
plan
ahead
for
this,
you
can
build
in
time
during
your
project
lifecycle
for
ongoing
requirements
management.
This
time
is
essential
because
requirements
(being
human-‐driven
and
human-‐created)
are
simply
not
static.
Giving
yourself
time
to
actively
manage
requirements
throughout
the
entire
project
can
help
you
stop
scope
creep
before
it
starts,
and
make
sure
that
your
team
is
always
focusing
on
the
right
set
of
priorities
that
match
actual
requirements.
There’s
obviously
a
lot
more
that
can
be
said
about
the
art
and
science
of
requirements
gathering,
but
hopefully
this
list
has
given
you
some
helpful
tools
to
manage
this
process
successfully.
If
you
are
the
client
on
the
other
side
of
this
requirements
process,
check
out
Nate
Parsons’
blog
post
“How
to
own
a
boat
or…
How
to
maximize
the
ROI
on
your
expensive
new
website”
to
learn
about
the
questions
that
your
team
should
ask
while
gathering
requirements
for
your
new
site.
Good
luck
out
there!
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
