Requirements Engineering
From elicitation to validation — the complete BA toolkit based on BABOK and industry best practices.
What Does a BA Do?
According to BABOK (Business Analysis Body of Knowledge), business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders.
A Business Analyst:
BA vs SA vs PM
| Role | Focus |
|---|---|
| Business Analyst (BA) | WHAT needs to be built and WHY |
| Systems Analyst (SA) | HOW systems interact and are structured |
| Project Manager (PM) | WHEN, WHO, and how much it costs |
In practice these roles overlap, especially in smaller teams.
Key BA Deliverables
- Business Requirements Document (BRD): high-level statement of business needs
- Software Requirements Specification (SRS): detailed functional/non-functional requirements
- User Stories: lightweight requirements in the format "As a [persona], I want [action], so that [benefit]"
- Use Case Diagrams: visual representation of actor-system interactions
- Process Models: BPMN diagrams showing current and target business processes
- Data Models: ER diagrams, data dictionaries
- Acceptance Criteria: conditions that must be met for a feature to be accepted
The BA Knowledge Areas (BABOK v3)
1. Business Analysis Planning and Monitoring 2. Elicitation and Collaboration 3. Requirements Life Cycle Management 4. Strategy Analysis 5. Requirements Analysis and Design Definition 6. Solution Evaluation
Situation
A fintech startup is building a mobile lending app. The product team has vague requirements: "We need to give people loans from their phones, fast."
What the BA Does
### Step 1: Understand the Business Context
Asks stakeholders:
Discovers: the company targets young professionals (22-35), loans of €500-€5000, disbursement within 15 minutes of approval.
### Step 2: Elicit User Needs
Conducts 8 user interviews and 2 focus groups. Key findings:
### Step 3: Document Requirements
Business Requirement: The system shall disburse approved loans to the customer's bank account within 15 minutes during business hours.
User Story: As a loan applicant, I want to receive a loan decision within 60 seconds of submitting my application, so that I can immediately know if I can proceed with my planned purchase.
Acceptance Criteria:
### Step 4: Validate with Stakeholders
Runs a structured walkthrough. Compliance officer flags: rejection reasons must comply with GDPR Article 22 (automated decision-making). BA updates AC to include human review option.
What is Elicitation?
Elicitation is the process of drawing out information from stakeholders. Requirements rarely exist in a fully articulated form — they must be discovered, surfaced, and clarified.
1. Interviews
Best for: understanding individual perspectives, sensitive topics, complex processes.
- One-on-one or small group (2-3 people max)
- Use open-ended questions: "Tell me about your typical day when processing a loan application."
- Follow up with: "Can you give me an example of when that went wrong?"
- Document: record with permission, or take structured notes
Risk: Interviewees tell you what they think you want to hear.
2. Workshops (JAD/RAD Sessions)
Best for: gaining consensus, resolving conflicts, complex cross-functional processes.
- Joint Application Design (JAD): structured sessions with business + IT
- Bring all key stakeholders together
- Use facilitator techniques: affinity mapping, dot voting, fishbone diagrams
Risk: Dominant personalities silence quieter stakeholders.
3. Observation (Ethnographic Study)
Best for: understanding actual vs. stated processes, discovering tacit knowledge.
- Shadow users as they do their real work
- Silent observation vs. concurrent think-aloud
- Often reveals undocumented workarounds and pain points
4. Document Analysis
Best for: understanding existing systems, regulations, and processes.
- Analyze existing manuals, reports, system outputs, contracts
- Identify implicit requirements embedded in current system behavior
5. Surveys and Questionnaires
Best for: large groups, quantitative data, validating assumptions.
- Closed questions for statistics; open questions for insights
- Response rate challenge — keep surveys under 10 minutes
6. Prototyping
Best for: validating understanding, eliciting requirements that are hard to articulate.
- Paper prototypes (wireframes) or clickable mockups
- Stakeholders react to something concrete rather than abstract descriptions
- "Show, don't tell" principle
User Story Format
A user story describes a feature from the user's perspective:
"As a [persona], I want [action/goal], so that [benefit/value]."
Examples:
INVEST Criteria (good user stories are...)
- Independent: can be developed and tested without dependencies on other stories
- Negotiable: the solution is flexible; the goal is fixed
- Valuable: delivers value to user or business
- Estimable: team can estimate the effort
- Small: completable within one sprint
- Testable: clear acceptance criteria exist
Acceptance Criteria Formats
### Scenario-based (Gherkin / BDD)
Given [initial context] When [event or action] Then [expected outcome]
Example: ``` Given the user has submitted a loan application When the credit check is completed Then the user receives a push notification with the decision within 60 seconds And the decision status is visible in the app ```
### Rule-based
- The report must contain at least: date range, total revenue, breakdown by category
- The system must support up to 10,000 concurrent users
- Passwords must be at least 12 characters and contain a digit and symbol
Epic → Feature → User Story → Task
Epic: Loan Application
Feature: Application Form
Story: Basic Info step (name, DOB, address)
Story: Financial Info step (income, employment)
Story: Document Upload step (ID, payslips)
Feature: Credit Decision
Story: Real-time credit score fetch
Story: Decision notification