2 | How to Get Stakeholders to Read Your Requirements Specifications
300 Brickstone Square • Suite 201 • Andover, MA 01810 USA • 1.800.288.7246 • +1.978.649.8200 • info@corpedgroup.com
you went off to do some analysis for a few days or
weeks, and when you returned and showed them
what you had done, they said that it was either
wrong or so different that they didn't know what
to do with your specifications. And you probably
had more questions for them — questions that
they had great difficulty answering.
Combine requirements elicitation activity with
documentation activities and analysis.Things
probably started to go wrong when you wrote the
requirements down. If your notes were informal,
and if you weren't precise about confirming your
understanding of what they told you, it's likely
that there was some miscommunication going
on that you probably weren't even aware of it.
Then you went away to do your analysis. You
did some research and deep thinking, learned
a lot, and probably gained great insight into the
business domain. But if your stakeholders didn't
share that process with you, their perception
of the requirements won't be the same as
yours. And then you added the details, such
as data descriptions and validation rules and
GUI navigation — topics really needed by your
designers — but in so much detail and from such
a different perspective that it overwhelmed your
subject matter experts.
And when you asked the stakeholders to review
the requirements documentation, you really
asked them to take a huge mental leap to catch
up with your understanding — to understand your
way of describing the requirements, which is very
likely to be different from theirs.
It's frustrating for you and for your stakeholders,
and it's bound to lead to missed or wrong
requirements and a delayed system delivery.
There are several things you can do to address
this problem:
• Be careful who you ask; you'll always get an
answer (but not necessarily the right one).
• Combine your requirements elicitation
activity with your analysis and
documentation activities.
• Let the stakeholders dictate the wording
of the requirements. (This isn't nearly as
outrageous as it sounds.)
Requirements Protocol
When you invite people to a meeting and ask
them questions, it's human nature for them to
want to help you by providing answers. But if you
are asking requirements of the wrong people, at
best it will be frustrating for both of you, and at
worst you will get the wrong requirements. These
"subject matter experts" will naturally be hesitant
to approve requirements if they aren't sure they
are right. Avoid asking people to sign off on
something they either don't understand or don't
have the authority to approve.
For successful requirements, the first thing you
should do is to identify all your stakeholders and
determine which stakeholders will provide you
with which requirements. Think "stakeholders"
rather than "users," because often the people in
the role of user have a limited perspective of the
system. For each of your stakeholders, determine
