Business Analysis Techniques

Solves:

Vague or superficial business goals without clear causes or actions (e.g. “improve UX”, “increase revenue”).

⚙️ How to use it:

Start with a broad or unclear statement. Ask “Why?” up to 5 times, each time digging deeper into motivations and obstacles.

💡 Example:

❓Need: “We want better customer engagement.”
→ Why? Customers ignore emails.
→ Why? Emails feel irrelevant.
→ Why? No personalization.
→ Why? Data not available to marketing team.
⇒ Functional requirement: “System must provide marketing access to customer purchase history.”

Solves:

Lack of context about who needs the feature and why — or when requirements aren't testable.

⚙️ How to use it:

Write user stories in the format: As a [user], I want [goal], so that [reason]. Then define what must happen for the story to be “done” (acceptance criteria).

💡 Example:

User Story:
As a customer, I want to reset my password, so that I can log in if I forget it.

Acceptance Criteria:
- Reset link is sent via email
- Link is valid for 24 hours
- User must enter new password twice

Solves:

High-level ideas that lump many features together (“Build a portal”, “Automate hiring”) with no actionable pieces.

⚙️ How to use it:

Write the vague goal on a whiteboard. Ask: “What would the user actually do here?” Break it down into concrete user actions or system functions. Repeat decomposition until each piece is actionable and testable.

💡 Example:

Need: “We need a customer portal.”
Breakdown:
- Register account
- Login/logout
- View/edit profile
- Track orders
- Download invoices
Each becomes a separate functional requirement.

Solves:

Ambiguity about system boundaries, who does what, and what interactions exist.

⚙️ How to use it:

Identify the actors (users, external systems). List actions each actor performs with the system. Draw connections — each action is a “use case.” Validate with stakeholders: “Did we miss anything?”

💡 Example:

Use Case: Onboarding System
Actor: HR
Use cases: Create employee profile, Assign laptop, Assign mentor
⇒ Functional requirement: “System must allow HR to input new employee info and assign assets.”

Solves:

Vague expectations like “Make it intuitive”, or stakeholders not knowing what they want until they see it.

⚙️ How to use it:

Sketch UI wireframes or interactive prototypes. Walk the stakeholder through the journey. Observe what they point out or question. Translate comments into functional requirements.

💡 Example:

Prototype: Dashboard with 4 widgets
Stakeholder says: “I want to compare these charts by month.”
⇒ Requirement: “Dashboard must allow users to filter widgets by date range.”

Solves:

Requests with no measurable outcome or testability — like “Improve performance” or “Modernize UX”.

⚙️ How to use it:

Ask: “If this feature was done, what would you see, hear, or do differently?” or “How will we measure success?”

💡 Example:

❓Need: “Improve team collaboration.”
Analyst: “How would we know if it’s improved?”
Stakeholder: “We’d stop using email chains.”
⇒ Functional requirement: “Introduce team chat with thread support and file sharing.”

Solves:

Unclear system behavior in response to real-world events.

⚙️ How to use it:

List business events (e.g., “User submits form”). Ask what must happen in response (emails, data saved, notifications). Each response becomes a requirement.

💡 Example:

Event: “Customer places an order”
Responses:
- Store order in DB
- Reduce inventory count
- Send confirmation email
- Notify shipping team
⇒ Each is a functional requirement.

Solves:

Assumptions about what the system will do — preventing scope creep or misalignment.

⚙️ How to use it:

During requirement sessions, ask: “What will this system not do?” or “What will still be manual?”

💡 Example:

Stakeholder: “We want automatic invoices.”
Analyst: “So no manual invoices ever?”
Stakeholder: “Only for international clients.”
⇒ Requirements:
- Generate invoices automatically for domestic orders
- Allow manual override for international orders

Solves:

Helps prioritize high-impact problems by evaluating them through business-critical lenses (tech, operations, finance). It ensures the product solves problems that are worth solving — not just doable or requested.

⚙️ How to use it:

Ask three sets of questions: Challenging: What makes this problem technically or operationally hard to solve? (Ask the hypothetical CTO.) Important: What non-economic factors make solving this problem essential? (Ask the CPO — Chief Procurement Officer.) Valuable: How exactly does solving this problem increase revenue, reduce cost, or mitigate risk? (Ask the CFO.) Focus on the problem’s nature, pain intensity, and business relevance, not on solution features.

💡 Example:

❓Business request: “Speed up customer onboarding”
Challenging: Manual verification of documents at scale is error-prone and labor-intensive.
Important: Delays in onboarding damage customer trust and reduce engagement.
Valuable: Automating onboarding reduces manual staffing by 40%, accelerating time to revenue.
⇒ Requirements derived:
- System must extract and validate ID data automatically
- Status tracking and reminders must be sent to users during onboarding
- Admin portal must allow verification overrides and audit trail