Eliciting Business Requirements

The Business Analyst as Explorer, Part 2 of 6 by Karl Wiegers

We explore business requirements to gain a shared understanding of the business opportunity being created or exploited, the organization’s business objectives, success criteria, product vision, and project scope boundaries. Business requirements answer the question, “Why are we undertaking this project?”

The project manager has a strong interest in determining the business requirements. Perhaps the first question the project manager and the business analysis must assess for a proposed requirement is whether it’s in scope for the overall project. It’s impossible to make this judgment until the scope has been determined based on the business objectives. If a proposed requirement is out of scope, the PM and BA don’t need to think it about any more. (However, you don’t want to lose sight of the fact that someone once proposed that requirement, because it might come back into scope in the future.) If the requirement is in scope for the project, though, the PM will need to allocate it to a specific release or iteration. These sets of allocated requirements determine the scope for each planned iteration.

If some new requirement request for a particular iteration comes along later, as it inevitably will, the PM must evaluate that requirement’s priority against the backlog of work already allocated to that iteration. Do you defer that new requirement to a later iteration, bump a lower priority allocated requirement to a later iteration, or consciously increase the scope of the iteration by adding the new requirement to it? You can’t just keep cramming more functionality into a planned iteration and expect to get it done on the original schedule. Serious, ongoing prioritization is essential to effective scope management, and it demands clearly defined business requirements. This process requires collaboration between the BA, the PM, and appropriate customer representatives.

Sources of business requirements include senior managers, marketing managers, funding sponsors, product visionaries, and others who know the rationale and business drivers for the project. Such folks might already have established their business requirements, perhaps in a project charter or a business case document. In other situations, though, it can be helpful to have a skilled BA work with the right people to elicit this vital knowledge. Following are some questions to consider asking if you’re a BA working with the holders of the business requirements.

What business problem are you trying to solve? This helps align subsequent requirements development and software development activities with the right objectives.

What’s the motivation for solving this problem? Team members work together more effectively and more enthusiastically if they understand the rationale behind their work.

What would a highly successful solution do for you? Management should be able to state the benefits they and their customers will receive from the product.

How can we judge the success of the solution? People often don’t think about how they will determine whether some enterprise has been successful. Contemplating this evaluation early on helps crystallize the stakeholders’ thinking about objectives and steers the project toward a clearly successful outcome. Project success criteria are the subject of Chapter 4 of my book Practical Project Initiation: A Handbook with Tools (Microsoft Press, 2007).

What’s a successful solution worth? Whenever possible, quantify the business outcomes. All projects involve some cost–benefit analysis. Understanding the potential return in meaningful units helps participants make cost-effective decisions.

Who are the individuals or groups that could influence this project or be influenced by it? This question seeks to identify potential stakeholders in the project. The BA might need to consult these stakeholders to understand their interests in the project, their expectations, and the nature of their involvement. Stakeholders could be internal to the project, internal to the organization, or external to the organization. And you can bet that your stakeholders will have conflicting objectives, requirements, and priorities.

Are there any related projects or systems that could influence this one or that this project could affect? Look for dependencies between projects and systems that need to be analyzed and accommodated. Sometimes apparently small changes can have vast ripple effects across multiple interconnected systems.

Which business activities and events should be included in the solution? Which should not? These questions help define the scope boundary. Modifying the established project scope is a business decision that has implications for cost, schedule, resources, quality, and tradeoff decisions.

Can you think of any unexpected or adverse consequences that the new system could cause? Consider whether certain individuals, organizations, customers, or business processes could experience a negative impact from the system or product being developed. For example, a new information system that automates a process that has been performed manually in the past could threaten the job stability of the people who perform that process. Employees might need retraining, or their job descriptions could change, both of which could lead to resistance to the project and unwillingness to cooperate.

As you gain experience with these sorts of dialogues, you’ll build a set of your own questions that you find helpful to pull out the key information. You might write those kinds of questions down on index cards. When you find that an elicitation discussion is stalling out or nearing an end, randomly pull out one of those cards and see if the question on it has already been addressed. If not, the question just might help you surface another tidbit of knowledge that will help you plan the project and keep it on track.

Don’t forget to leave your comments below.

Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons.

(adapted from More about Software Requirements by Karl Wiegers)