User Stories
Short, simple descriptions of a feature from the user's perspective
What It Is
A user story is a brief, informal description of a feature told from the perspective of the person using it. It focuses on the "who," "what," and "why" rather than technical details. User stories are the foundation of Agile development and drive sprint planning.
Agile/Scrum projects, backlog refinement, sprint planning, development sprints
Standard Format
So that [business value/benefit].
Real Example
Context: Building an e-commerce website
I want to save items to a wishlist,
So that I can review them later before purchasing.
- Keep stories small enough to complete in one sprint (2-5 days)
- Add "Acceptance Criteria" to clarify what "done" looks like
- Use simple, non-technical language
- Focus on user value, not implementation details
Acceptance Criteria Example
For the wishlist story above:
✓ Item appears in user's wishlist immediately
✓ User can view their wishlist at any time
✓ User can remove items from wishlist
✓ Wishlist persists even if user logs out
BA's Role
- Gather user needs through interviews and research
- Write clear, concise user stories
- Define acceptance criteria with the team
- Prioritize stories in the backlog
- Answer clarification questions during development
- Validate completed stories against acceptance criteria
Use Cases
Detailed scenarios showing how users interact with a system
What It Is
A use case is a detailed, step-by-step description of how a user (actor) interacts with a system to accomplish a goal. Use cases show both the "happy path" (everything goes right) and alternative scenarios (what happens when things go wrong).
Waterfall projects, complex business processes, system design, stakeholder communication, test planning
Key Components
- Actor: The user or external system
- Preconditions: What must be true before the use case starts
- Main Flow: The successful path (step-by-step)
- Alternative Flows: What happens if something goes wrong
- Postconditions: The state after the use case completes
Real Example
Context: Bank ATM system
Preconditions: Customer has valid ATM card; ATM has cash
Main Flow (Happy Path):
1. Customer inserts ATM card
2. System validates card
3. Customer enters PIN
4. System verifies PIN is correct
5. Customer selects "Withdraw Cash"
6. Customer enters amount ($100)
7. System verifies sufficient balance
8. System dispenses cash
9. System returns card
10. Transaction complete; customer leaves
Alternative Flow (Insufficient Funds):
At step 7: If customer doesn't have enough balance:
7a. System displays "Insufficient funds" error
7b. System prompts customer to enter different amount
7c. Return to step 6
BA's Role
- Identify all actors and their interactions with the system
- Document the main success scenario in detail
- Identify and document alternative/error scenarios
- Validate use cases with stakeholders and developers
- Use use cases as basis for test plan development
- Ensure complete system coverage across all use cases
Requirements Document
Comprehensive specification of what the system must do
What It Is
A requirements document is a formal specification that details all functional and non-functional requirements for a system. It serves as the contract between business stakeholders and development teams, defining what will be built and how it will behave.
Waterfall/traditional projects, complex systems, formal contracts, regulatory compliance, traceability requirements
Typical Sections
- Executive Summary: High-level overview and business goals
- Functional Requirements: What the system must do
- Non-Functional Requirements: Performance, security, scalability
- User Requirements: User roles and permissions
- System Requirements: Technical specifications
- Constraints: Limitations and dependencies
- Assumptions: What we're assuming is true
Requirements Matrix Example
Context: New customer portal for a bank
| Req ID | Requirement | Type | Priority | Status |
|---|---|---|---|---|
| FR-001 | User must be able to log in with username/password | Functional | High | Complete |
| FR-002 | User must be able to view account balance | Functional | High | Complete |
| FR-003 | User must be able to transfer funds between accounts | Functional | High | In Progress |
| NFR-001 | System must load account page in less than 2 seconds | Non-Functional | Medium | Testing |
| NFR-002 | All transactions must be encrypted with SSL/TLS | Non-Functional | High | Complete |
Sample Requirement Write-up
Requirements:
• User must select source and destination accounts
• User must enter transfer amount
• System must validate sufficient balance exists
• System must display confirmation screen
• User must confirm transfer
• System must process transfer immediately
• System must display receipt/confirmation
Constraints:
• Transfer limit: $10,000 per transaction
• Transfer daily limit: $50,000
• Transfers between accounts of same customer only
BA's Role
- Gather all requirements from stakeholders
- Organize and document requirements systematically
- Ensure requirements are clear, complete, and testable
- Manage requirement traceability (track changes)
- Obtain stakeholder approval and sign-off
- Manage requirement changes throughout project
- Ensure requirements map to test cases
Wireframes & Mockups
Visual representations of system layout and user interface
What It Is
Wireframes are low-fidelity visual sketches of a system's user interface. They show page layout, navigation, buttons, and where content goes—without worrying about colors or detailed design. Mockups are higher-fidelity versions that look more like the final product.
UI/UX design, requirements clarification, stakeholder reviews, developer handoff, user testing
Purpose
- Communicate user interface concepts visually
- Get stakeholder feedback before development
- Clarify user flows and navigation
- Document screen layouts and components
- Support user testing and validation
- Serve as design reference for developers
Example Wireframe
Context: E-commerce product page
Wireframe Annotations
BAs add detailed notes explaining:
• User interactions (click, scroll, etc.)
• Conditional logic (show/hide elements)
• Data sources (where info comes from)
• Navigation flows (where clicking leads)
• Validation rules (for form fields)
BA's Role
- Understand user needs and user flows
- Collaborate with designers on layout and navigation
- Create or review wireframes for all key screens
- Add annotations explaining functionality and logic
- Facilitate stakeholder reviews and feedback
- Iterate wireframes based on feedback
- Hand off wireframes to designers and developers
Process Flow Diagrams
Visual representation of how work moves through a business process
What It Is
A process flow diagram (also called a flowchart) shows the sequence of steps in a business process. It uses shapes to represent different types of activities and diamonds to show decision points. Process flows help teams understand how work currently flows and how it should flow in the future.
Process improvement projects, system design, documentation, training, automation initiatives
Flowchart Symbols
| Symbol | Meaning | Example |
|---|---|---|
| ⭕ (Oval) | Start/End | Start Process, End Process |
| ▭ (Rectangle) | Activity/Task | Submit Order, Verify Payment |
| ◇ (Diamond) | Decision Point | Is order approved? |
| ▭ (Parallelogram) | Input/Output | Receive order form |
| → (Arrow) | Flow Direction | Connect steps |
Example: Customer Order Process
Context: E-commerce order fulfillment
↓
Customer Places Order
↓
System Validates Payment ◇ (Payment OK?)
↓ Yes ↓ No
Send Confirmation Send Failure Email
↓ ↓
Pick Items [END]
↓
Pack Order
↓
Generate Shipping Label
↓
Hand to Carrier
↓
Send Tracking Info to Customer
↓
[END]
BA's Role
- Interview process owners to understand current state
- Map existing process flows (AS-IS)
- Identify inefficiencies and bottlenecks
- Design improved process flows (TO-BE)
- Use tools like Visio, Lucidchart, or Draw.io
- Validate flows with stakeholders
- Use flows as basis for system automation
Business Rules
The specific policies and constraints that govern system behavior
What It Is
Business rules are specific policies, constraints, or conditions that define how the business operates and how the system should behave. They answer questions like "What discount percentage should apply?" or "What's the maximum transaction amount?" Business rules are critical for developers to implement correctly.
All project types, especially where business logic is complex, when rules change frequently, compliance/regulatory requirements
Types of Business Rules
- Calculations: How to compute values (discounts, taxes, fees)
- Validations: What data is acceptable (email format, age limits)
- Constraints: Limits on values or actions
- Conditions: If-then logic (if order > $500, then apply discount)
- Policies: Business procedures (approval workflows, approval limits)
Examples from E-commerce
BR-002: If order total exceeds $500, apply 15% discount
BR-003: Customer must be at least 18 years old to purchase
BR-004: Free shipping if order total exceeds $75
BR-005: Sales tax applies only to orders shipped to certain states
BR-006: Customers can return items within 30 days of purchase
BR-007: Restocking fee of 15% applies to returns (except defective items)
BR-008: Only customers with 'Premium' membership can use priority shipping
Detailed Business Rule
Rule Name: Quantity Discount
Description: Apply tiered discounts based on order quantity
Logic:
IF order quantity 1-10: NO discount
IF order quantity 11-25: Apply 5% discount
IF order quantity 26-50: Apply 10% discount
IF order quantity 50+: Apply 15% discount
Affected Screens: Order Entry, Cart, Confirmation
Source System: Pricing Database
Exception Handling: Contact sales manager for additional discounts
BA's Role
- Interview business stakeholders to identify all business rules
- Document rules clearly and unambiguously
- Identify rule exceptions and special cases
- Organize rules in searchable documents or tools
- Ensure developers understand and implement rules correctly
- Include business rules in test plans
- Manage rule changes as business evolves
Test Plans & Test Cases
Specifications for validating that the system works as intended
What It Is
A test plan outlines the testing strategy for a project—what will be tested, how it will be tested, and who will do the testing. Test cases are specific scenarios that verify individual requirements or features work correctly. Together they ensure quality before release.
All projects, especially before go-live, regression testing, quality assurance
Test Plan Contents
- Scope: What's included/excluded from testing
- Approach: Types of testing (functional, integration, UAT, etc.)
- Schedule: Testing timeline and phases
- Resources: Who's involved (testers, BA, etc.)
- Deliverables: What outputs testing produces
- Risk & Exit Criteria: When testing is complete
Test Case Example
Context: Testing login functionality
| Test Case ID | Scenario | Steps | Expected Result | Status |
|---|---|---|---|---|
| TC-001 | Valid Login | 1. Enter valid username 2. Enter valid password 3. Click Login |
User is logged in and directed to dashboard | ✓ Pass |
| TC-002 | Invalid Password | 1. Enter valid username 2. Enter incorrect password 3. Click Login |
Error message: "Invalid credentials" | ✓ Pass |
| TC-003 | Locked Account | 1. Enter username for locked account 2. Enter password 3. Click Login |
Error message: "Account locked. Contact support." | ✓ Pass |
BA's Role
- Develop overall test plan strategy
- Create test cases based on requirements and use cases
- Define test data needs
- Map test cases to requirements (traceability)
- Execute or oversee User Acceptance Testing (UAT)
- Document test results and issues
- Manage defect resolution and retesting
Stakeholder Analysis & RACI
Identifying who's involved and their roles and responsibilities
What It Is
Stakeholder analysis identifies everyone affected by or involved in a project—their interests, influence, and concerns. A RACI matrix clarifies roles: who's Responsible, Accountable, Consulted, and Informed. This prevents confusion and ensures smooth project execution.
Project kickoff, complex projects with many stakeholders, governance, decision-making processes
RACI Definitions
- R (Responsible): Does the work; executes tasks
- A (Accountable): Final authority; approves work (only one per task)
- C (Consulted): Provides input and expertise; asked for feedback
- I (Informed): Kept in loop; receives updates
RACI Matrix Example
Context: CRM System Implementation
| Task | Project Manager | Business Analyst | Sales VP | IT Manager | End Users |
|---|---|---|---|---|---|
| Gather Requirements | I | R/A | C | C | C |
| System Configuration | I | C | I | R/A | I |
| UAT Execution | I | C | A | I | R |
| Go-Live Decision | C | C | A | C | I |
| User Training | I | R | A | I | R |
Stakeholder Profile
Role: Department Head
Interest: Wants system to improve team efficiency
Influence: HIGH - makes final go/no-go decision
Concerns: Training timeline, disruption to sales
Communication Plan: Weekly status updates; monthly executive briefing
BA's Role
- Identify all stakeholders early in project
- Assess their interests, influence, and impact
- Create and maintain RACI matrix
- Develop stakeholder communication plan
- Manage expectations across groups
- Address conflicts between stakeholders
- Keep stakeholders engaged and informed