UML Weekend Crash Course™ - To Parent Directory

Session 4—Defining Requirements for the Case Study 43
Pitfall #1: Making assumptions
Every piece of information encountered during problem definition or analysis is under suspicion.
I can’t tell you how many shouting matches I’ve mediated between programmers and
clients because one or the other assumed something in a conversation. The programmer
assumed that the client spoke for everyone who does the same job, not realizing that nearly
everyone had his own peculiar way of doing it. The client assumed that the programmer
already knew most of the facts and only called the meeting to ask specific questions. So
the client didn’t volunteer any of the missing information and the programmer remained
ignorant.
Confirm everything! When possible and reasonable, confirm it in multiple ways. Here
again, the UML provides us the means to do exactly this type of verification. I’ll provide
examples of this cross checking as you learn about each of the UML diagrams.
Pitfall #2: Replicating existing implementations
This is probably the single most common and destructive pitfall. Most projects are under
serious time pressure. Managers constantly ask the programmers, “Where is the code”
Analysis is all about critical thinking — asking why and challenging the status quo. What
brought the approving managers to the point that they were willing to spend the company’s
money on this project Something was viewed as an obstacle to the company. How can you
remove the obstacle if you simply replace the existing system with a duplicate system in a
different technology
Pitfall #3: Mistaking preferences for requirements
Users are people. People have opinions — and not often the same opinions. Beware of people
who have a vested interest in how things are done. One client may be the one who thought
up the current process. Another client is the dragon slayer, seeking out anything and everything
to change. Other clients simply refuse to reach a consensus.
Often, the most willing client to participate as the project liaison takes on one of
the first two roles, champion or dragon slayer. Both bring a strong bias to the project
requirements.
This situation challenges you to be the objective outsider. The modeling techniques I
cover in the rest of the course provide you with a set of tools that will help objectify the
issues and identify inconsistencies.
REVIEW
In this session, you began your evaluation of the problem statement, the description of the
problem you are supposed to solve, or to be fair, an opportunity you are supposed to
exploit. You identified four major types of requirements: business process, constraints, rules,
and performance. You then used three different perspectives to investigate these requirements:
users, resources, and functionality. The different perspectives help to guarantee that
you don’t miss anything and that you can validate the requirements by cross-checking
them.