Laying the Foundation of Requirements Engineering
Learn practical skills for how to understand the business problem before converging on a solution, and tips for how to keep the problem in focus with a clear and concise problem statement.
This chapter is from the book
This chapter is from the book
This chapter is from the book
In the classical pure (and hypothetical) waterfall software development model, the team accumulates a complete set of requirements for the product, designs a solution, builds the entire solution, tests it all, and delivers it. We all know that approach doesn’t work well in most cases.
Projects will vary in how much requirements work can, and should, be done up front. Sometimes it’s possible to specify a good portion of the requirements for an information system before getting too far into implementation. Complex products with multiple hardware and software components demand careful requirements engineering because the cost of making late changes is high. For applications that change rapidly or lend themselves to incrementally releasing ever more capable software versions, developing requirements just-in-time in small chunks is an effective approach. Innovative apps may involve a lot of concept exploration, prototyping, feasibility studies, and market assessment.
No single approach to the development life cycle or requirements work optimally fits every situation. However, there are several interconnected activities related to requirements that every team should perform at the beginning. This chapter describes five essential practices that collectively provide a solid foundation for both technical and business success:
Practice #1. Understand the problem before converging on a solution.
Practice #2. Define business objectives.
Practice #3. Define the solution’s boundaries.
Practice #4. Identify and characterize stakeholders.
Practice #5. Identify empowered decision makers.
Practice #1 Understand the problem before converging on a solution.
Imagine that you worked for more than a year on a project that had executive support and high visibility. In your business analyst role, you performed the requirements elicitation, analysis, and specification. The development team built what the stakeholders asked for and deployed the product on schedule. But just three months later, the product is considered a failure and decommissioned. Why? Because it didn’t solve the right problem.
Far too often, teams build and release requirements, features, and even entire products that go unused because those teams didn’t fully understand the business situation and the problems they were trying to solve. Understanding the problems or opportunities that your solution will address aligns all participants on the core issues and provides confidence that the solution will indeed achieve the desired outcomes.
Business Problems
A business problem is any issue that prevents the business from achieving its goals or exploiting an opportunity (Beatty and Chen 2012). A business problem can be small, such as a user complaint that some task takes too long, which can perhaps be solved by streamlining some functionality. Or it can be as large as organization-level business challenges—spending too much money, not making enough money, or losing money—that demand major projects or entirely new products.
Organizations launch initiatives to solve one or more business problems. Each activity gets funded because management expects its business value to outweigh its costs. However, those problems or opportunities often are neither explicitly stated nor documented. Rather than presenting a clear problem statement, the executive sponsor or lead customer might simply tell the team what to build. This can cause the scenario described above: project success but product failure. If you don’t understand the problem adequately, or if you begin with a specific solution in mind, there’s a good chance that the team will solve only part of the problem—or perhaps none of it.
It’s a good idea to avoid presuming that either a presented problem or a presented solution is necessarily correct. That initial presentation might come from a business case, project charter, senior manager, or product visionary. But can you trust it as setting the right direction for all the work that will follow?
When you’re presented with a stated problem, perform a root cause analysis until you’re confident that the real issue and its contributing factors are well understood (Tableau 2022). Then you can derive possible solutions that you know will address those very issues. If you’re presented with a solution, explore this question: “If <solution> is the answer, what was the question?” In other words, ask “Why do you think that’s the right solution?” You might discover that the underlying issue demands a different approach: possibly simpler, possibly more complex, possibly more specific, possibly more general. You won’t know until you perform the analysis.
Eliciting the Real Problems
A stakeholder might request a solution such as “Combine several systems into one,” with the expectation that such a strategy would address multiple, unspecified objectives. However, system consolidation could be overkill if a simpler answer is appropriate. If the problem is that you’re spending too much money on maintenance and support for four existing systems, combining them could be the right approach. However, suppose that the most pressing concern instead is that your users are unhappy. A root cause analysis using the 5 Whys technique with the pertinent stakeholders could sort all this out (Tableau 2022).
Root cause analysis involves working backward from a stated problem or a proposed solution to identify the underlying problems and the factors that contribute to them. Assessing those factors then leads to the appropriate solution choice. With the 5 Whys technique, you ask questions like “Why is that a problem?” or “Why are we not already achieving that goal today?” repeatedly until you unveil the compelling issue that drove launching the initiative in the first place. The conversation between a business analyst and a key stakeholder might go something like this:
Analyst: “You requested that we combine your four current systems into one. Why do we need to combine them?”
Stakeholder: “Because our customers complain that they must keep signing in between webpage clicks. It’s annoying. This is because they’re accessing different backend systems that all have separate user accounts.”
Analyst: “Why is it an issue if your customers are complaining?”
Stakeholder: “According to our market research, 25 percent of our customers have left us for the competition because of their frustrations with usability on our site.”
Analyst: “If that’s the case, why not just implement single sign-on to improve usability?”
Stakeholder: “That would help, but we’d still have to maintain and support all four systems.”
Analyst: “If we combined them, wouldn’t you still need the same number of support people for the new system?”
Stakeholder: “We don’t believe so. The four current systems use different programming languages. We need at least one engineer fluent in each language to support each system, although there’s not enough work to keep them busy. By combining the systems into one using a single language, we could free up the additional engineers to work on other products.”
Analyst: “Ah, so it looks like you’re trying to solve multiple problems. You want higher customer retention, and you also want to reduce support costs and free up staff by using fewer technologies.”
By asking “why” several times in this conversation, the analyst now understands that the stakeholder expects their proposed solution to address two significant concerns. The request to combine several systems into one might indeed be the best long-term strategy. However, an interim solution using single sign-on could appease the disgruntled customers quickly, while the consolidation initiative works on the larger concern of support and maintenance.
A root cause analysis diagram, also called a fishbone or Ishikawa diagram, is a way to show the analysis results. Suppose the BA drills down into the first problem the stakeholder brought up: losing frustrated customers. The BA could apply the 5 Whys technique to determine exactly why the customers are frustrated and then draw a diagram like the one in Figure 2.1. The problem goes at the head of the “fish.” Place the highest-level causes in the boxes on diagonal lines coming off the fish’s backbone. Add contributing causes on the short horizontal lines from each diagonal. Continue the exploration until you reach the ultimate, actionable root causes. Then you can devise one or more solutions to address them.
)
Figure 2.1 A root cause analysis (fishbone or Ishikawa) diagram example shows the factors that contribute to the stated problem.
Once you’ve identified the primary and contributing issues, consider all their implications before committing to a solution. The requested or most apparent solution could be the wrong strategy. On one of Candase’s projects, the problem was that the version of the commercial off-the-shelf (COTS) package the company used was going end-of-life soon and the vendor would no longer support it. After that, any production issue could have cost the company its entire business because it wouldn’t have any vendor assistance. Nor could it currently make its own enhancements to the vendor product. The obvious solution was to upgrade to the latest version of the vendor’s product. However, the company would have had to pay the vendor high service fees to resolve problems and add enhancements. Consequently, the company considered both acquiring a new COTS package from a different vendor and building an in-house replacement as better solutions to both the initial end-of-life concern and the additional issues.
Problem analysis can reveal other, unobvious challenges. You might confront conflicting problems from different stakeholders or be trying to solve multiple, disparate problems with a single fix. As you explore the issues, look for situations where you might need several solutions, rather than seeking a single silver bullet.
Keeping the Business Problem in Focus
When the key stakeholders have agreed upon a clear understanding of the core business concerns, consider writing a problem statement (Kyne 2022). A template like this can be helpful (Compton 2022):
Situation |
Describe the background, context, and environment. |
Problem |
Describe the business problems or opportunities as you now understand them. |
Implication |
Describe the likely results if the problem isn’t solved. |
Benefit |
State the business value of solving the problem. |
Vision |
Describe what the desired future state would look like. |
A concise problem statement serves as the reference point for the rest of the work. It feeds directly into crafting the specific business objectives that management or your customers expect the solution to achieve (see Practice #2, “Define business objectives”). The problem statement also helps the team make decisions throughout the project. When prioritizing requirements, favor those items that are the most critical or timely contributors to solving the highest-value problem (see Practice #13, “Prioritize the requirements”). In the combine-several-systems-into-one example above, implementing single sign-on to relieve customer frustration would be a quicker fix than combining multiple systems and would address the immediate concern of losing customers.
Whenever someone requests a new system capability, ask how it relates to the business problems (see Practice #20, “Manage changes to requirements effectively”). If you can’t tie each new requirement to any of the defined business problems, either there are more problems yet to explore or you don’t need the new requirement.
Stakeholders often will propose a specific deliverable as a requirement: “Build me product X or feature Y.” The stakeholder’s solution may indeed be the correct one—but not necessarily. Take the time to thoroughly understand the real business problem to ensure that the team focuses on achieving the proper outcomes. If your analysis reveals that the real problem doesn’t quite match what you found in a business case or other originating document, revise that document to match the newly understood reality. That insight could profoundly change the project’s direction.
Related Practices
Practice #2. Define business objectives.
Practice #3. Define the solution’s boundaries.
Practice #13. Prioritize the requirements.
Practice #20. Manage changes to requirements effectively.
Next Steps
If you haven’t already done so, talk with project leadership and key stakeholders about why they’re undertaking your initiative to make sure you understand the problem it is intended to solve.
Create a root cause analysis diagram for your core business problem, using a technique like 5 Whys to discover both major and contributing causes.
Write a problem statement using the template described in this section.
Based on the problem or problems identified, assess whether your current solution concept will address them adequately. If not, either change the solution or point out the risk that the current solution may not be sufficient.