Effective Analysis Phases and Outputs

Previously, we adopted the practice of not making an explicit distinction between business analysis and systems analysis, using the term "analysis" for all analytical activities—from discovering business goals and objectives to selecting and designing a concrete solution[cite: 26]. The reason behind this is to emphasize that all analytical activities are interconnected and require similar skills[cite: 26]. Additionally, calling everything analysis serves as a convenient simplification[cite: 26].

Regardless of this practice, analysis is not a single activity[cite: 26]. It consists of various components, each focusing on exploring different aspects of a problem[cite: 26]. The entire process of analyzing a problem resembles peeling an onion, moving from top to bottom while continuously uncovering more detail[cite: 26]. Crucially, this onion-like approach is a general analysis principle that remains valid no matter what analysis, software development, or project methodology is selected[cite: 26]. It does not matter whether the complete analysis is done upfront or if small increments are analyzed just-in-time when needed for development; the process always starts with general facts and moves deeper into detail[cite: 26]. Even though every analysis is different, utilizing different techniques and producing a different set of artifacts, each must progress through the same phases[cite: 26]. The foundational analysis layers remain the same, as does the way their outputs are documented[cite: 26]. What varies is the timing and the specific form of the produced outputs, both of which depend on the selected development process[cite: 26].

In this chapter, we present the typical analysis phases and the outputs created to document their results[cite: 26]. Although these phases are presented in a linear order, please note that this is purely for the sake of simplicity[cite: 26]. In reality, this linear order is not guaranteed, and the phases usually overlap[cite: 26]. For example, during solution analysis, potential changes to the future state may be uncovered[cite: 26]. So, despite the future state description logically preceding the solution specification, it can be revised even after the solution analysis has been completed[cite: 26]. Analysis is performed iteratively, meaning that certain parts are revisited and revised multiple times[cite: 26].

We are living in an agile era where the trend is to act ad-hoc, minimize advance preparation, and iterate instead of planning[cite: 26]. No matter how beneficial it is to be agile, being forewarned is forearmed[cite: 26]. Therefore, before diving into the depths of analysis, it is always better to have a plan and establish an analysis approach[cite: 26]. Large projects that engage multiple analysts, in particular, should think before acting and create at least a basic outline of who will be involved and how the analysis will proceed[cite: 26]. This includes the initial identification of key stakeholders, a list of analysis activities with their timing, and a definition of how communication and collaboration will be handled[cite: 26].

The first step is to understand why a change has been initiated—the underlying business need[cite: 26]. It must be entirely clear why we are undertaking the effort and what problem the company is trying to solve[cite: 26].

To understand the context surrounding this business need, it is also important to map the current state (as-is) of the relevant parts of the enterprise, including its structure, resources, capabilities, and technology[cite: 26]. This helps the team understand the environment in which the change will be implemented[cite: 26].

Once the business need and its current context are clear, the next step is to define concrete business goals[cite: 26]. These represent the state or condition that an organization seeks to establish to meet that need[cite: 26]. Together with related constraints, assumptions, dependencies, and risks, these goals form the future state (to-be)[cite: 26]. The future state also defines which parts of the enterprise need to change—whether in structure, resources, capabilities, or technology—to meet those business goals[cite: 26].

Sometimes the future state can be achieved using existing organizational capabilities, but more often, a business need arises because the organization lacks the specific tools to solve it[cite: 26]. Therefore, the analyst performs a gap analysis to identify the changes required to reach the future state[cite: 26]. The results of this gap analysis form the foundation for identifying possible solutions[cite: 26]. For example, if the business goal is to implement OCR for automatic invoice reading, there are two main possibilities: purchasing an existing OCR product or developing a solution in-house[cite: 26]. As soon as the final option is selected, it is outlined in a solution description[cite: 26]. While a solution can span multiple organizational components, in this context, the primary focus is often the new software[cite: 26].

The final step is implementing the solution, which requires describing each component in sufficient detail[cite: 26]. In the case of software, this typically takes the form of a functional specification documenting the technical and behavioral aspects of the system[cite: 26].

Outputs

Each analysis phase presented in the previous section produces distinct results[cite: 26]. The form in which they are captured and stored depends heavily on the software development approach and organizational standards[cite: 26]. For this reason, Effective Analysis does not prescribe specific templates[cite: 26]. Instead, it provides an overview of the information that is worth documenting during or after each phase, regardless of the methodology used[cite: 26].

Please note that we are talking about documenting information, not about compiling documents[cite: 26]. The goal of analysis is not to create a document, but to provide the clear information needed to identify and implement a solution[cite: 26]. Whenever Effective Analysis references a "document," it means a logical container for related information[cite: 26]. A document is merely one way to represent information[cite: 26]. While it is possible to store all information primarily in Word files, it could just as easily be managed in a database[cite: 26].

The following diagram illustrates how an initial idea is elaborated from a high-level business need down to the detailed description of each system function[cite: 26]. It shows the information containers typically created to capture the insights discovered during each phase:

Many of you have likely encountered some of the documents shown above, and many have tried to determine exactly what information each should include[cite: 26]. The reality is that there is no universal agreement on which document should contain which information, or to what level of detail[cite: 26]. Even the terminology is inconsistent, which is why we present some of these containers under multiple names[cite: 26]. Each organization and team labels these artifacts differently and populates them with varying types of information[cite: 26]. Our goal is not to dictate what documentation you should create or what you should call your analytical outputs[cite: 26]. We simply want to ensure a common understanding of the results a proper analysis should produce[cite: 26].

But is it actually necessary to create multiple documents in the first place[cite: 26]? And why do we need to document high-level business requirements when we already know what features the system should have[cite: 26]? The real question is not how many documents to produce, but how to logically structure the information[cite: 26]. The primary reason for structuring it is that analysts target multiple audiences simultaneously[cite: 26]. Some stakeholders are only interested in the high-level business goals and the overall outcome of the initiative[cite: 26]. Others need to review the core architecture design or specific security implementations[cite: 26]. The goal, therefore, is to group information of the same type together[cite: 26]. It matters very little whether this is achieved by creating multiple separate documents or by organizing distinct sections within a single master specification[cite: 26].