How to Write Better Requirements: A Practical Guide That Actually Works
Learn how to write clear, testable requirements that prevent project...
BABOK Strategy Analysis: How Business Analysts Define the Right Problem Before Solving It
Listen to this blog
Here is a failure mode that plays out on projects every year: a team gathers requirements diligently, writes them up carefully, gets them approved, and builds a system that functions exactly as specified. Then the project is declared a failure because it did not solve the actual business problem.
This happens because the analysis phase started in the wrong place. The team jumped from a symptom to a solution without understanding the business context, the real drivers of the initiative, or whether the proposed approach was the best way to address the actual need.
Strategy analysis is the BABOK knowledge area that prevents this failure mode. It is concerned with understanding the business environment before requirements are gathered, defining what success actually looks like for the organization, and ensuring that the project is pointed at the right target before significant resources are committed.
Why Strategy Analysis Comes Before Requirements
The goal of strategy analysis is to understand the context within which a project operates: the organization’s goals, capabilities, constraints, and competitive environment. Without this understanding, requirements gathering is a series of conversations without a frame of reference.
If the business analyst begins gathering requirements from the stakeholders before the purpose or basic constraints of the project are determined, it is likely that the end product will be something very different from what the customer expected.
The business analyst who does strategy analysis well can do something that most analysts cannot: they can evaluate requirements against the business objectives that justify the project. When a stakeholder requests a feature that does not align with those objectives, the BA has a principled basis for having that conversation. Without strategy analysis, every stakeholder request has equal standing, and scope management becomes a political battle rather than a strategic discussion.
Analyzing the Current State
Understanding the Business Architecture
Before defining where the business needs to go, the BA must understand where it currently is. This as-is analysis covers the business architecture: what the organization does, how it does it, where it operates, who is involved, what events drive its activities, and why those activities exist.
The Zachman Framework for Enterprise Architecture is one of the most comprehensive models for capturing this understanding. It maps six questions (what, how, where, who, when, and why) against six perspectives (planner, business model, system model, technology model, builder, and subcontractor). Each intersection identifies a specific artifact. For example:
- The why of the business model perspective is the business plan, capturing the organization’s goals and strategies.
- The what of the system model perspective is the logical data model.
- The how of the business model perspective is the business process model.
The framework is powerful because it forces completeness. It is easy to analyze a business from one or two dimensions and miss important context. The Zachman Framework ensures that the BA is considering all six dimensions of the enterprise, not just the ones that are most visible or most familiar.
In practice, the BA does not need to complete every cell of the Zachman Framework for every project. The goal is to use the framework as a checklist to ensure that key aspects of the business context have been considered. For a prescription interaction project at a pharmacy chain, the business model might show that the strategic goal is to become the premier pharmacy, that the mission includes customer safety and efficient purchasing, and that the organization has locations across multiple continents. Each of these facts shapes what requirements are relevant and what trade-offs are acceptable.
Business Rules, Policies, and Competencies
Strategy analysis also requires understanding the operational context in which the solution will function. This means documenting:
- Policies – how the business responds to certain conditions. For example, ‘The company will not accept a prescription unless payment is made or a preapproved drug plan is provided.’
- Procedures – how certain key activities are carried out. For example, the drug interaction verification procedure, or the prescription refill process.
- Business rules – specific constraints on business behavior. For example, ‘A pharmacist must check for drug interactions before filling a prescription.’
- Competencies – what the business should be capable of doing, including competitive advantages. For example, ‘Ability to refill prescriptions from any location in the network.’
These are not requirements themselves. The system does not have to enforce all business rules directly. But they provide essential context that determines what requirements need to be gathered. The business rule about checking for drug interactions triggers a set of questions: Should this check be automated? What information does the pharmacist need to make the decision? What action should follow a positive finding? Each of these questions leads to specific requirements.
Defining the Future State
Business Goals and Objectives
Every project needs to answer the why question. Why is this project being done? What will be different about the business when it succeeds? Business goals and objectives translate strategic direction into project-level terms.
Goals and objectives should be specific enough to be evaluable. ‘Improve customer service’ is not a goal. ‘Reduce drug-interaction-related lawsuits by 75 percent over three years’ is a goal. It is specific, measurable, and connects directly to a business problem that is costing the organization money.
All project objectives should trace back to a specific business need. This traceability is what enables the BA to evaluate requirements for strategic relevance and to challenge additions that do not connect to the project’s stated objectives.
Scope Definition
System scope is like a hole, perhaps defined by what it is not, rather than what it is. Defining scope well means being explicit about both inclusions and exclusions.
The scope statement should address:
- Business goals and objectives – why this project exists and what it must accomplish
- Assumptions – educated guesses made because the correct answer is not yet known. All assumptions carry risk. They must be documented and agreed upon by key stakeholders.
- Constraints – limitations that define the box within which the project operates. Common constraints include existing infrastructure, preferred vendor lists, and regulatory requirements.
- Impacted organizations – all organizations, systems, and external entities that will interact with the solution. This is the start of the communication plan and the stakeholder list.
The Context Diagram
The context diagram, sometimes called the level 0 data flow diagram, is one of the most effective tools for defining and communicating scope. It consists of three elements: the scope area at the center, external entities (people, organizations, or systems that interact with the scope area) as rectangles, and data flows as labeled arrows between them.
Creating the context diagram is an activity that should be done with the customer, not for them. The visual representation serves as a catalyst for stakeholders to identify interfaces and data flows they had not initially mentioned. It also communicates the complexity of the technical environment to customers who may not realize how many systems their business relies on.
A well-completed context diagram often leads to one of the most valuable conversations in the project: the realization that system interfaces may represent the majority of the project’s budget. When customers see all the systems that must share data or exchange transactions with the new solution, they frequently revise their estimates of how simple the project will be. This is far better to discover during strategy analysis than during implementation.
Feasibility Studies
Before a project is authorized, there must be a business case made for why the organization should invest in it. The feasibility study informs that business case by answering a specific question: is this approach actually achievable given the organization’s current situation?
A feasibility study is a project in itself. It should have requirements, deliverables, and a project plan. The more precisely the initial question is defined, the better the study will be executed. ‘Is this feasible?’ is not a precise enough question. ‘Is it feasible to develop a drug interaction checking system that integrates with all existing pharmacy network locations within 18 months using our current infrastructure?’ is a question that can actually be researched and answered.
The key steps in a feasibility study are:
- Identify the problem or opportunity – understand why this effort is being undertaken. Is it to gain competitive advantage, comply with new regulation, or respond to a quality problem? The driver shapes what areas need the most careful examination.
- Understand the current situation – assess what capabilities and infrastructure already exist. Are there partial solutions already in place? What is the competitive situation? This answers ‘Where are we?’
- Define a vision of the solution – without yet getting bogged down in constraints, define what the world will look like when the problem is solved or the opportunity realized. This answers ‘Where do we want to be?’
- Determine alternative solutions – be creative. If the first idea that surfaces gets selected without evaluation, someone will think of a better way later, which causes expensive rework. Alternatives also help in confidently rejecting options that have been considered and found wanting.
- Recommend a solution – evaluate the alternatives and select the one that best addresses the business problem, with an honest assessment of the risks and trade-offs involved in each option.
The options available to any project team are more varied than is usually recognized. Change the business process without automation. Enhance the existing system. Write a new solution in-house. Outsource the development. Buy a commercial package. Do nothing and accept the consequences. Each option has a different risk profile, cost, and timeline. The feasibility study’s job is to evaluate these options with enough rigor that the decision makers can choose with confidence.
The Business Case
The business case makes the financial and strategic argument for the chosen solution. It is the formal justification for investing organizational resources in a project.
A good business case includes both quantitative and qualitative factors. Quantitative factors include costs, benefits, timing of each, return on investment, net present value, and internal rate of return. Qualitative factors include strategic alignment, competitive positioning, employee satisfaction, and reputation. The combination tells the full story of what the organization will gain and what it will spend.
A very good project manager who does not understand the business goals can very effectively deliver the wrong product.
Business analysts are not typically responsible for writing the business case, but they are often key contributors. They can identify business areas that will be impacted by the solution, estimate analysis phase costs, identify risks that affect the cost and benefit assumptions, and flag benefit categories that might otherwise be overlooked, including reduced staff turnover, improved job satisfaction, or global market access.
One of the most common mistakes in business cases is being too narrow in defining both costs and benefits. Job satisfaction improvements and reduced training overhead are large benefits that are routinely overlooked. Maintenance costs, training costs, and staff turnover during system transitions are costs that are routinely underestimated. The BA who has done thorough strategy analysis is in the best position to identify these overlooked items.
The business case must also be honest about confidence levels. Some cost estimates will be based on solid data. Others will be educated guesses. Decision makers deserve to know which is which. If all the costs are solid and all the benefits are guesses, this is a high-risk investment, and that should be visible in the business case.
Connecting Strategy Analysis to Requirements Management
Strategy analysis does not exist in isolation from the rest of the requirements process. It is the foundation that makes everything else coherent. When requirements are gathered without strategy analysis, each requirement has equal standing, and there is no principled basis for prioritization, scope decisions, or trade-offs.
When strategy analysis is done well, every requirement can be evaluated against the business objectives that justify the project. A new feature request can be assessed for strategic alignment. A scope reduction can be evaluated for impact on business goals. A design decision can be traced back to the feasibility assessment that shaped it.
Modern Requirements supports this connection directly. Traceability from business objectives through requirements to design and test artifacts means the strategic context captured during strategy analysis does not get lost as the project moves into development. When requirements are linked to the business goals they support, any change to either can automatically flag the connection as needing review, keeping the project aligned with its strategic purpose throughout the development lifecycle.
Table des matières
Articles récents
EU MDR (2017/745) Compliance Automation for Technical Documentation & Traceability
Automate EU MDR technical documentation and GSPR traceability for medical...
Audit-Ready DevSecOps for Financial Services: Building Compliance Into Every Release
Learn how banks, insurers, and fintechs build audit-ready DevSecOps that...
