Effective Analysis Phases and Outputs

Previously, we adopted the practice not to make a difference between business analysis and system analysis explicitly and started to use the term “analysis” for all analytical activities, from discovering business goals and objectives to selecting and designing the concrete solution. The reason behind it is to emphasize that all analytical activities are related to each other and require similar skills. Also, calling everything analysis is a convenient simplification.

Irrespective of this practice, analysis is not a single activity. It consists of various components where each of them focuses on exploring different aspects of the problem. The whole process of analyzing a problem resembles peeling an onion, going from top to bottom, continuously uncovering more and more details. The critical remark is that this onion-like approach is a general analysis principle that is valid no matter what analysis, software development, or project approach is selected. It does not matter whether the complete analysis is done upfront or if small increments are analyzed just in time when it is needed for development, it always starts with general facts and goes deeper into detail. Even though each analysis is different, uses different techniques producing a different set of artifacts, each analysis must go through the same phases. The basic analysis layers are always the same, and as well as the way their outputs are documented. What varies is the particular timing and the concrete form of the produced outputs, which both depend on the selected process.

In this chapter, we would like to present typical analysis phases and outputs that are typically created to document their results. Although the phases are presented in linear order, please note that this is just for simplicity’s sake. In reality, the order is not guaranteed, and the phases also usually overlap. For example, during solution analysis, potential changes to the future state may be uncovered, so despite the future state description logically precedes the solution specification, it can be revised even after the solution analysis was done. The analysis is performed iteratively, meaning that some parts are done/revised multiple times.

We are living in an agile time when the trend is to do ad-hoc things, not to prepare much in advance and iterate instead of plan. No matter how beneficial it is to be agile, forewarned is forearmed, so before diving into the depths of analysis, it is always better to have a plan and set up an analysis approach. Especially big projects that engage many analysts should think before acting and should create at least a basic outline of who will be involved in analysis and how the analysis will proceed. It includes initial identification of the key stakeholders, a list of analysis activities (and their timing), and the way the communication and collaboration will be done.

The first step is to understand why the change has been initiated, what is the underlying business need. It must be clear why we are doing the whole thing, what the company is trying to solve.

To understand the context in which the business need exists, it is also important to know the current state/as-is of the relevant parts of the enterprise (structure, resources, capabilities, and technology). It helps understand the environment in which the change is supposed to be implemented.

Once it is clear what is the business need and what is its current context, the next step is to define more concrete business goals that represent a state or condition that an organization is seeking to establish to meet the need. Together with the related constraints, assumptions, dependencies, and risks, business goals form a future state/to-be. The future state also defines what parts of the enterprise need to change (structure, resources, capabilities, and technology) in order to meet the business goals.

Sometimes the future state could be achieved using the already existing organization capabilities, but mostly the business need arises because the organization lacks a tool that would solve it. Therefore, the analyst performs a gap analysis to identify the required enterprise change to get to the future state. The result of the gap analysis forms the foundation for identifying possible solutions. For example, if the business goal is to implement OCR for automatic invoice reading, there are two possible solutions: to buy some existing OCR or implement it in-house.
As soon as the final solution is selected, it is outlined in the solution description. The solution could consist of multiple organizational components changes, but in this case, the only change is the new software.

The final step is implementing the solution, which requires describing each solution component in sufficient detail. In the case of software, it is usually some form of a functional *specification documenting the technical aspects of the system.

Outputs

Each analysis phase presented in the previous section produces some results. The form they are captured and stored is highly dependent on the software development approach, and the organization itself may also order it. For this reason, Effective Analysis does not present any specific templates analysts should use, but only provides an overview of information which, regardless of the analysis approach, are worth documenting during or after each analysis phase. Please note that we are talking about documenting information, not about putting it into documents. The goal of the analysis is not to create a document, but to provide enough information needed to find and implement the solution. If Effective Analysis talks about the document, it means a container of related information. The document is just one of the possible representations of information. While it is possible to store all information primarily in Word documents, it might as well be stored in a database, for example.

The following schema depicts how the initial idea is elaborated from the high-level business need down to the detailed description of each system function and shows what information containers are typically created to capture information discovered during each phase:

Many of you have probably heard about some of the documents shown above. And many of you have also tried to find out what information each document should include. The bad news is, there is no agreement as to which document should contain which information and to what extent of detail. It is not even clear how to call the documents, which is why we present some of them under multiple names. Each organization and even each team calls the artifacts differently, and regardless of the name, they put various types of information into it. Our goal is not to dictate what documentation organizations should create or how they should call their analytical outputs. We only want to make sure that there is a common understanding of what results a proper analysis should produce.

But is it needed to create multiple documents in the first place? And why do we need to document high-level business requirements when we already know what features the system should have? The question is not how many documents to produce, but how to logically structure information. The main reason is that analysts target multiple audiences at the same time. Some stakeholders are only interested in the business goals and the outcome of the whole activity. Other stakeholders will need to review just the design or just how the security is going to be done. The goal is, therefore, to put the information of the same type together, and it does not matter if it will be achieved by creating multiple documents or multiple sections within a single big specification.