The Business Analysis Body of Knowledge (BABOK) which is the current documented standard for Business Analysts lists the following techniques as ways to elicit requirements from stakeholders.

  • Brainstorming
  • Document Analysis
  • Focus Groups
  • Interface Analysis
  • Interviews
  • Observation
  • Prototyping
  • Requirements Workshops
  • Survey/Questionnaire

In this post I am going to focus on Document Analysis and how it can be a useful step in your requirements gathering efforts. Blog posts in the future will touch on some of the other techniques.

When you first start a project or join an existing one, analyzing existing documentation is a great way to familiarize yourself with how the business currently functions. This is especially important when the subject matter experts are too busy to dedicate enough time to meet with you to describe the current process or when experts have left the organization and all that is left is documentation. Reviewing the documentation will help you to understand the current situation and begin to formulate the questions to ask of stakeholders to gather additional requirements. If the project is enhancing an existing system or replacing it with a new one it will be important to know which functionality of the existing solution the stakeholders want to carry over to the new one and which can be retired. A great source for requirements in that case is looking at old requirement definition documents and reusing requirements. It is important to make sure that if you are reusing requirements that they are up to date and have not been made obsolete by other enhancements to the system.

Another category of documents that can be analyzed are from proposed solutions to the business problem. Many times after the business problem has been defined members of the project team can begin to brainstorm solutions that will solve the problem. While it is not a good idea in most cases to define how the solution will solve the problem in the requirements, you will still have a general idea of what the needs will be of any solution that is used. For example, the purpose of the project may be to upgrade an existing version of SharePoint to the latest version. Some documents that would be worth reviewing include training guides, system specifications, and other product literature. It is even a good idea to research how other organizations have handled the same tasks and problems they may have encountered.

While reviewing the existing documentation it is important to jot down questions that arise that can be brought to the stakeholders. This is a great first step as you prepare for interviews or other interaction based elicitation methods. Using existing documentation allows for the analyst to not start their requirements gather process from a blank page and leverages existing artifacts to create or confirm requirements. One of the drawbacks is that documentation can quickly become outdated so it is important to confirm that what you are reviewing is the most current. Reviewing existing documentation can be a time consuming process, but is a great starting point in the requirements elicitation process.