Requirements are under suspicion. Read between the lines of software and project management journalism and you'll hear nearly everyone lamenting the sad state of requirements. Managers plan only eight percent of project time for requirements. Developers worry about Zen-like requirements that lack sufficient detail to produce serviceable code. Testers think they have to backfill requirements. So, what were the analysts doing?
Have you ever seen the comedy Office Space? In a scene right out of Dilbert, the person responsible for requirements is interviewed by two "rightsizing" consultants. Tell us what you do, they ask. He replies, I talk to the customer to find out what they want, and then I relate that to people who write the code. A wink between the consultants tells you this analyst is history. After all, can't the customer talk directly to the people who code the software? Maybe yes and maybe no. Sometimes developers are responsible for everything from requirements to unit testing. At the opposite end of the spectrum, no one person or group has the specific task of requirements definition. Marketing talks to the customer, architects talk to marketing, and developers talk to architects. Apart from these role-and-responsibility clashes, what else ails requirements?
How Requirements Become Suspect
Requirements often fail because they are too brief, too vague, too confusing, or all of that. To some, this implies that the meager time devoted to requirements is over-spending. The opposite is more often true—there isn't enough time. However, incorrect allocation of time is only a symptom; less obvious causes are more likely to lead to poor results:
We believe in miracles. Ever hear a story about how some genius sold his idea based on a napkin sketch? I think sometimes we expect our analysts to do the same. Hey, once the sketch is down, we're done! Time to hand the napkin over to production.
We get carried away by sports analogies. In some organizations, the requirements stage feels like the warm-up before a game. We spend just enough time to loosen up, because we are saving time for the real work. So, requirements becomes all about establishing the customer relationship and maintaining a friendly mood.
We believe in components. This is good, because once we really have requirements this could buy us time and produce reliable results. Without clear requirements, we risk assembling a van instead of the sedan that was requested. We heard "vehicle for the family," started thinking about which components to use, and went to work.
Assumptions Are Silent Expectations
You've heard the truism "To assume makes an ass out of u and me." We make assumptions all the time in our jobs, and sometimes it works. But a more reliable path is to make our assumptions public where they can be either rejected, or cultivated into clearer expectations when reasonable.
Here are common software development assumptions that can work for good or ill:
Experience is everything. When an experienced analyst starts a project, either she or her manager might assume she knows all the system issues and is asking the right questions. In a worst case the analyst may not probe enough, thinking this is like every other system she built. The manager might believe the experience lets him cut the time needed for requirements.
Communication is free. Some people believe that school taught us everything we need to know to about communication. Sometimes, even a Ph.D. in English can't guarantee that! By realizing our own filters and biases, we can work to remove any barriers or distortions they might create.