Home > Articles

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

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

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):


Describe the background, context, and environment.


Describe the business problems or opportunities as you now understand them.


Describe the likely results if the problem isn’t solved.


State the business value of solving the problem.


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

  1. 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.

  2. Create a root cause analysis diagram for your core business problem, using a technique like 5 Whys to discover both major and contributing causes.

  3. Write a problem statement using the template described in this section.

  4. 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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020