“;ey helped the project by organizing the require-
ON THE SAME PAGE
ments to tell a story.”
;e team also discovered missing requirements
and project areas that had no written requirements
Visual models can help ensure that all project team
members share the same understanding of the
project’s requirements—especially since di;erent
people see the same things di;erently,
Mr. Podeswa says. While team members might grasp only their respective
project components, a model displays
the whole picture.
“Not everyone thinks at the same
level,” says Pierre Gagné, president of
Insurance Frameworks Inc., Quebec
City, Quebec, Canada. “Some think
close to the ground and some think
And some team members can get
so mired in the technical details of a
project that they miss critical pieces
When a Canadian regional government had to
update its human resources software, Mr. Podeswa
was brought on to help select and purchase a new
system. He started modeling with a group of busi-
ness analysts who had already been working on
everything is in the blueprint and laid out on top
of each other.”
If visual modeling relies on the old adage that a
picture is worth a thousand words, Ms. Beatty ;nds
another number equally useful: seven. Based on the
work of psychologist George A. Miller, PhD, Ms.
Beatty uses this concept to explain the useful role of
visual requirements models. As Dr. Miller showed,
people’s short-term memory can absorb about
seven new things at a time, give or take two. Ms.
Beatty often sees this play out on projects.
One such project aimed to build a game-like simulation for a government contractor. “;e customer
handed us their list of 2,000 requirements, and said,
‘Help us ;gure out if we’re missing anything,’” Ms.
Beatty says. Not only would parsing through the list
of 2,000 items take the project team too much time,
but Ms. Beatty still wouldn’t have been able to ;gure
out everything the project needed.
“As I was reading through, somewhere around
As I got more
number 10, I forgot what number one was about,”
Ms. Beatty says. “Reading through is impossible for
comparing requirements and looking for redundan-
cies or missing pieces.”
Ms. Beatty and her team mapped the list of
requirements onto models: requirements map-
ping matrices, process ;ows and context diagrams.
“When it was just a list, no one really could under-
stand the essence of what the system did, but these
models tied the requirements together,” she says.
involved in the
of projects, I
realized that these
models, if drawn
at the beginning
of a project, would
reveal to me missing