Requirements at the Speed of Thought
Back to School
by Mike Alexander
The first day of school brings back great
memories for me. Going shopping for a Superman backpack, trying out the new
lunchbox (how will the thermos, two desserts and a note from mom all fit in
there?), and getting ready to see old friends and make new ones. It's a time
of excitement and of nervousness. Will I like my teacher? Will I have a lot
of homework? How will I ever read all those books on the bookshelf?!? But
it's also a time of opportunity.
Starting on a new requirements project can be a lot like going back to
school. You get to meet new people, discover new areas and challenges in
your organization, and maybe even get a new lunchbox! But perhaps most
importantly, you get the chance to learn new things about gathering
requirements.
Wait ... "learn new things about gathering requirements?" You already know
how to gather requirements, right? Shouldn't that sentence read "show off
your skills with requirements gathering" or "teach others about
requirements?" Well, it certainly could be either or both of those.
Hopefully you're able to educate the rest of the team about good
requirements engineering practices during every project, and hopefully the
team will be impressed with your RE prowess. However, I think the
opportunity for each of us to learn more about what we do, while we do it,
is even more important.
If you've been working in RE for a while, you may have a typical pattern or
approach to your work, and that approach probably works well. That said,
each of us can always learn something to help improve our work. Maybe a
particular model did or didn't work especially well on this project. What
made this project different? What can you take away from this experience to
improve both the current project and your approach for the next one?
In addition to this "on the job learning," new projects provide great
opportunities to find new sources of information outside the project. What
new blogs, journals, discussion groups, or books are available on RE? What
local professional associations meet to discuss software development topics?
The start of a new project only provides a good opportunity to learn – it's
up to you to take advantage of that opportunity. Use the excitement and
energy a new project brings to help you discover new things about RE. Those
discoveries will improve both your skill set and the project you're working
on, and that new Superman backpack will certainly get the conversations
flowing!
Blog Hits
Are your requirements smarter than a
5th grader?
There was a neat article in the July 13 Dr Dobbs Agile Modeling Newsletter.
http://www.ddj.com/dept/architect/201001273
It basically argued that you could evaluate the quality of a document based on a
set of criteria:C = The percentage of the document that is currently
"correct".
R = The chance that the document will be read by the intended audience.
U = The percentage of the document that is actually understood by the intended
audience.
F = The chance that the material contained in document will be followed.
T = The chance that the document will be trusted.
The CRUFT rating of the document, with 100% being a bad thing, is calculated
with the following formula:
100% - C * R * U * F * T
I thought this was a neat idea. I want to address the "U" factor that represents
the chance that the document will be understood.
We generally have a clear idea in mind of who's going to read our document -
business stakeholders, architects, developers, and testers. What we don't
necessarily do well is to take into account what the people who perform these
roles actually know about the system. If one of our objectives is to make our
documents consumable by making them understandable, we need to be careful about
how we present information.
One technique that I've often suggested that my clients use is to make sure that
prose which gives context to the problem being solved should be understandable
by a 5th grader. When I suggest this, many people insist that the problem is
simply too complex. However, this is probably both overcomplicating your
problem, and underestimating your 5th grader. If you can't explain your problem
to a 5th grader, can you really explain it to a tester who has no context on the
problem? Can you explain it to a business stakeholder who is brand new to his
job?
In addition to facilitating communication with some consumers of the document,
the act of breaking down a problem into simpler terms is a valuable exercise. It
gives us a fresh perspective on the problem, and often allows us to challenge
the assumptions that you've made in a more complex document.
So take a look at your last requirements document. Could a smart 5th grader
understand them?
-Marc Talbot
Blog Link - Are your requirements smarter than a 5th grader? |
