Business Analysis Best Practices: Stop Solving Too Early

The short answer

Good business analysis does five things. It states the need before discussing solutions, it identifies who is affected, it gathers information from more than one source, it writes requirements that someone can check, and it records why decisions were made.

Everything else is a technique in service of those five. If you are short on time, put effort into the first one. A wrong need produces a well-documented wrong answer.

Start with the need, not the solution

The International Institute of Business Analysis (IIBA) defines six core concepts: change, need, solution, stakeholder, value and context. On its core concept model page, a need is “a problem or opportunity to be addressed” and a solution is “a specific way of satisfying one or more needs in a context.” The order matters. A solution is judged against a need, so the need comes first.

An IIBA article on needs and solutions adds a useful point: the same thing can be a need to one stakeholder and a solution to another. So state the need from a specific point of view, such as “customers wait too long for an answer” and not “we need a chatbot.”

Good habits here: write the problem in one or two sentences, name who has it, say how you will know it is solved, and ask “why” until the answer points to a cause and not another request.

Know your stakeholders

A stakeholder is anyone with a relationship to the change, the need or the solution. That includes people who use the result, people whose work changes, people who pay, people who approve and people who maintain it.

• List them early and ask each interviewee who else you should talk to.
• Note their interest and influence. A simple grid of high or low on each helps decide how much time to spend.
• Include the quiet groups. Front-line staff, support teams and customers are often missed in favor of managers.
• Identify the decision maker for requirements disputes before disputes happen.

Our guides to the business analyst job description and business analyst skills cover how this fits the role day to day.

Elicit with more than meetings

Meetings are the default way to gather requirements, and the weakest on their own. People forget, defer to the loudest voice or describe how work should happen instead of how it does.

Use at least two methods for anything important. A common pattern is data first (what happens), observation second (why), then a workshop to agree what to change.

In interviews, prepare questions, ask open ones first, and repeat back what you heard. Ask for examples of the last time the problem happened, because specifics are more reliable than generalities.

Write requirements that can be tested

A requirement is useful only if two people would agree on whether it has been met. Vague words such as “fast,” “user-friendly” and “flexible” cause disputes later.

The numbers in the stronger column are examples. Real values should come from stakeholders and data.

Other habits help:

• One idea per requirement. If it contains “and,” it may be two.
• Separate the need, the requirement and the design. The requirement says what must be true. The design says how.
• State acceptance criteria. A short list of conditions that show the requirement is met.
• Record assumptions and constraints separately, with an owner for each assumption.
• Add a priority and the reason for it, agreed with the people who pay for the work.

For the project side of this, see our guide to requirements management.

Check, trace and manage change

• Validate with the people who will use it. Walk through scenarios, not only a list of statements.
• Verify quality. Check for gaps, conflicts, duplicates and unclear wording before development starts.
• Trace each requirement back to a need and forward to a test or deliverable. A simple table is enough.
• Control change. Log each change, note its effect on cost and time, and record who approved it.
• Keep a decision log. A line each for what was decided, why, who decided and when. It saves arguments months later.

Use SWOT and similar tools to support a decision

SWOT analysis sorts what you know about a situation into four groups. Strengths and weaknesses are internal: things about your organization, team or product. Opportunities and threats are external: things in the market, the law or the environment.

SWOT is easy to run and easy to run badly. A list of vague bullets (“good team,” “strong brand”) does not help anyone decide. A few habits make it useful:

• Be specific and evidence-based. “Order errors are 4% of shipments” beats “poor quality.”
• Tie it to one decision. SWOT for “the company” is vague. SWOT for “should we launch a customer portal this year?” is usable.
• Get several viewpoints. One person’s strength may be another’s weakness.
• Move from list to action. Ask how strengths can seize opportunities, how weaknesses leave you open to threats, and what to do about each. The pairing approach is often called TOWS.
• Rank. Pick the few items that most affect the decision.

SWOT also has limits. It is a snapshot, it does not weight items, and it can hide disagreement. Treat it as a way to organize thinking before a proper comparison of options, as in the next section.

A made-up scoring example

The numbers are invented. A company has a SWOT for a customer-service problem and three options: A improve the current manual process, B build a self-service portal, and C outsource the service desk. The team scores each option from 1 (poor) to 5 (strong) on four criteria. A higher score is always better, so cost is scored as 5 for cheapest and risk as 5 for lowest risk.

First weights: cost 30, benefit 30, risk 25, speed 15 (total 100).

For option A: (5 × 30 + 2 × 30 + 5 × 25 + 4 × 15) ÷ 100 = (150 + 60 + 125 + 60) ÷ 100 = 3.95. The other rows work the same way.

Now suppose leadership says benefit matters most and cost less: cost 15, benefit 45, risk 25, speed 15 (still 100). The scores become A 3.50, B 3.85 and C 3.15. The ranking flips and the portal wins.

That is the point of the exercise. The scoring does not decide for you. It shows which assumption the decision depends on, so you can take that question to the sponsor: “How much more is the benefit worth than the cost?” Always show the weights, and test at least one alternative set.

Communicate for the reader

• Lead with the decision or ask. Put what you need from the reader in the first lines.
• Use the reader’s words. Business terms for business readers, technical terms for the technical team, and a glossary for both.
• Use pictures where they help. A process map or a simple context diagram often removes pages of text.
• Separate facts, assumptions and opinions. Label them.
• Keep documents short enough to be read. If a reader must skim, put the key points on page one.

Common mistakes

• Jumping to a solution. The most common one, and the costliest.
• Treating the loudest stakeholder as the only one.
• Writing requirements nobody can test.
• Gold-plating. Adding features no one asked for.
• Skipping the decision log. Then no one remembers why.
• Using one big sign-off. Review in pieces so problems show up early.
• Hiding uncertainty. If an estimate or a finding is shaky, say so.

Learn more

If you want structured study of the practices above, online providers such as Coursera and Udemy list business analysis courses. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. Check the syllabus for practice with requirements writing and stakeholder work. For the career side, see our guides to the business analyst career and business analyst vs. system analyst, or compare programs such as the certificate in business analysis.

Frequently asked questions

What are business analysis best practices?

Widely used habits: define the need before the solution, identify stakeholders, use several ways to gather information, write testable requirements, trace and control change, and record decisions.

What is the first step in business analysis?

Understand the problem or opportunity and who is affected by it. A common practice is to write the need in one or two sentences before discussing solutions.

What is the difference between a need and a requirement?

A need is a problem or opportunity. A requirement is a usable representation of a need, stated so it can be checked. The IIBA describes a requirement in those terms.

How do you write a good requirement?

State one thing, in measurable terms, with acceptance criteria and a priority. Avoid vague words and describe what must be true, not how to build it.

What is SWOT analysis used for in business analysis?

To organize what is known about internal strengths and weaknesses and external opportunities and threats, usually before choosing among options. It works best when tied to a specific decision and backed by evidence.

What is the difference between SWOT and a scoring matrix?

SWOT sorts information. A scoring matrix compares options against weighted criteria. Many analysts use SWOT first and a matrix second.

What is requirements traceability?

Linking each requirement back to the need it serves and forward to the design, test or deliverable that satisfies it, so you can see the effect of a change.