Many of us agree that one of the first steps in any project is to gather requirements from stakeholders, understand them and then verify those requirements with those same stakeholders. Once verified, the requirements can be given to developers and they can go on their merry way. But there are some who don’t see the value in documenting requirements, and it’s those individuals whom I'm addressing Part 1 of this 2-part blog.
It’s important (and even helpful) to document requirements because:
People are forgetful. Without a dedicated team member (like a BA) whose role is to actively look for requirements, the project can quickly seem an attempt to herd cats. Business stakeholders talk to lots of people – they will forget what they say. Or, the more people they talk to the more the idea evolves in their head so they say different things to different people. Imagine for a moment that they’re only talking to developers. Developers will forget requirements. This leads to a lot of wasted time while team members try to remember what was discussed.
Verbal communication is loaded with errors. Think of the game telephone we used to play as kids. The idea was that a message starts out as one thing but as it is passed from one person to another it can change considerably, especially if more people are involved. Requirements are very specific, detailed items that can easily be changed by using a different word or phrase. Verbal communication of requirements will rarely be accurate.
People sometimes answer the same question differently if asked twice. As I mentioned above, as the business stakeholder talks to multiple people the idea can easily evolve into something else. The stakeholder will give different messages to different people. They may even provide different answers to the same questions at different times. This, of course, leads to ambiguity and leaves everyone wondering “just what are we supposed to do here?”. And sometimes stakeholders simply change their minds. BA’s are experts at asking the same question in different ways before documenting the requirement to be sure that the SME has really answered definitively.
Writing something down forces a person to think about it more carefully than they do when they say it. For example, a SME may say that he wants a report to show totals by month, but when he sees a report layout with 12 columns crammed together, he realized that he actually wants the last 3 months only.
Having a BA write down a user request and then asking the user to review it for accuracy highlights ambiguity and poorly defined requirements. It also identifies missing requirements and undocumented assumptions.
New people joining a project need to get familiar with the requirements. This is most effectively done by having requirements documented.
Evaluating and managing assignments to other team members requires that the assignment to be clear – and this is where the value in documented requirements can be found. Actually this holds true for all employees in any role, and the reason why HR departments encourage managers to articulate assignments accurately. It is difficult to hold someone responsible for carrying out (or not carrying out) a task when the requirement to do so is not documented anywhere. In this case, it would be impossible to hold a developer responsible for implementing (or not implementing) a requirement when that requirement is not documented anywhere. Likewise, it would be difficult to convince a client that the product does meet their stated needs if there are no documented requirements to fall back to.
So there you have it. Eliciting, documenting and verifying requirements with stakeholders is an important project task that should never be skipped. In Part 2 we’ll take a look at the importance of detail in requirements.