Assuming the Worst about Requirements

analysis . Maybe this is true of some people. Others may be good at analyzing software problems, but not at analyzing business requirements. The pursuit of one discipline in college tends to produce vertical thinkers-deep reasoning down a specific path to arrive at a conclusion. To be good at analyzing anything you need to learn lateral thinking*-broad, pattern thinking, which generates new patterns by changing perspective.

Software is easy to change . Hardware engineers used to believe that software could be changed "for free." If the software specs were vague it didn't matter, because software could be changed. Any organic software development run amuck will slip to the dark side of this assumption, which is a costly maintenance cycle.

What we hear is what is needed . Precise capture of a request might cause problems in two ways. One, we believed the meaning and request was clear. Two, given the first case we fall into the next-we don't ask questions. By asking questions we have an opportunity to verify a request. Questions can also test whether the customer's request would really solve their problem.

Reversing the Trend
Analysts could use a little respect, not to mention reasonable schedules for producing decent requirements. What can we do to change current opinion and practice? Clearly convey your perception of the product so others can see what you have and what is missing. This can also increase analyst and customer confidence. Here are three recommendations:

 1. Produce something demonstrable . There are techniques for every cultural style:

• Your organization might build a simulation based on system requirements or an executable model that uses model content to run a simulation.
• IT departments have been using prototypes to good effect for years.
• A commercial software venture might use Agile or XP techniques where small cycles of requirements-gathering-to-code produce working parts of the final system in incremental stages.
• Anyone can produce visuals-models or pictures that help speak to what we know and what we don't.

 2. Iterate . Once you've demonstrated something, you aren't done. You may have new information that needs to be incorporated into your requirements documen

3. Keep a record . Include your findings, tasks, process, key insights, and timeline. Keep a written record of requirements in a form that is useful for technical staff-you'll need to hand this off. Take control by developing your own plan with estimates. Track actuals. Write down events, observations, setbacks, and breakthroughs in a journal. This will let you recall the story behind the numbers, so that you can review them in a personal or project retrospective. Through records, you can better understand your strengths and weaknesses and just might improve your skills.