Document Analysis

What is it?

Document Analysis is one of the core techniques of business analysis and involves the Business Analyst reviewing existing documentation in order to gather/elicit information they need in order to more effectively do their job.

Why do it?

According to the BABOK Guide (v2), Document analysis is used if the objective is to gather details of existing solutions, including business rules, entities, and attributes...[1]. Other references to documents analysis tend to imply that it is only useful for eliciting requirements. However, I feel that limiting the use of document analysis to existing solutions or eliciting requirements is selling the technique short. Document analysis can be useful in each of the following scenarios:

Learning the Business

First, document analysis can help the BA learn about a new business unit they are engaging with or a new aspect of a business unit they have already worked with. This is especially valuable if there are no business resources available to the BA (due to time constraints or having left the company) or as a preliminary education effort by the BA before engaging with the business resources. This can involve reviewing:


Learning the Project

A second use for document analysis occurs when a business analyst is first engaging with a project that is already underway or a new project that is an evolution of a past effort. This may involve reviewing the following:


Learning the System

A third use for document analysis occurs when the business analyst needs to learn about an existing system. This most often occurs when the BA is beginning a project to enhance or replace an existing system. In this scenario, the BA may review the following documents:


How do I do it?

The Document Analysis technique is normally undertaken in three stages. These are:

  1. Preparation -- This involves:
    1. Determining what documentation is available
    2. Determining which of the available documentation is relevant
    3. Out of the relevant documents, which are the most appropriate for study given the objectives you are trying to achieve (this is especially true if there is a large amount of documentation available).
  2. Review -- This involves studying the documentation you have chosen as the most relevant in order to:
    1. Extract information that meets your needs or may be valuable later
    2. Taking note of questions that the documentation raises so that you can follow-up with SME’s later.
    3. Look for references to other documentation that you may not have come across in your initial search that may be relevant to your effort.
  3. Wrap-Up-- This involves:
    1. Organizing and analyzing the information you extracted from the documents. This may include restating the information in the form of preliminary requirements for later review.
    2. Following-up on any appropriate document references you came across to continue the document analysis process.
    3. Review any questions you captured with the appropriate subject-matter experts in order to elicit answers and identify further questions.


There are several risks to using the Document Analysis technique.

The first is that there is an implied assumption that any documentation is up to date. Especially in the case of systems, process, or policy documentation this may not be true. The BA must take care that they determine how up to date any documents they reference are and treat the information obtained with some level of skepticism until it has been confirmed.

The second risk is that document analysis can be extremely time consuming. Just reading the material can take significant time; but extracting, analyzing, structuring, and confirming the information can take even more. There may always be the desire to just include this one more relevant document into the analysis. If there is sufficient time, this may work. But the lack of time on most projects makes triaging the documentation found in order to assess only the most up to date and relevant a critical step. If there is insufficient time allotted however, do ensure to call that out as a project risk.




  1. The Guide to the Business Analyst Body of Knowledge (BABOK) v2; Section 9.9 -- Document Analysis; Page169

Related Resources