How to Use Document Analysis for Business Analysis
Document analysis is probably your first stop in elicitation for business analysis. Here, you peruse company documents to glean information about the current environment.
Why go off and try and create something new without understanding what the company’s operations are all about? You don’t go into a job interview without understanding the prerequisites and skills needed for the job. You don’t shop for a car without understanding the available options and warranty information. Similarly, you don’t want to start eliciting requirements from stakeholders without understanding more about their current environment.
Analyzing existing documentation gives you a good sense of the project; the business processes you’re supporting; and the rules, data, and stakeholders involved. You can get a good return on your investment for your time spent using this technique.
Gathering up and reviewing existing documentation also gives you clues as to who needs to be interviewed, data that needs to be captured, business rules that need to be enforced, processes that need to be followed, and that sort of thing.
For instance, suppose you’re assigned to a project to create or update some marketing reports. You start by gathering the reports that are currently in production. Here are some things you may notice:
The fact that the report can be run for salespeople, sales managers, and division managers: That information tells you that these people need to be included in your elicitation sessions so you can understand their needs.
What data the company is currently capturing: That info is important because this data is the information the stakeholders need in order to make decisions.
Info that helps you understand the business rules the company enforces: Business rules are guidelines, such as calculations and security clearance levels, that define and shape a company’s business operations and procedures. Consider these rules when defining and designing the solution for your project.
You can pull all of this stuff out of the existing reports to create a starting point for developing the right elicitation questions, which helps you create the new report.
To perform document analysis, follow these steps:
Gather documentation that has already been created on the business area, systems, and so on, and that is in scope for the project.
This documentation may be all over the place — on document collaboration tools, such as Microsoft SharePoint, in servers, and in binders on people’s desks. If you don’t know whether the documentation exists, ask people involved with those systems whether you can find existing documentation.
Read the documents and take notes.
Include in your notes things such as unclear information, glossary terms you need to define, processes that are executed, data involved, and systems and people that interface with the areas under study.
Develop in-depth questions for the project team, based on your findings.
Examples of such questions include “Do you still pull data from System ABC?”, “Are the stakeholders still located in California?”, and “Does System X still contain the validation routines?” These are the kinds of in-depth questions this approach generates.