Document Analysis · Business Analysis Notes

What it is#

The BABOK Guide describes document analysis as eliciting business analysis information by examining existing materials about the business environment and its assets. It is especially useful when a subject matter expert is not available.

Two broad kinds of material are useful:

Documentation of the current solution: business rules, technical and training documentation, problem reports, previous requirements documents.
Background research: market studies, industry standards, regulations, organization charts and staffing documents.

The work has three parts: prepare (find materials and judge their relevance, accuracy, credibility and whether the audience will understand them), analyze (study the content, look for gaps and conflicts, spot new topics, and record notes with the topic, source, open questions and follow-up actions) and record the results in working documents, sometimes visual ones.

It is one of the most used elicitation techniques in practice. In a 2020 survey of business analysts in Ukraine, Gobov and Huchenko found interviews and document analysis at the top of the list, with document analysis used more often in outsourcing companies than elsewhere.

When to use it#

Use document analysis when:

you join a project and need to learn the domain quickly;
you are replacing or enhancing an existing system and need to know what it does today;
experts have little time, so you want to arrive with specific questions;
you need to check results from interviews or workshops against written policy;
regulations, contracts or standards constrain the solution.

Wiegers and Beatty list document analysis among the main sources for business rules: old specifications, regulations, policies and contracts often contain rules nobody mentions in interviews.

Do not rely on it alone. The BABOK Guide points out that documents may be out of date or wrong, their authors may have left, and the technique mainly describes the current state, not what people need next. Large document sets can also bury you in detail. Pair it with interviews and observation.

How to do it#

Define what you need to learn. Write three to five questions the analysis should answer. This keeps you from reading everything.
Inventory the materials. Ask stakeholders what they use day to day, not just what is official. Record title, version, date, owner and location.
Assess each source. Is it current? Who wrote it and why? Is it used in practice? Mark doubtful sources so findings from them get confirmed.
Read with a purpose. Extract facts, rules, terms, data elements, volumes, roles and pain points. Add new terms to the glossary as you go.
Look for gaps and conflicts between documents, and between documents and what people told you.
Log findings with a precise reference to the source so others can check them.
Turn gaps into questions for interviews or workshops, addressed to a named person.
Confirm key findings with stakeholders before using them as requirements.

Example#

The Workshop (a fictional chain of bike-repair workshops) has no written requirements, but it has plenty of paper. Before interviewing anyone, the analyst collects:

the current booking spreadsheet used at three workshops;
paper job cards filled in by mechanics;
the customer price list and warranty terms;
the contract with the parts supplier;
a folder of customer complaint emails;
the front-desk procedure sheet.

Extract from the findings log:

ID	Source (version, date)	Topic	Finding	Gap or conflict	Question for	Action
`D-03`	Job card form (no version, in use)	Repair status	Card has fields “received”, “in progress”, “done”	No status for “waiting for parts”	Workshop managers	Ask in interview
`D-07`	Warranty terms (2-page leaflet)	Rules	Repairs carry a warranty period	Job card does not record the warranty end date	Owner	Confirm rule; add to data dictionary
`D-11`	Supplier contract	Ordering	Orders placed by a cut-off time ship next day	Workshops order by phone at any time	Parts supplier, managers	Check impact on parts process
`D-14`	Complaint emails	Pain points	Many complaints ask “is my bike ready?”	—	—	Supports notification requirement

The log gives the analyst targeted questions for the first round of interviews, and evidence for the notification feature.

Common mistakes#

Reading everything → start from questions and stop when they are answered.
Treating documents as truth → confirm with people who do the work; procedures often differ from practice.
Losing the trail → record exact source, version and page for every finding.
Copying the old system’s behavior into new requirements → ask whether each behavior is still needed.
Ignoring informal documents (spreadsheets, sticky notes, emails) → they often show the real process.
Not sharing findings → circulate the log; it saves stakeholders from repeating themselves.

Checklist#

The questions the analysis must answer are written down.
Every source has title, version, date and owner recorded.
Each source’s reliability has been assessed.
Findings reference exact locations.
Gaps and conflicts are turned into questions for named people.
New terms are added to the glossary.
Key findings are confirmed with stakeholders.

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.18 “Document Analysis”.
Business analysis training materials (Elicitation and Collaboration module).
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 9 (sources of business rules).
D. Gobov, I. Huchenko. State of Business Analysis in Ukraine 2020. DataArt, 2020.