The BA technique of document analysis can be undertaken in many different contexts and phases of the effort. The major contexts for document analysis are:
- Manuals, specifications, and contracts can be reviewed as part of the discovery process to learn how existing processes (in-house and those of competitors) work, including the behavior of machines and third-party or external or other black box processes, or how new processes may work.
- The details of existing and generated processed documents can be examined to understand the information they contain to identify appropriate means of classification and identify fields and values that are currently used and may be used in the future.
- Historical records can be reviewed to help quantify the scope, scale, and parameters governing existing operations in the data collection phase. That data can provide information on trends, problems, and opportunities.
- Existing organizational policy documents can be read to understand how decisions are made within existing processes.
- Existing and envisaged statutes and regulations can be researched to understand what requirements may affect or drive processes.
I describe many other kinds of documents here.
Determinations must me made on the authenticity, authority, completeness, and accuracy of documents. Documents should also be reviewed to identify ways to spot errors, omissions, and inconsistencies, as part of deciding whether any given document may be usable. This can apply to all types of documents and contexts listed above.
Here is how documents tend to be analyzed in different phases of an engagement.
Intended Use (Problem Definition): The need to process existing documents, modify existing documents, or generate new documents, is recognized or identified as the driving force or major component of any new effort. This would typically involve identifying high-level operations that would need to be performed on documents rather than considering low-level details of new or existing documents.
Conceptual Model: If an engagement involves figuring out what is going on currently (to accurately and completely define the As-Is state), then document analysis takes place in many different contexts during this phase. If the engagement is intended to create something entirely new, then these activities may be divided across the Requirements and Design phases.
Requirements: Requirements are driven by business needs and descriptions of the existing and future processes. All of the document types described at the beginning of this article are germane in every context.
Design: Once the requirements are understood, bearing in mind that many phases may continue to evolve iteratively, the work of design tends to focus on lower-level details of the documents being processed or generated, along with the documents that describe aspects or operations of the process itself.
Implementation: Document analysis does not typically take place in this phase, except as questions arising from this work may drive revisitation of work done in previous or subsequent phases.
Test (and Deployment and Acceptance): This phase mostly involves review of generated documents to ensure they contain the correct information in the correct format, and also review of processed (input) documents to ensure they are read properly and that the desired information was gathered, the proper decisions were made, and their disposition was properly determined.