# Business Analysis Skill

Comprehensive guide for business analysis practices, requirements gathering, process modeling, and analysis techniques.

**Version**: 1.0.0
**Last Updated**: 2025-10-30
**Target Audience**: Business Analysts, Requirements Engineers, Process Analysts

---

## Table of Contents

1. [Requirements Gathering](#1-requirements-gathering)
2. [Process Modeling](#2-process-modeling)
3. [Requirements Documentation](#3-requirements-documentation)
4. [Analysis Techniques](#4-analysis-techniques)
5. [Tools & Deliverables](#5-tools--deliverables)

---

## 1. Requirements Gathering

Requirements gathering is the foundation of successful business analysis. This section covers techniques for eliciting, discovering, and understanding stakeholder needs.

### 1.1 Stakeholder Identification and Analysis

#### Identifying Stakeholders

**Definition**: Stakeholders are individuals or groups who can affect or be affected by the project.

**Stakeholder Categories**:

1. **Primary Stakeholders** (directly affected):
   - End users
   - Customers
   - Project sponsors
   - Product owners

2. **Secondary Stakeholders** (indirectly affected):
   - Support teams
   - Training staff
   - Compliance officers
   - Vendors/suppliers

3. **Key Influencers**:
   - Executive leadership
   - Department heads
   - Subject matter experts (SMEs)
   - Change agents

**Stakeholder Identification Techniques**:

```markdown
## Brainstorming Session
- Gather project team
- List all potential stakeholders
- Group by category and influence level
- Validate with project sponsor

## Organizational Chart Analysis
- Review org structure
- Identify impacted departments
- Map reporting relationships
- Identify decision makers

## Previous Project Analysis
- Review similar past projects
- Identify who was involved
- Learn from previous stakeholder engagement
```

#### Stakeholder Analysis Matrix

Create a Power/Interest Grid to prioritize stakeholder engagement:

```markdown
| Stakeholder | Power | Interest | Strategy |
|-------------|-------|----------|----------|
| CEO | High | Low | Keep Satisfied |
| End Users | Low | High | Keep Informed |
| Project Sponsor | High | High | Manage Closely |
| IT Support | Medium | Medium | Keep Informed |
```

**Power/Interest Grid Quadrants**:

1. **High Power, High Interest** (Manage Closely):
   - Key players, engage frequently
   - Involve in decision-making
   - Regular status updates
   - Address concerns promptly

2. **High Power, Low Interest** (Keep Satisfied):
   - Keep informed at high level
   - Don't overwhelm with details
   - Seek approval at key milestones
   - Monitor for changing interest

3. **Low Power, High Interest** (Keep Informed):
   - Regular communication
   - Gather detailed feedback
   - Champions for change
   - Can provide valuable insights

4. **Low Power, Low Interest** (Monitor):
   - Minimal effort
   - General updates sufficient
   - Monitor for changes
   - May become more engaged later

#### Stakeholder Analysis Template

```markdown
## Stakeholder Profile: [Name/Group]

**Role**: [Job title or group description]
**Department**: [Organizational unit]
**Level**: [Executive/Management/Staff]

**Power/Influence**: [High/Medium/Low]
**Interest Level**: [High/Medium/Low]
**Engagement Strategy**: [Manage Closely/Keep Satisfied/Keep Informed/Monitor]

**Needs and Expectations**:
- [What they need from the project]
- [What they expect as outcomes]
- [Success criteria from their perspective]

**Potential Concerns**:
- [What might worry them]
- [Resistance points]
- [Risk areas]

**Communication Preferences**:
- **Frequency**: [Daily/Weekly/Monthly]
- **Method**: [Email/Meetings/Reports/Dashboard]
- **Detail Level**: [High-level summary/Detailed analysis]

**Key Questions for This Stakeholder**:
1. [Question about their needs]
2. [Question about their constraints]
3. [Question about success criteria]
```

### 1.2 Interview Techniques and Questions

#### Interview Preparation

**Before the Interview**:

1. **Research the stakeholder**:
   - Review their role and responsibilities
   - Understand their department's goals
   - Identify previous interactions with similar projects

2. **Prepare questions**:
   - Create structured interview guide
   - Mix open and closed questions
   - Prepare follow-up probes

3. **Set expectations**:
   - Send agenda in advance
   - Clarify purpose and duration
   - Request any pre-reading materials

4. **Logistics**:
   - Book appropriate time (usually 60-90 minutes)
   - Choose comfortable, private location
   - Test recording equipment (with permission)
   - Prepare note-taking tools

#### Interview Question Framework

**Opening Questions** (Build rapport):
- "Can you describe your current role and key responsibilities?"
- "How long have you been with the organization?"
- "What does a typical day look like for you?"

**Current State Questions**:
- "Can you walk me through your current process for [activity]?"
- "What tools or systems do you currently use?"
- "How do you measure success in your current workflow?"
- "What works well in the current process?"

**Pain Points and Challenges**:
- "What are the biggest challenges you face daily?"
- "What frustrates you most about the current system/process?"
- "Where do you spend the most time in your work?"
- "What causes delays or rework?"
- "If you could change one thing, what would it be?"

**Future State and Requirements**:
- "What would the ideal solution look like?"
- "How would success be measured in a new system?"
- "What capabilities are absolutely essential?"
- "What would make your job significantly easier?"
- "How do you envision using this new system/process?"

**Constraint Questions**:
- "Are there regulatory or compliance requirements we must meet?"
- "What is your timeline for needing this solution?"
- "Are there budget constraints we should be aware of?"
- "What technical limitations do we need to consider?"

**Priority Questions**:
- "If we can only deliver three features, which would you choose?"
- "What capabilities are must-haves vs. nice-to-haves?"
- "What would you be willing to trade off?"

**Closing Questions**:
- "Who else should I speak with about this?"
- "Is there anything important I haven't asked about?"
- "May I follow up if I have additional questions?"

#### Interview Techniques

**Active Listening**:
```markdown
DO:
- Maintain eye contact
- Nod and show engagement
- Take notes but don't let it distract
- Paraphrase to confirm understanding
- Ask clarifying questions

DON'T:
- Interrupt or finish sentences
- Jump to solutions
- Make assumptions
- Multi-task or check devices
- Show bias or judgment
```

**Probing Techniques**:

1. **The 5 Whys**:
   ```
   "We need faster reporting."
   Why? "Reports take too long to generate."
   Why? "We have to pull data from multiple systems."
   Why? "Systems aren't integrated."
   Why? "We lack an enterprise data warehouse."
   Why? "Previous integration project was never completed."
   ```

2. **Expanding Questions**:
   - "Can you tell me more about that?"
   - "What do you mean by [term]?"
   - "Can you give me an example?"
   - "What happens next in that scenario?"

3. **Clarifying Questions**:
   - "When you say 'fast', what timeframe are you thinking?"
   - "Who specifically is included in 'the team'?"
   - "What would 'improved' look like in measurable terms?"

4. **Hypothetical Questions**:
   - "If you had unlimited resources, what would you build?"
   - "What if we could automate this entire process?"
   - "Imagine it's a year from now and this is successful - what changed?"

#### Interview Documentation

**During Interview**:
- Note key quotes verbatim
- Mark action items with [ACTION]
- Flag inconsistencies with [?]
- Track follow-up questions with [FOLLOW-UP]

**Post-Interview**:
```markdown
## Interview Summary: [Stakeholder Name]
**Date**: [Date]
**Duration**: [Time]
**Location**: [Location/Remote]
**Attendees**: [Names and roles]

### Key Takeaways
- [Main point 1]
- [Main point 2]
- [Main point 3]

### Current State Observations
[Summary of how things work now]

### Pain Points Identified
1. [Pain point 1 - with specific examples]
2. [Pain point 2 - with specific examples]
3. [Pain point 3 - with specific examples]

### Requirements Identified
| Requirement | Priority | Type |
|-------------|----------|------|
| [Requirement description] | Must-Have | Functional |
| [Requirement description] | Should-Have | Non-Functional |

### Action Items
- [ ] [Follow-up action 1]
- [ ] [Follow-up action 2]

### Follow-up Questions
- [Question that emerged during interview]
- [Clarification needed]

### Additional Stakeholders to Contact
- [Name] - [Reason to contact]

### Quotes
> "[Significant quote that captures key insight]"
> - [Stakeholder name]
```

### 1.3 Workshop Facilitation

Workshops bring multiple stakeholders together for collaborative requirements elicitation.

#### Workshop Types

**1. Requirements Workshop**:
- **Purpose**: Gather and validate requirements
- **Duration**: 2-4 hours
- **Participants**: 6-12 key stakeholders
- **Outcome**: Prioritized requirements list

**2. Process Mapping Workshop**:
- **Purpose**: Document current or future processes
- **Duration**: 3-6 hours
- **Participants**: Process owners and participants
- **Outcome**: Visual process maps

**3. Design Thinking Workshop**:
- **Purpose**: Ideate solutions collaboratively
- **Duration**: 1-2 days
- **Participants**: Cross-functional team
- **Outcome**: Prototype concepts

**4. Prioritization Workshop**:
- **Purpose**: Rank requirements or features
- **Duration**: 2-3 hours
- **Participants**: Decision makers and SMEs
- **Outcome**: Ranked backlog

#### Workshop Planning Checklist

**4-6 Weeks Before**:
- [ ] Define workshop objectives and scope
- [ ] Identify and invite participants
- [ ] Book facility and arrange logistics
- [ ] Identify co-facilitator if needed

**2-4 Weeks Before**:
- [ ] Develop detailed agenda
- [ ] Prepare workshop materials
- [ ] Send pre-work to participants
- [ ] Confirm attendance

**1 Week Before**:
- [ ] Send reminder with logistics
- [ ] Finalize materials and print
- [ ] Test technology (projector, video conferencing)
- [ ] Arrange catering if applicable

**Day Before**:
- [ ] Review agenda and materials
- [ ] Prepare room setup diagram
- [ ] Charge devices
- [ ] Print name tents

**Day Of**:
- [ ] Arrive early to set up room
- [ ] Test all equipment
- [ ] Arrange materials
- [ ] Welcome participants

#### Workshop Agenda Template

```markdown
## Requirements Gathering Workshop

**Date**: [Date]
**Time**: [Start] - [End]
**Location**: [Location]
**Facilitator**: [Name]

### Pre-Work
Please review the following before the workshop:
- [Document 1]
- [Document 2]

### Agenda

**9:00 - 9:15 | Welcome and Introductions (15 min)**
- Introductions and icebreaker
- Workshop objectives
- Ground rules
- Agenda overview

**9:15 - 9:45 | Context Setting (30 min)**
- Project overview and goals
- Current state summary
- Success criteria
- Scope boundaries

**9:45 - 10:30 | Requirements Brainstorming (45 min)**
Activity: Silent brainstorming followed by group sharing
- Functional requirements
- Non-functional requirements
- Constraints

**10:30 - 10:45 | Break (15 min)**

**10:45 - 11:30 | Requirements Refinement (45 min)**
Activity: Group discussion and clustering
- Consolidate similar items
- Clarify ambiguous requirements
- Add missing details

**11:30 - 12:15 | Prioritization (45 min)**
Activity: MoSCoW prioritization
- Must Have
- Should Have
- Could Have
- Won't Have (this time)

**12:15 - 12:30 | Wrap-up and Next Steps (15 min)**
- Summary of outcomes
- Action items
- Next steps
- Feedback

### Ground Rules
- One conversation at a time
- All ideas are valid
- Stay focused on objectives
- Be present (minimize devices)
- Respect time boundaries
- Challenge ideas, not people
```

#### Facilitation Techniques

**Brainstorming Rules**:
```markdown
1. Quantity over quality initially
2. No criticism or evaluation during generation
3. Wild ideas encouraged
4. Build on others' ideas
5. Stay focused on topic
6. One conversation at a time
```

**Dot Voting for Prioritization**:
```markdown
1. List all items on wall/board
2. Give each participant 5-7 dot stickers
3. Participants place dots on top priorities
4. Can use multiple dots on one item (if allowed)
5. Count dots to see top priorities
6. Discuss results and make final decisions
```

**MoSCoW Prioritization**:
```markdown
**Must Have**: Critical for go-live, project fails without
**Should Have**: Important but not critical, can be deferred
**Could Have**: Nice to have, include if time/budget allows
**Won't Have**: Out of scope for this release
```

**Affinity Mapping**:
```markdown
1. Write each idea on separate sticky note
2. Post all notes on wall
3. Silently group similar items together
4. Discuss groupings as a team
5. Name each group
6. Identify themes and patterns
```

#### Managing Difficult Situations

**Dominant Participant**:
- "Thank you [Name], let's hear from others"
- Use round-robin approach
- Direct questions to quieter participants
- Use silent brainstorming techniques

**Off-Topic Discussion**:
- "That's important, let's capture it in the parking lot"
- "How does this relate to our objective?"
- Redirect to agenda
- Use parking lot board for tangents

**Disagreement or Conflict**:
- Acknowledge both perspectives
- Focus on interests, not positions
- Find common ground
- Table for offline discussion if needed
- Use voting to resolve deadlock

**Low Energy**:
- Take an unscheduled break
- Use energizer activity
- Change format (stand up, move around)
- Check if agenda is too ambitious

### 1.4 Observation and Job Shadowing

Observation provides firsthand insight into how work actually happens (vs. how stakeholders describe it).

#### When to Use Observation

**Ideal Scenarios**:
- Complex processes difficult to describe
- Significant muscle memory or tacit knowledge
- Suspected gaps between described and actual process
- Understanding context and environment
- Identifying workarounds and informal processes

**Not Appropriate When**:
- Highly sensitive or confidential work
- Process happens infrequently
- Work is dangerous or restricted
- Stakeholder is uncomfortable being observed

#### Planning an Observation Session

**Preparation**:
```markdown
1. **Get Permission**:
   - Manager approval
   - Individual consent
   - Explain purpose and process

2. **Set Expectations**:
   - Duration of observation
   - Your role (observer, not evaluator)
   - Confidentiality of findings
   - Ability to ask questions

3. **Prepare Tools**:
   - Observation checklist
   - Note-taking materials
   - Camera (if permitted)
   - Process documentation template

4. **Choose Timing**:
   - Typical workday (avoid unusual circumstances)
   - Complete process cycle if possible
   - Consider busy vs. slow periods
```

#### Observation Framework

**What to Observe**:

1. **Physical Environment**:
   - Workspace layout
   - Tools and equipment
   - Materials and supplies
   - Ergonomics and comfort

2. **Process Steps**:
   - Sequence of activities
   - Decision points
   - Handoffs between people/systems
   - Inputs and outputs

3. **Time and Effort**:
   - Duration of each step
   - Wait times and delays
   - Multitasking
   - Rush vs. thorough work

4. **Tools and Systems**:
   - Software applications used
   - Manual vs. automated steps
   - System switching
   - Workarounds and shortcuts

5. **Interactions**:
   - Communication patterns
   - Collaboration needs
   - Questions asked
   - Information sources

6. **Pain Points**:
   - Frustrations expressed
   - Errors or rework
   - Confusion or uncertainty
   - Inefficiencies

#### Observation Template

```markdown
## Job Shadowing Session: [Role/Process]

**Date**: [Date]
**Time**: [Start] - [End]
**Observer**: [Your name]
**Participant**: [Role or anonymous identifier]
**Process Observed**: [Process name]

### Environment Notes
[Physical workspace, tools available, noise level, etc.]

### Process Flow Observed

| Time | Step | Activity Description | Tools Used | Duration | Notes |
|------|------|---------------------|------------|----------|-------|
| 9:00 | 1 | Login to system | System X | 2 min | Had to reset password |
| 9:02 | 2 | Pull overnight orders | System X | 5 min | System slow to respond |
| 9:07 | 3 | Export to Excel | System X, Excel | 3 min | Manual export needed |

### Workarounds Identified
1. [Workaround description and why it exists]
2. [Workaround description and why it exists]

### Pain Points Observed
- **[Pain point]**: [Description and impact]
- **[Pain point]**: [Description and impact]

### Automation Opportunities
- [Step that could be automated]
- [Repetitive task that could be streamlined]

### Questions Raised
- [Question about why process is done this way]
- [Question about alternative approaches]

### Process Improvement Ideas
1. [Improvement idea based on observation]
2. [Improvement idea based on observation]

### Follow-up Actions
- [ ] Validate observations with participant
- [ ] Interview [Name] about related process
- [ ] Research system capability for [specific need]
```

#### Think-Aloud Protocol

Ask participant to verbalize their thinking:

```markdown
"As you work, please describe what you're thinking and doing:
- What you're looking at
- What you're deciding
- Why you're choosing one option over another
- What you're concerned about"
```

**Benefits**:
- Reveals decision-making process
- Uncovers tacit knowledge
- Identifies information needs
- Shows workarounds and informal rules

### 1.5 Document Analysis

Existing documentation provides valuable context and baseline information.

#### Types of Documents to Analyze

**Strategic Documents**:
- Business plans
- Strategic roadmaps
- Vision and mission statements
- Goals and objectives

**Operational Documents**:
- Standard operating procedures (SOPs)
- Work instructions
- Training materials
- Quality checklists

**System Documentation**:
- User manuals
- System specifications
- Database schemas
- Integration diagrams

**Historical Records**:
- Previous project documentation
- Lessons learned reports
- Meeting minutes
- Email threads

**Compliance Documents**:
- Regulatory requirements
- Audit reports
- Policy documents
- Contracts and SLAs

**Performance Data**:
- Reports and dashboards
- Metrics and KPIs
- Incident logs
- Customer feedback

#### Document Analysis Framework

```markdown
## Document Analysis: [Document Name]

**Document Type**: [Type]
**Date Created**: [Date]
**Author**: [Name/Department]
**Last Updated**: [Date]
**Purpose**: [Why document was created]

### Key Findings

**Relevant Requirements**:
- [Requirement extracted from document]
- [Requirement extracted from document]

**Business Rules Identified**:
- [Rule 1]
- [Rule 2]

**Processes Described**:
- [Process 1 - with reference to section]
- [Process 2 - with reference to section]

**Stakeholders Mentioned**:
- [Stakeholder role and their involvement]

**Constraints Identified**:
- [Constraint from document]

**Assumptions Noted**:
- [Assumption in document]

### Gaps and Inconsistencies

**Missing Information**:
- [What's not covered that should be]

**Inconsistencies with Other Documents**:
- [Conflict with Document X about Y]

**Outdated Information**:
- [What needs updating]

### Questions for Stakeholders
1. [Question about unclear point]
2. [Question about inconsistency]
3. [Question about gap]

### Action Items
- [ ] Verify [information] with [stakeholder]
- [ ] Request updated version of [document]
- [ ] Clarify [conflicting information]
```

#### Analysis Checklist

**Quality Assessment**:
- [ ] Is documentation current and up-to-date?
- [ ] Is it complete for our needs?
- [ ] Is it accurate (verified with stakeholders)?
- [ ] Is terminology consistent?
- [ ] Are there version control issues?

**Content Analysis**:
- [ ] What requirements are explicitly stated?
- [ ] What business rules are defined?
- [ ] What processes are documented?
- [ ] What constraints are mentioned?
- [ ] What assumptions are made?

**Gap Analysis**:
- [ ] What information is missing?
- [ ] What conflicts with other documents?
- [ ] What has changed since creation?
- [ ] What needs validation?

---

## 2. Process Modeling

Process modeling creates visual representations of business processes to analyze, communicate, and improve them.

### 2.1 BPMN Notation and Diagrams

BPMN (Business Process Model and Notation) is the standard for process modeling.

#### Core BPMN Elements

**1. Events** (things that happen):

```markdown
**Start Events** (where process begins):
○ - Start Event (generic)
⊙ - Timer Start Event (scheduled)
✉ - Message Start Event (triggered by message)

**Intermediate Events** (occur during process):
◎ - Generic Intermediate Event
⊕ - Timer Intermediate Event (wait for time)
⊞ - Message Intermediate Event (send/receive message)

**End Events** (where process ends):
⊗ - End Event (process completes)
⊗ - Terminate End Event (end all paths)
✉⊗ - Message End Event (send message and end)
```

**2. Activities** (work being done):

```markdown
[Activity Name] - Task (single unit of work)
[⊞ Activity Name] - Subprocess (collapsed process)
[⊕ Activity Name] - Loop Activity (repeats)
```

**3. Gateways** (control flow):

```markdown
◇ - Exclusive Gateway (XOR) - one path chosen
⬦ - Parallel Gateway (AND) - all paths taken
⬢ - Inclusive Gateway (OR) - one or more paths
○◇ - Event-Based Gateway - wait for event
```

**4. Connecting Objects**:

```markdown
→ - Sequence Flow (order of activities)
--- → - Message Flow (between pools)
.... - Association (link to artifacts)
```

**5. Swimlanes**:

```markdown
Pool: Represents an organization or major participant
Lane: Subdivides pool by role or department
```

#### BPMN Diagram Example

```mermaid
flowchart TB
    Start([Start: Customer Order Received]) --> Validate{Validate Order}
    Validate -->|Valid| CheckStock[Check Inventory]
    Validate -->|Invalid| NotifyError[Notify Customer of Error]
    NotifyError --> End1([End])

    CheckStock --> StockDecision{In Stock?}
    StockDecision -->|Yes| ProcessPayment[Process Payment]
    StockDecision -->|No| Backorder{Backorder Available?}

    Backorder -->|Yes| CreateBackorder[Create Backorder]
    Backorder -->|No| NotifyOut[Notify Out of Stock]
    CreateBackorder --> ProcessPayment
    NotifyOut --> End2([End])

    ProcessPayment --> PaymentOK{Payment Approved?}
    PaymentOK -->|Yes| FulfillOrder[Fulfill Order]
    PaymentOK -->|No| NotifyPaymentFail[Notify Payment Failed]
    NotifyPaymentFail --> End3([End])

    FulfillOrder --> ShipOrder[Ship Order]
    ShipOrder --> NotifyShipped[Send Shipping Confirmation]
    NotifyShipped --> End4([End: Order Complete])
```

#### BPMN Best Practices

**DO**:
- Start with high-level process, then detail
- Use consistent naming conventions (Verb + Noun)
- Keep diagrams readable (one page if possible)
- Show happy path clearly
- Document exceptions and error handling
- Use swimlanes to show responsibilities
- Include timing information when relevant

**DON'T**:
- Mix different levels of detail
- Create overly complex diagrams (max 20-30 elements)
- Use technical jargon for business processes
- Forget to show end states
- Ignore exception flows
- Create diagrams without validation from process owners

### 2.2 Swimlane Diagrams

Swimlanes show which role or department performs each activity.

#### Swimlane Structure

```markdown
## Order Processing (Swimlane View)

┌─────────────────────────────────────────────────────────────┐
│ CUSTOMER                                                     │
├─────────────────────────────────────────────────────────────┤
│  ○ Place Order → [Fill Order Form] → Submit →               │
│                                               ↓              │
│                                    ← [Review Confirmation]  │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ SALES                                                        │
├─────────────────────────────────────────────────────────────┤
│                  ↑                                           │
│                [Receive Order] → {Valid?} ─No→ [Reject]     │
│                                      │                       │
│                                     Yes                      │
│                                      ↓                       │
│                              [Check Credit] → {OK?}         │
│                                      │                       │
│                                     Yes                      │
│                                      ↓                       │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ WAREHOUSE                                                    │
├─────────────────────────────────────────────────────────────┤
│                                      ↑                       │
│                           [Pick Items] → [Pack Order]       │
│                                              ↓               │
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ SHIPPING                                                     │
├─────────────────────────────────────────────────────────────┤
│                                              ↑               │
│                              [Create Label] → [Ship] → ⊗    │
└─────────────────────────────────────────────────────────────┘
```

#### Swimlane Template

```markdown
## Process: [Process Name]

**Purpose**: [What this process accomplishes]
**Trigger**: [What starts this process]
**Outcome**: [What is produced]

### Swimlanes (Roles/Departments)

**Lane 1: [Role Name]**
- Step 1.1: [Activity]
- Step 1.2: [Activity]
- Decision 1.3: [Gateway]

**Lane 2: [Role Name]**
- Step 2.1: [Activity]
- Step 2.2: [Activity]

**Lane 3: [Role Name]**
- Step 3.1: [Activity]
- Step 3.2: [Activity]

### Handoffs

| From | To | What is Transferred | Method | Time |
|------|-----|---------------------|--------|------|
| Sales | Warehouse | Order details | System X | Real-time |
| Warehouse | Shipping | Packed order | Physical handoff | 15 min |

### Notes
- [Important information about process]
- [Exceptions or special cases]
```

### 2.3 Process Analysis (As-Is vs To-Be)

#### As-Is Process Analysis

**Purpose**: Document current state to identify improvement opportunities.

**As-Is Analysis Template**:

```markdown
## As-Is Process: [Process Name]

**Last Updated**: [Date]
**Process Owner**: [Name]
**Frequency**: [How often process runs]
**Average Duration**: [Time to complete]

### Process Overview
[Brief description of what process does today]

### Process Steps

| Step | Activity | Role | System | Duration | Issues |
|------|----------|------|--------|----------|--------|
| 1 | Receive request | Admin | Email | 5 min | Manual entry required |
| 2 | Validate data | Analyst | Excel | 30 min | No validation rules |
| 3 | Approve request | Manager | Paper form | 2 days | Manager often unavailable |

### Process Metrics

**Efficiency Metrics**:
- Total cycle time: 3-5 days
- Active work time: 2 hours
- Wait time: 90% of cycle time
- Rework rate: 20%
- Error rate: 15%

**Volume Metrics**:
- Requests per month: 200
- Peak volume: 350 (month-end)
- Staff required: 3 FTEs

**Cost Metrics**:
- Labor cost per transaction: $45
- System costs: $500/month
- Error correction cost: $2,000/month

### Pain Points Identified

**1. Manual Data Entry**
- **Issue**: Request form must be re-typed into system
- **Impact**: Time consuming, error-prone
- **Frequency**: Every request
- **Impact Score**: High

**2. Approval Delays**
- **Issue**: Manager approval requires physical signature
- **Impact**: 2-3 day delays common, longer if manager traveling
- **Frequency**: Every request
- **Impact Score**: High

**3. No Validation**
- **Issue**: Data errors discovered late in process
- **Impact**: Rework and delays
- **Frequency**: 20% of requests
- **Impact Score**: Medium

### Bottlenecks
1. Manager approval (48-72 hour delay)
2. Data validation (30 minutes of manual checking)
3. Month-end volume spike (causes 5-day backlog)

### Workarounds
- Analysts email manager for urgent approvals
- Pre-validation by submitter (informal)
- Overtime during month-end

### Root Causes
- Legacy systems not integrated
- Manual approval policy never updated
- No investment in automation tools
```

#### To-Be Process Design

**Purpose**: Define future state that addresses pain points.

**To-Be Design Template**:

```markdown
## To-Be Process: [Process Name]

**Target Implementation**: [Date]
**Process Owner**: [Name]
**Expected Frequency**: [How often]
**Target Duration**: [Time to complete]

### Process Overview
[Description of improved process]

### Improvements Over As-Is

| Current State | Future State | Improvement |
|---------------|--------------|-------------|
| Manual data entry | Web form with integration | 80% time reduction |
| Physical signature | Electronic approval | 90% faster approval |
| Manual validation | Automated rules | 100% error detection |

### Process Steps (To-Be)

| Step | Activity | Role | System | Duration | Changes from As-Is |
|------|----------|------|--------|----------|-------------------|
| 1 | Submit request | Requester | Web portal | 2 min | Self-service, validation |
| 2 | Auto-validate | System | Portal | 30 sec | Automated |
| 3 | Approve request | Manager | Portal (mobile) | 1 hour | Electronic, notifications |

### Expected Metrics

**Efficiency Improvements**:
- Total cycle time: 4 hours (was 3-5 days)
- Active work time: 30 minutes (was 2 hours)
- Wait time: 10% (was 90%)
- Rework rate: 2% (was 20%)
- Error rate: 1% (was 15%)

**Capacity Improvements**:
- Staff required: 1 FTE (was 3)
- Peak handling: 500/month (was 350)
- No overtime needed

**Cost Savings**:
- Labor cost per transaction: $8 (was $45)
- Annual labor savings: $88,800
- Error correction savings: $21,600/year
- ROI: 18 months

### Changes Required

**Technology**:
- [ ] Implement web portal
- [ ] Integrate with core system
- [ ] Build validation rules
- [ ] Enable electronic signatures
- [ ] Mobile app for managers

**Process**:
- [ ] Update approval policy
- [ ] Create self-service help
- [ ] Define SLAs
- [ ] Update training materials

**People**:
- [ ] Train requesters on portal
- [ ] Train managers on mobile approval
- [ ] Redeploy 2 FTEs to other work

**Governance**:
- [ ] Update policy documents
- [ ] Get executive approval
- [ ] Communicate changes
- [ ] Establish metrics dashboard

### Implementation Plan

**Phase 1: Foundation (Month 1-2)**
- Build web portal
- Integrate systems
- Pilot with small group

**Phase 2: Rollout (Month 3)**
- Train all users
- Full launch
- Monitor closely

**Phase 3: Optimize (Month 4-6)**
- Gather feedback
- Fine-tune process
- Measure benefits

### Risk Mitigation

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| User adoption | Medium | High | Extensive training, champions |
| System integration | Low | High | Prototype early, fallback plan |
| Process not followed | Medium | Medium | Clear communication, monitoring |
```

### 2.4 Process Improvement Identification

#### Process Improvement Framework

**DMAIC Methodology** (Six Sigma approach):

```markdown
**Define**: What process needs improvement?
- Identify process scope
- Define problem statement
- Establish goals and metrics

**Measure**: How is the process performing?
- Map current process
- Collect baseline data
- Identify pain points

**Analyze**: Why are problems occurring?
- Root cause analysis
- Identify waste and inefficiency
- Determine improvement opportunities

**Improve**: What changes will help?
- Design future state
- Pilot improvements
- Validate benefits

**Control**: How do we sustain improvements?
- Implement monitoring
- Train staff
- Document new process
```

#### Seven Wastes (LEAN)

Identify and eliminate waste in processes:

```markdown
1. **Transportation**: Unnecessary movement of materials/information
   Example: Printing document just to scan it elsewhere

2. **Inventory**: Excess information or materials waiting
   Example: Queue of 100 unprocessed requests

3. **Motion**: Unnecessary movement of people
   Example: Walking to another building for signatures

4. **Waiting**: Idle time between activities
   Example: Waiting 2 days for approval

5. **Overproduction**: Creating more than immediately needed
   Example: Generating unused reports "just in case"

6. **Overprocessing**: More work than required
   Example: Multiple people reviewing same document

7. **Defects**: Errors requiring rework
   Example: Incorrect data entry requiring correction
```

#### Improvement Identification Template

```markdown
## Process Improvement Opportunities: [Process]

### Quick Wins (High Impact, Low Effort)

**1. [Improvement Name]**
- **Current Issue**: [What's wrong]
- **Proposed Solution**: [How to fix]
- **Expected Benefit**: [What improves]
- **Effort**: [Hours/days to implement]
- **Cost**: [Estimated cost]
- **Dependencies**: [What's needed]

**2. [Improvement Name]**
[Same structure]

### Strategic Improvements (High Impact, High Effort)

**1. [Improvement Name]**
- **Current Issue**: [What's wrong]
- **Proposed Solution**: [How to fix]
- **Expected Benefit**: [What improves]
- **Effort**: [Weeks/months to implement]
- **Cost**: [Estimated cost]
- **Dependencies**: [What's needed]

### Small Enhancements (Low Impact, Low Effort)

**1. [Improvement Name]**
[Same structure]

### Not Recommended (Low Impact, High Effort)
- [Improvement that isn't worth it]

### Prioritization Matrix

```
High Impact │  3. Strategic  │  1. Quick Win
            │                │
            ├────────────────┼───────────────
            │                │
Low Impact  │  4. Not Worth  │  2. Enhancement
            │                │
            └────────────────┴───────────────
              High Effort      Low Effort
```

### Implementation Roadmap

**Q1**: Quick Wins 1, 2, 3
**Q2**: Strategic Improvement 1 (Phase 1)
**Q3**: Strategic Improvement 1 (Phase 2), Enhancement 1
**Q4**: Strategic Improvement 2
```

---

## 3. Requirements Documentation

Clear, testable requirements are the foundation of successful projects.

### 3.1 User Stories (As a, I want, So that)

User stories describe functionality from user perspective.

#### User Story Structure

```markdown
As a [type of user]
I want [goal/desire]
So that [benefit/value]
```

**Example**:
```markdown
As a customer
I want to track my order status online
So that I know when to expect delivery without calling support
```

#### Writing Good User Stories

**INVEST Criteria**:

```markdown
**I - Independent**: Story can be developed standalone
**N - Negotiable**: Details can be discussed
**V - Valuable**: Delivers value to user/business
**E - Estimable**: Team can size the effort
**S - Small**: Can be completed in one iteration
**T - Testable**: Clear acceptance criteria
```

**Examples of Good vs. Bad User Stories**:

**Bad** (Too technical):
```markdown
As a developer
I want to implement REST API endpoints
So that data can be accessed
```

**Good** (User-focused):
```markdown
As a mobile app user
I want to sync my data across devices
So that I can access my information anywhere
```

**Bad** (Too vague):
```markdown
As a user
I want better reporting
So that I can do my job
```

**Good** (Specific):
```markdown
As a sales manager
I want to see daily sales by region in a dashboard
So that I can quickly identify underperforming territories
```

#### User Story Template

```markdown
## User Story: [Short Title]

**ID**: US-###
**Epic**: [Parent epic]
**Priority**: [Must/Should/Could Have]
**Story Points**: [Estimate]

### Story

As a [role]
I want [feature]
So that [benefit]

### Acceptance Criteria

1. Given [context]
   When [action]
   Then [outcome]

2. Given [context]
   When [action]
   Then [outcome]

3. Given [context]
   When [action]
   Then [outcome]

### Additional Details

**User Persona**: [Which persona this serves]
**Business Value**: [Why this matters]
**Dependencies**: [Other stories or systems needed]
**Assumptions**: [What we're assuming]

### Technical Notes
- [Technical consideration 1]
- [Technical consideration 2]

### Questions
- [ ] [Open question to resolve]

### Definition of Done
- [ ] Code complete and reviewed
- [ ] Unit tests written and passing
- [ ] Acceptance criteria verified
- [ ] Documentation updated
- [ ] Deployed to staging
```

#### User Story Examples by Type

**Feature Story**:
```markdown
As a customer
I want to filter products by price range
So that I can find items within my budget

**Acceptance Criteria**:
1. Given I'm on the product listing page
   When I set a minimum and maximum price
   Then only products in that range are displayed

2. Given I've applied a price filter
   When no products match the range
   Then I see "No products found" message

3. Given I've applied a price filter
   When I click "Clear Filters"
   Then all products are displayed again
```

**Bug Fix Story**:
```markdown
As a user
I want the shopping cart to persist my items
So that I don't lose my selections when I close the browser

**Acceptance Criteria**:
1. Given I've added items to my cart
   When I close the browser
   Then my items are still in cart when I return

2. Given I've added items on desktop
   When I login on mobile
   Then I see the same cart items
```

**Technical Story** (when absolutely necessary):
```markdown
As a development team
We want to upgrade the database to version 12
So that we can use improved performance features

**Acceptance Criteria**:
1. Database upgraded with zero data loss
2. All existing queries still function
3. Rollback plan tested and documented
```

### 3.2 Use Cases Structure

Use cases describe interactions between actors and system to achieve a goal.

#### Use Case Template

```markdown
## Use Case: [Name]

**ID**: UC-###
**Priority**: [High/Medium/Low]
**Status**: [Draft/Reviewed/Approved]

### Brief Description
[One paragraph overview of what this use case accomplishes]

### Actors
- **Primary Actor**: [Who initiates this use case]
- **Secondary Actors**: [Other participants]
- **Systems**: [External systems involved]

### Preconditions
- [Condition that must be true before use case starts]
- [Another precondition]

### Postconditions
**Success**:
- [What's true after successful completion]
- [Another postcondition]

**Failure**:
- [What's true if use case fails]

### Main Success Scenario
1. [Actor] [action]
2. System [response]
3. [Actor] [action]
4. System [response]
5. Use case ends successfully

### Extensions (Alternate Flows)

**3a. Invalid Data Entered**
  3a1. System displays validation error
  3a2. System highlights problematic fields
  3a3. Use case continues at step 3

**4a. System Timeout**
  4a1. System displays timeout message
  4a2. System saves partial progress
  4a3. Use case ends in failure

**\*a. Actor Cancels**
  \*a1. System prompts to confirm cancellation
  \*a2. System discards changes
  \*a3. Use case ends

### Special Requirements
- [Non-functional requirement relevant to this use case]
- [Another special requirement]

### Frequency of Use
[How often: Continuous / Daily / Weekly / Monthly / Rare]

### Business Rules
- BR-1: [Business rule that applies]
- BR-2: [Another business rule]

### User Interface Mockup
[Reference to mockup or wireframe if available]

### Open Issues
- [Question or issue to resolve]
```

#### Detailed Use Case Example

```markdown
## Use Case: Process Refund Request

**ID**: UC-012
**Priority**: High
**Status**: Approved

### Brief Description
Customer service representative processes a customer's refund request for a returned item, validating eligibility and issuing refund through the appropriate payment method.

### Actors
- **Primary Actor**: Customer Service Representative
- **Secondary Actors**: Customer, Accounting System
- **Systems**: Order Management System, Payment Gateway

### Preconditions
- Representative is logged into Order Management System
- Customer has provided order number
- Order exists in system
- Product has been returned and received in warehouse

### Postconditions
**Success**:
- Refund is approved and processed
- Customer receives email confirmation
- Accounting records are updated
- Order status updated to "Refunded"

**Failure**:
- Refund is denied
- Customer is notified of denial reason
- Order status remains unchanged

### Main Success Scenario
1. Representative enters order number
2. System displays order details and refund eligibility
3. Representative verifies return reason with customer
4. Representative selects items for refund
5. System calculates refund amount based on return policy
6. System displays refund amount and payment method
7. Representative confirms refund processing
8. System processes refund through payment gateway
9. System updates order status to "Refunded"
10. System sends confirmation email to customer
11. Use case ends successfully

### Extensions (Alternate Flows)

**2a. Order Not Found**
  2a1. System displays "Order not found" error
  2a2. System prompts to re-enter order number
  2a3. Use case continues at step 1

**2b. Order Not Eligible for Refund**
  2b1. System displays reason for ineligibility
  2b2. Representative explains policy to customer
  2b3. Use case ends in failure

**5a. Partial Refund Required**
  5a1. Representative adjusts refund amount
  5a2. Representative enters justification note
  5a3. System requires manager approval
  5a4. Manager reviews and approves/denies
  5a5. Use case continues at step 6 (if approved)

**8a. Payment Gateway Error**
  8a1. System displays error message
  8a2. System logs error for technical team
  8a3. Representative notes issue in customer record
  8a4. Use case continues at step 8 (retry)
  8a5. If retry fails, representative escalates to supervisor

**8b. Original Payment Method Invalid**
  8b1. System alerts representative
  8b2. Representative requests alternate refund method
  8b3. Customer provides alternative (check, store credit)
  8b4. Use case continues at step 8 with new method

### Special Requirements
- Refund must process within 5 business days
- All refunds over $500 require manager approval
- System must maintain audit trail of all actions
- Compliance with PCI DSS for payment data

### Frequency of Use
Approximately 50-100 times per day across all representatives

### Business Rules
- BR-012: Products must be returned within 30 days of purchase
- BR-013: Refund amount is purchase price minus shipping unless item defective
- BR-014: Store credit option provides 10% bonus value
- BR-015: Final sale items are not refundable

### User Interface Mockup
See wireframe: Refund-Processing-Screen-v2.png

### Open Issues
- Waiting for confirmation on international refund processing time
- Need to clarify partial return shipping fee policy
```

### 3.3 Functional vs Non-Functional Requirements

#### Functional Requirements

**Definition**: What the system must do - specific behaviors and functions.

**Categories**:
```markdown
1. **Business Logic**: Calculations, validations, business rules
2. **Data Management**: CRUD operations, data manipulation
3. **User Interaction**: Interface behaviors, workflows
4. **Integration**: Interactions with other systems
5. **Reporting**: Information presentation and export
```

**Functional Requirement Template**:
```markdown
**FR-###: [Requirement Title]**

**Description**: [Detailed description of what system must do]

**Priority**: [Must/Should/Could Have]

**Rationale**: [Why this requirement exists]

**Acceptance Criteria**:
1. [Testable criterion 1]
2. [Testable criterion 2]
3. [Testable criterion 3]

**Dependencies**: [Related requirements or systems]

**Business Rule Reference**: [Related business rules]
```

**Examples**:

```markdown
**FR-101: Password Reset**
The system shall allow users to reset their password via email verification.

**Acceptance Criteria**:
1. User can request password reset by entering email address
2. System sends reset link valid for 24 hours
3. User can set new password meeting complexity requirements
4. System invalidates old password upon successful reset
5. System sends confirmation email after reset

---

**FR-102: Invoice Calculation**
The system shall calculate invoice total as sum of line items plus applicable taxes minus discounts.

**Acceptance Criteria**:
1. Line item total = quantity × unit price
2. Subtotal = sum of all line items
3. Tax = subtotal × tax rate (based on ship-to location)
4. Discount = subtotal × discount percentage (if applicable)
5. Total = subtotal + tax - discount
6. All amounts rounded to 2 decimal places

---

**FR-103: Order Status Notification**
The system shall automatically send email notifications when order status changes.

**Acceptance Criteria**:
1. Email sent when order placed (confirmation)
2. Email sent when order shipped (with tracking number)
3. Email sent when order delivered
4. Email sent if order cancelled
5. User can opt-out of non-essential notifications
6. Email template uses branding guidelines
```

#### Non-Functional Requirements

**Definition**: How the system performs - quality attributes and constraints.

**Categories (FURPS+)**:

```markdown
**F - Functionality**: Already covered in functional requirements

**U - Usability**: User experience, accessibility
**R - Reliability**: Availability, fault tolerance
**P - Performance**: Speed, throughput, capacity
**S - Supportability**: Maintainability, testability

**+ Additional Categories**:
- Design constraints
- Implementation requirements
- Interface requirements
- Physical requirements
- Security requirements
- Compliance requirements
```

**Non-Functional Requirement Template**:
```markdown
**NFR-###: [Requirement Title]**

**Category**: [Usability/Performance/Security/etc.]

**Description**: [Detailed description]

**Priority**: [Must/Should/Could Have]

**Measurement**: [How to measure/verify]

**Acceptance Criteria**: [Testable criteria]
```

**Examples by Category**:

**Usability Requirements**:
```markdown
**NFR-201: Response Time Perception**
Category: Usability
The system shall provide feedback within 0.1 seconds for user actions.

**Measurement**: User testing and timing analysis

**Acceptance Criteria**:
1. Button clicks show visual response within 100ms
2. Loading indicators appear for operations over 1 second
3. Progress bars update for operations over 5 seconds

---

**NFR-202: Accessibility Compliance**
Category: Usability
The system shall comply with WCAG 2.1 Level AA standards.

**Acceptance Criteria**:
1. All images have descriptive alt text
2. Interface navigable via keyboard only
3. Minimum contrast ratio of 4.5:1 for text
4. Screen reader compatible
5. No time-based interactions under 5 seconds
```

**Performance Requirements**:
```markdown
**NFR-301: Page Load Time**
Category: Performance
Web pages shall load in under 2 seconds on standard broadband connection.

**Measurement**: Load testing with typical data volumes

**Acceptance Criteria**:
1. 95% of page loads under 2 seconds
2. 99% of page loads under 3 seconds
3. Measured with 50ms latency, 5Mbps bandwidth

---

**NFR-302: Concurrent Users**
Category: Performance
System shall support 1,000 concurrent users without degradation.

**Measurement**: Load testing

**Acceptance Criteria**:
1. Response time remains under 2 seconds at 1,000 users
2. No errors or timeouts at maximum load
3. Resource utilization under 80% at peak
```

**Reliability Requirements**:
```markdown
**NFR-401: System Availability**
Category: Reliability
System shall be available 99.9% of time during business hours (8am-8pm ET).

**Measurement**: Uptime monitoring

**Acceptance Criteria**:
1. Maximum 43 minutes downtime per month
2. Planned maintenance outside business hours
3. Disaster recovery in under 4 hours

---

**NFR-402: Data Backup**
Category: Reliability
System shall backup all data daily with 30-day retention.

**Acceptance Criteria**:
1. Automated backup runs daily at 2am
2. Backup completion verified within 1 hour
3. Monthly restore test conducted
4. Off-site backup copy maintained
```

**Security Requirements**:
```markdown
**NFR-501: Authentication**
Category: Security
System shall require multi-factor authentication for all users.

**Acceptance Criteria**:
1. Username/password as first factor
2. SMS, authenticator app, or hardware token as second factor
3. Session timeout after 30 minutes inactivity
4. Account lockout after 5 failed attempts

---

**NFR-502: Data Encryption**
Category: Security
System shall encrypt all sensitive data at rest and in transit.

**Acceptance Criteria**:
1. AES-256 encryption for data at rest
2. TLS 1.3 for data in transit
3. Encryption keys rotated quarterly
4. PII data encrypted in database
```

### 3.4 Acceptance Criteria

Acceptance criteria define when a requirement is "done."

#### Given-When-Then Format

```markdown
**Given** [initial context/precondition]
**When** [action/event occurs]
**Then** [expected outcome]
```

**Examples**:

```markdown
## User Story: Shopping Cart Quantity Update

**Acceptance Criteria**:

**AC1: Increase Quantity**
Given I have an item with quantity 1 in my cart
When I click the increase quantity button
Then the quantity updates to 2
And the item subtotal reflects new quantity
And the cart total updates accordingly

**AC2: Decrease Quantity**
Given I have an item with quantity 2 in my cart
When I click the decrease quantity button
Then the quantity updates to 1
And the item subtotal reflects new quantity

**AC3: Remove Item**
Given I have an item with quantity 1 in my cart
When I click the decrease quantity button
Then the item is removed from cart
And I see "Item removed" confirmation message

**AC4: Maximum Quantity**
Given I have an item with quantity 10 in my cart
When I try to increase quantity
Then I see "Maximum quantity reached" error
And quantity remains at 10

**AC5: Direct Entry**
Given I'm viewing my cart
When I type "5" in the quantity field and press Enter
Then the quantity updates to 5
And validations run (positive integer, in stock)
```

#### Checklist Format

For simpler requirements, use checklist:

```markdown
## Feature: User Profile Settings

**Acceptance Criteria**:
- [ ] User can update first and last name
- [ ] User can update email address (with verification)
- [ ] User can upload profile photo (max 5MB, JPG/PNG only)
- [ ] User can change password (requires current password)
- [ ] User can enable/disable email notifications
- [ ] User can set timezone preference
- [ ] User can delete account (with confirmation)
- [ ] All changes are saved with "Settings updated" message
- [ ] Validation errors display clearly
- [ ] Form is mobile-responsive
```

#### Edge Cases in Acceptance Criteria

Always consider edge cases:

```markdown
## Feature: Search Functionality

**Acceptance Criteria**:

**Happy Path**:
Given I enter "laptop" in search
When I click Search
Then I see relevant results ranked by relevance
And I see result count
And I can sort and filter results

**Edge Cases**:

**Empty Search**:
Given the search box is empty
When I click Search
Then I see "Please enter a search term" message
And no results are shown

**No Results**:
Given I enter "xyzabc123" in search
When I click Search
Then I see "No results found" message
And I see suggestions for similar terms

**Special Characters**:
Given I enter search with special characters (*, &, <, >)
When I click Search
Then special characters are properly escaped
And search executes without error

**Very Long Search**:
Given I enter 500 character search string
When I click Search
Then I see "Search term too long" error
And maximum length is indicated

**SQL Injection Attempt**:
Given I enter "'; DROP TABLE users;--"
When I click Search
Then input is properly sanitized
And no SQL is executed
And search treats it as literal string
```

### 3.5 Traceability Matrix

Traceability links requirements to their sources and implementations.

#### Requirements Traceability Matrix (RTM)

```markdown
## Requirements Traceability Matrix

**Project**: [Project Name]
**Date**: [Date]
**Version**: [Version]

| Req ID | Requirement | Source | Priority | Design Doc | Test Case | Status |
|--------|-------------|--------|----------|------------|-----------|--------|
| BR-001 | Business Rule 1 | Stakeholder Interview 1 | Must | DD-01 | TC-001, TC-002 | Complete |
| FR-101 | Login functionality | BR-001 | Must | DD-02 | TC-010-015 | In Progress |
| FR-102 | Password reset | BR-001 | Should | DD-02 | TC-020-022 | Not Started |
| NFR-201 | Page load < 2s | Performance SLA | Must | DD-05 | TC-100 | Complete |
| US-050 | User dashboard | Workshop 3 | Must | DD-03 | TC-030-035 | Testing |
```

**Column Definitions**:
- **Req ID**: Unique identifier
- **Requirement**: Brief description
- **Source**: Where requirement originated
- **Priority**: Must/Should/Could/Won't Have
- **Design Doc**: Design documentation reference
- **Test Case**: Test cases that verify requirement
- **Status**: Current implementation status

#### Forward and Backward Traceability

**Forward Traceability** (Requirement → Deliverables):
```markdown
Business Need → Business Requirement → Functional Requirement → Design → Code → Test
```

**Backward Traceability** (Deliverables → Requirement):
```markdown
Test ← Code ← Design ← Functional Requirement ← Business Requirement ← Business Need
```

**Example**:

```markdown
## Traceability Chain: Fast Checkout

**Business Need**: BN-10
"Reduce cart abandonment rate by simplifying checkout"

**Business Requirement**: BR-45
"Checkout process must require no more than 3 steps"

**Functional Requirements**:
- FR-220: Single page checkout design
- FR-221: Guest checkout option
- FR-222: Saved payment methods for registered users
- FR-223: Address auto-complete

**Design Documents**:
- DD-15: Checkout Flow Design
- DD-16: Payment Integration Design

**Implementation**:
- Code Module: checkout_module.py
- Database: checkout_schema.sql
- API: /api/checkout endpoint

**Test Cases**:
- TC-500: Guest checkout flow
- TC-501: Registered user checkout
- TC-502: Checkout performance
- TC-503: Checkout validation

**Validation**:
- Cart abandonment reduced from 68% to 45%
- Average checkout time reduced from 4:30 to 2:15
- Customer satisfaction score increased 15%
```

---

## 4. Analysis Techniques

### 4.1 Gap Analysis

Gap analysis identifies differences between current and desired states.

#### Gap Analysis Framework

```markdown
## Gap Analysis: [Process/System Name]

**Date**: [Date]
**Analyst**: [Name]
**Stakeholders**: [Names]

### Current State (As-Is)

**Capabilities**:
- [What we can do today]
- [Current feature/process]
- [Existing functionality]

**Performance**:
- [Current metrics]
- [Performance levels]

**Limitations**:
- [What we cannot do]
- [Constraints]
- [Bottlenecks]

### Desired State (To-Be)

**Required Capabilities**:
- [What we need to do]
- [Required features]
- [Target functionality]

**Performance Targets**:
- [Target metrics]
- [Desired performance levels]

**Success Criteria**:
- [What success looks like]
- [Measurable outcomes]

### Gap Identification

| Area | Current State | Desired State | Gap | Impact |
|------|---------------|---------------|-----|--------|
| Functionality | Manual data entry | Automated import | No import capability | High - 3hrs/day wasted |
| Performance | 5 min response | 30 sec response | 4.5 min improvement needed | Medium - user frustration |
| Capacity | 100 users | 500 users | 400 additional users | High - business growth limited |
| Integration | Manual transfer | Real-time sync | No integration | High - errors and delays |

### Root Cause Analysis

**Gap 1: No Import Capability**
- **Why?**: Legacy system built before APIs existed
- **Why?**: No budget for modernization
- **Why?**: Priority given to other projects
- **Root Cause**: Lack of business case for ROI

### Impact Assessment

**Business Impact**:
- Lost productivity: 750 hours/year
- Cost: $30,000/year in labor
- Opportunity cost: Cannot serve enterprise clients

**Technical Impact**:
- Technical debt increasing
- System maintenance burden
- Risk of system failure

**User Impact**:
- Frustration and workarounds
- Training burden for new staff
- Errors due to manual entry

### Recommendations

**Priority 1: Quick Wins** (0-3 months)
1. **Bulk Import via CSV**
   - Effort: 2 weeks development
   - Cost: $8,000
   - Benefit: 50% time savings
   - ROI: 3 months

**Priority 2: Strategic** (3-12 months)
2. **API Integration**
   - Effort: 3 months
   - Cost: $75,000
   - Benefit: 90% time savings, real-time data
   - ROI: 12 months

**Priority 3: Future**:
3. **System Replacement**
   - Effort: 12 months
   - Cost: $500,000
   - Benefit: All gaps closed
   - ROI: 24 months

### Implementation Roadmap

**Phase 1** (Q1): Bulk CSV import
**Phase 2** (Q2-Q3): API integration
**Phase 3** (Q4): Performance optimization
**Phase 4** (Year 2): Evaluate system replacement

### Success Metrics

**How we'll measure closure of gaps**:
- Import time reduced by 80%
- Data error rate below 1%
- User satisfaction score > 8/10
- System handles 500 concurrent users
```

### 4.2 Root Cause Analysis

#### 5 Whys Technique

Ask "Why?" five times to drill down to root cause.

**Example**:

```markdown
## 5 Whys: Customer Orders Delayed

**Problem**: Customer orders are consistently delayed by 2-3 days

**Why #1**: Why are orders delayed?
Answer: Orders sit in queue waiting for processing

**Why #2**: Why do orders sit in queue?
Answer: Processing team is backlogged

**Why #3**: Why is the team backlogged?
Answer: Manual validation of each order takes 30 minutes

**Why #4**: Why does validation take so long?
Answer: Must check 5 different systems for data

**Why #5**: Why must they check 5 different systems?
Answer: Systems are not integrated; no single source of truth

**Root Cause**: Lack of system integration creates manual, time-consuming validation process

**Solution**: Integrate systems to enable automated validation
```

#### Fishbone (Ishikawa) Diagram

Organize potential causes into categories.

```markdown
## Fishbone Diagram: High Customer Complaint Rate

                           People              Process
                            /                    /
              Insufficient training         No quality checks
                          /                    /
              High turnover                Unclear procedures
                        /                    /
                       /                    /
                      /                    /
                     /____________________/
                    /                     \
                   /                       \
                  /                         \
         Poor communication            Outdated system
                /                             \
        No escalation path                 Slow response
              /                                 \
          Methods                              Technology


**Root Causes Identified**:

**People**:
- High turnover rate (50% annually)
- Insufficient training (1 day only)
- Poor communication between shifts

**Process**:
- No quality control checkpoints
- Unclear escalation procedures
- No standard complaint resolution process

**Technology**:
- CRM system outdated (8 years old)
- System response time slow (5+ seconds)
- No mobile access for field staff

**Methods**:
- No structured approach to complaint handling
- Inconsistent documentation
- Lack of follow-up process

**Action Plan**:
Priority 1: Implement quality checkpoints (Process)
Priority 2: Upgrade CRM system (Technology)
Priority 3: Develop comprehensive training (People)
```

### 4.3 Impact Analysis

Impact analysis evaluates consequences of changes.

#### Impact Analysis Template

```markdown
## Impact Analysis: [Change Description]

**Change ID**: CHG-###
**Date**: [Date]
**Analyst**: [Name]
**Requested By**: [Stakeholder]

### Change Summary
[Brief description of proposed change]

### Scope of Impact

**Systems Affected**:
- [System 1] - [High/Medium/Low impact]
- [System 2] - [High/Medium/Low impact]

**Business Processes Affected**:
- [Process 1] - [Description of impact]
- [Process 2] - [Description of impact]

**Stakeholder Groups Affected**:
| Group | Impact Level | Nature of Impact | Mitigation |
|-------|--------------|------------------|------------|
| End Users | High | Must learn new interface | Training program |
| IT Operations | Medium | New monitoring requirements | Documentation |
| Customers | Low | Minimal UI changes | Communication |

### Detailed Impact Analysis

**Functional Impact**:
- **Positive**:
  - [Capability added or improved]
  - [Problem solved]

- **Negative**:
  - [Capability removed or changed]
  - [New limitations]

**Technical Impact**:
- Database schema changes required
- API contracts modified
- Infrastructure scaling needed
- Integration points affected: [List]

**Data Impact**:
- Data migration required: [Yes/No]
- Data volume affected: [Amount]
- Data quality risks: [Description]
- Archive/backup needs: [Requirements]

**Performance Impact**:
- Expected performance change: [Better/Worse/Same]
- Load increase: [Percentage]
- Resource requirements: [CPU/Memory/Storage]

**Security Impact**:
- Security model changes: [Yes/No]
- New vulnerabilities: [Description]
- Compliance implications: [Requirements]

**User Experience Impact**:
- Learning curve: [High/Medium/Low]
- Workflow changes: [Description]
- Training required: [Hours/Days]

### Risk Assessment

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| Data loss during migration | Low | High | Full backup, pilot test |
| User resistance to change | High | Medium | Change management plan |
| Integration failures | Medium | High | Extensive testing, rollback plan |
| Performance degradation | Low | Medium | Load testing, monitoring |

### Dependencies

**Prerequisites**:
- [What must be complete before this change]
- [Required approvals]

**Blocked By**:
- [What would prevent this change]

**Blocks**:
- [What depends on this change]

### Cost-Benefit Analysis

**Costs**:
- Development: $[Amount]
- Testing: $[Amount]
- Training: $[Amount]
- Infrastructure: $[Amount]
- **Total**: $[Amount]

**Benefits**:
- Efficiency gain: [Quantified]
- Cost savings: $[Amount/year]
- Revenue increase: $[Amount/year]
- Risk reduction: [Description]
- **Annual Benefit**: $[Amount]

**ROI**: [Percentage] | **Payback Period**: [Months]

### Implementation Considerations

**Effort Estimate**: [Hours/Days/Weeks]

**Timeline**:
- Analysis: [Timeframe]
- Development: [Timeframe]
- Testing: [Timeframe]
- Training: [Timeframe]
- Deployment: [Timeframe]
- **Total**: [Timeframe]

**Resource Requirements**:
- Developers: [Number] for [Duration]
- Testers: [Number] for [Duration]
- Business Analysts: [Number] for [Duration]

### Recommendations

**Recommendation**: [Approve/Defer/Reject]

**Justification**:
[Reasoning for recommendation based on analysis]

**Conditions** (if approved):
- [Condition 1]
- [Condition 2]

**Alternatives Considered**:
1. [Alternative approach 1] - [Why not chosen]
2. [Alternative approach 2] - [Why not chosen]
```

### 4.4 Cost-Benefit Analysis

#### Cost-Benefit Analysis Template

```markdown
## Cost-Benefit Analysis: [Initiative Name]

**Date**: [Date]
**Analysis Period**: [Number] years
**Analyst**: [Name]

### Executive Summary
[2-3 sentences: What is being analyzed and recommendation]

### Costs (One-Time)

**Development Costs**:
- Requirements & Design: $[Amount]
- Development: $[Amount]
- Testing: $[Amount]
- Project Management: $[Amount]
- **Subtotal**: $[Amount]

**Infrastructure Costs**:
- Hardware: $[Amount]
- Software Licenses: $[Amount]
- Cloud Setup: $[Amount]
- **Subtotal**: $[Amount]

**Change Management Costs**:
- Training Development: $[Amount]
- User Training: $[Amount]
- Communication: $[Amount]
- **Subtotal**: $[Amount]

**Other One-Time Costs**:
- Data Migration: $[Amount]
- Consulting: $[Amount]
- **Subtotal**: $[Amount]

**Total One-Time Costs**: $[Amount]

### Costs (Recurring/Annual)

**Operational Costs**:
- Software Licenses: $[Amount/year]
- Infrastructure: $[Amount/year]
- Support & Maintenance: $[Amount/year]
- **Subtotal**: $[Amount/year]

**Personnel Costs**:
- Additional Staff: $[Amount/year]
- Training (ongoing): $[Amount/year]
- **Subtotal**: $[Amount/year]

**Total Annual Costs**: $[Amount/year]

### Benefits (One-Time)

**Process Improvement**:
- Reduction in backlog: $[Amount]
- Avoided penalties: $[Amount]
- **Subtotal**: $[Amount]

**Total One-Time Benefits**: $[Amount]

### Benefits (Recurring/Annual)

**Efficiency Gains**:
- Time savings: [Hours/week] × [Rate] = $[Amount/year]
- Reduced errors: $[Amount/year]
- Faster processing: $[Amount/year]
- **Subtotal**: $[Amount/year]

**Cost Avoidance**:
- Reduced manual labor: $[Amount/year]
- Lower error correction costs: $[Amount/year]
- Reduced system maintenance: $[Amount/year]
- **Subtotal**: $[Amount/year]

**Revenue Impact**:
- Increased capacity: $[Amount/year]
- New capabilities: $[Amount/year]
- Customer retention: $[Amount/year]
- **Subtotal**: $[Amount/year]

**Risk Reduction**:
- Avoided compliance penalties: $[Amount/year]
- Reduced system downtime: $[Amount/year]
- **Subtotal**: $[Amount/year]

**Total Annual Benefits**: $[Amount/year]

### Financial Analysis

**3-Year Projection**:

| Year | Costs | Benefits | Net Benefit | Cumulative |
|------|-------|----------|-------------|------------|
| 0 | $[Initial] | $0 | $([Initial]) | $([Initial]) |
| 1 | $[Annual] | $[Annual] | $[Net] | $[Cumulative] |
| 2 | $[Annual] | $[Annual] | $[Net] | $[Cumulative] |
| 3 | $[Annual] | $[Annual] | $[Net] | $[Cumulative] |
| **Total** | **$[Total]** | **$[Total]** | **$[Total]** | - |

**Key Metrics**:
- **Net Present Value (NPV)**: $[Amount]
- **Return on Investment (ROI)**: [Percentage]%
- **Payback Period**: [Months]
- **Benefit-Cost Ratio**: [Ratio]:1

**NPV Calculation** (at [X]% discount rate):
```
Year 0: $([Initial cost])
Year 1: $[Net benefit] / 1.10 = $[PV]
Year 2: $[Net benefit] / 1.21 = $[PV]
Year 3: $[Net benefit] / 1.33 = $[PV]
NPV = Sum of above = $[Total NPV]
```

### Qualitative Benefits

**Intangible Benefits** (not quantified above):
- Improved employee morale
- Enhanced customer satisfaction
- Competitive advantage
- Improved decision-making capability
- Future scalability
- Risk mitigation

### Sensitivity Analysis

**Optimistic Scenario** (benefits 20% higher):
- ROI: [Percentage]%
- Payback: [Months]

**Most Likely Scenario** (base case above):
- ROI: [Percentage]%
- Payback: [Months]

**Pessimistic Scenario** (benefits 20% lower):
- ROI: [Percentage]%
- Payback: [Months]

### Risks and Assumptions

**Key Assumptions**:
- [Assumption 1 that impacts calculation]
- [Assumption 2 that impacts calculation]

**Risks to Benefits**:
- [Risk that could reduce benefits]
- [Another risk]

**Mitigation Strategies**:
- [How to address risks]

### Recommendation

**Recommendation**: [Proceed/Don't Proceed/Further Analysis]

**Rationale**:
[Explanation based on financial analysis and qualitative factors]

**Conditions for Approval**:
- [Condition 1]
- [Condition 2]

**Next Steps**:
1. [Step 1]
2. [Step 2]
```

### 4.5 Risk Analysis

#### Risk Analysis Template

```markdown
## Risk Analysis: [Project/Initiative Name]

**Date**: [Date]
**Analyst**: [Name]
**Review Date**: [When to review again]

### Risk Identification

| Risk ID | Category | Description | Source |
|---------|----------|-------------|--------|
| R-001 | Technical | System integration failure | Technical assessment |
| R-002 | Resource | Key developer unavailable | Resource plan |
| R-003 | Business | Requirements change mid-project | Stakeholder interviews |

### Risk Assessment Matrix

**Probability Scale**:
- **High (H)**: >50% chance
- **Medium (M)**: 20-50% chance
- **Low (L)**: <20% chance

**Impact Scale**:
- **High (H)**: >$50K impact or project failure
- **Medium (M)**: $10K-$50K impact or major delay
- **Low (L)**: <$10K impact or minor delay

**Risk Matrix**:
```
          │ Low Impact │ Med Impact │ High Impact
──────────┼────────────┼────────────┼─────────────
High Prob │   Medium   │    High    │    High
          ├────────────┼────────────┼─────────────
Med Prob  │    Low     │   Medium   │    High
          ├────────────┼────────────┼─────────────
Low Prob  │    Low     │    Low     │   Medium
```

### Detailed Risk Register

**Risk R-001: System Integration Failure**

**Category**: Technical
**Probability**: Medium (30%)
**Impact**: High (Could delay launch by 3 months, $150K impact)
**Risk Score**: High
**Owner**: Technical Lead

**Description**:
Third-party system API may not support required functionality or may have performance issues.

**Triggers**:
- API documentation incomplete
- Performance testing reveals issues
- Authentication failures

**Impact Details**:
- 3-month delay to find alternative or build custom solution
- $150K additional development cost
- Potential loss of customer confidence
- May miss market window

**Mitigation Strategy** (Reduce probability/impact):
- Proof of concept with vendor's API (Week 1-2)
- Early performance testing (Week 3-4)
- Identify alternative vendors upfront
- Include fallback option in architecture
- Escalate to vendor technical team early

**Contingency Plan** (If risk occurs):
- Switch to alternative vendor (Vendor B)
- Build custom integration layer (3 weeks, $30K)
- Negotiate with vendor for technical support

**Current Status**: ⚠️ Monitoring (POC in progress)

---

**Risk R-002: Key Developer Unavailability**

**Category**: Resource
**Probability**: Low (15%)
**Impact**: Medium (2-week delay, $20K impact)
**Risk Score**: Low
**Owner**: Project Manager

**Description**:
Lead developer may leave during project or be unavailable due to illness/emergency.

**Mitigation Strategy**:
- Knowledge sharing sessions weekly
- Code reviews for knowledge transfer
- Document complex design decisions
- Cross-train secondary developer
- Maintain good morale and engagement

**Contingency Plan**:
- Promote secondary developer to lead
- Hire contractor with required skills
- Reduce scope to critical features only

**Current Status**: ✅ Under Control

---

**Risk R-003: Requirements Change Mid-Project**

**Category**: Business
**Probability**: High (60%)
**Impact**: Medium (Could add 4 weeks, $40K)
**Risk Score**: High
**Owner**: Business Analyst

**Description**:
Stakeholders may request significant changes after requirements are baselined.

**Mitigation Strategy**:
- Clear change control process
- Regular stakeholder demos (every 2 weeks)
- Sign-off on requirements document
- Prioritize features (MVP vs. nice-to-have)
- Frequent communication of impact of changes

**Contingency Plan**:
- Formal change request process
- Impact analysis required for all changes
- Defer non-critical changes to Phase 2
- Add time buffer to schedule (20%)

**Current Status**: 🔴 High Priority (Managing actively)

### Risk Summary Dashboard

**Risk Distribution**:
- High Priority: 2 risks
- Medium Priority: 3 risks
- Low Priority: 5 risks
- **Total**: 10 risks

**By Category**:
- Technical: 4 risks
- Resource: 2 risks
- Business: 3 risks
- External: 1 risk

**Top 3 Risks** (by risk score):
1. R-001: System Integration Failure
2. R-003: Requirements Change
3. R-005: Data Migration Issues

### Risk Response Budget

**Contingency Reserve**: $75,000
**Management Reserve**: $25,000
**Total Risk Budget**: $100,000

### Risk Monitoring Plan

**Review Frequency**: Bi-weekly at project status meeting

**Escalation Criteria**:
- New high-priority risk identified
- Existing risk probability/impact increases
- Risk occurs

**Reporting**:
- Risk register updated in project management tool
- Top 5 risks reported to steering committee monthly
- Risk trend analysis (improving/stable/worsening)
```

---

## 5. Tools & Deliverables

### 5.1 Business Requirements Document (BRD) Structure

#### BRD Template

```markdown
# Business Requirements Document

**Project Name**: [Project Name]
**Document Version**: [Version]
**Date**: [Date]
**Status**: [Draft/Review/Approved]

**Document Control**:
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 0.1 | [Date] | [Name] | Initial draft |
| 0.2 | [Date] | [Name] | Incorporated feedback |
| 1.0 | [Date] | [Name] | Approved version |

**Approvals**:
| Name | Role | Signature | Date |
|------|------|-----------|------|
| [Name] | Project Sponsor | | |
| [Name] | Business Owner | | |
| [Name] | IT Lead | | |

---

## 1. Executive Summary

### 1.1 Purpose
[1-2 paragraphs: Why this project exists, what problem it solves]

### 1.2 Scope
**In Scope**:
- [Major deliverable 1]
- [Major deliverable 2]

**Out of Scope**:
- [What is explicitly not included]
- [Future phase items]

### 1.3 Expected Benefits
- [Key benefit 1 with quantification]
- [Key benefit 2 with quantification]
- [Key benefit 3 with quantification]

### 1.4 Success Criteria
- [Measurable success criterion 1]
- [Measurable success criterion 2]
- [Measurable success criterion 3]

---

## 2. Business Context

### 2.1 Background
[Current situation, history, why change is needed now]

### 2.2 Business Objectives
| Objective | Measure | Target |
|-----------|---------|--------|
| Improve efficiency | Processing time | Reduce by 50% |
| Increase capacity | Transactions/day | Increase from 100 to 500 |
| Enhance quality | Error rate | Reduce to <1% |

### 2.3 Strategic Alignment
[How this project supports company strategy, goals, initiatives]

---

## 3. Stakeholders

### 3.1 Stakeholder Analysis

| Stakeholder | Role | Interest | Influence | Engagement Strategy |
|-------------|------|----------|-----------|-------------------|
| Jane Smith | Project Sponsor | High | High | Weekly updates, decision involvement |
| Sales Team | End Users | High | Medium | Demos, training, feedback sessions |
| IT Department | Implementers | Medium | High | Regular technical meetings |

### 3.2 Organizational Impact
[Which departments/teams are affected and how]

---

## 4. Current State Assessment

### 4.1 Current Process
[Description or diagram of how things work today]

### 4.2 Current System Capabilities
[What current systems/tools can and cannot do]

### 4.3 Pain Points and Limitations

**Pain Point 1: Manual Data Entry**
- **Description**: Users must re-key data from emails into system
- **Impact**: 2 hours per day per user, 15% error rate
- **Frequency**: Every transaction (200/day)
- **Cost**: $30,000/year in labor + error correction

**Pain Point 2**: [Similar structure]

### 4.4 Current State Metrics
- Average processing time: 45 minutes
- Error rate: 15%
- Customer satisfaction: 6.5/10
- System availability: 95%

---

## 5. Business Requirements

### 5.1 Business Capabilities Required

**BR-001: Automated Data Capture**
- **Description**: System must automatically capture data from email and other sources without manual re-entry
- **Business Value**: Eliminate 2 hours/day manual work per user
- **Priority**: Must Have
- **Success Metric**: 90% of data auto-captured

**BR-002**: [Similar structure for each requirement]

### 5.2 Business Rules

**Rule BR-001**: Orders over $10,000 require manager approval
**Rule BR-002**: Customer credit limit = 2x average monthly purchases (minimum $1,000)
**Rule BR-003**: Refunds must be processed within 5 business days

### 5.3 Business Process Requirements

[Process diagrams or descriptions of required business processes]

---

## 6. Functional Requirements

### 6.1 User Requirements

**As a** Sales Representative
**I need** to view customer order history
**So that** I can provide informed recommendations

**Acceptance Criteria**:
- View last 12 months of orders
- See order status and amount
- Access from mobile device

### 6.2 Functional Requirements Summary

| Req ID | Requirement | Priority | Complexity |
|--------|-------------|----------|------------|
| FR-001 | User login and authentication | Must Have | Medium |
| FR-002 | Dashboard with key metrics | Must Have | High |
| FR-003 | Order entry and validation | Must Have | High |
| FR-004 | Reporting and analytics | Should Have | Medium |

[Detailed FR specifications in separate FRD or appendix]

---

## 7. Non-Functional Requirements

### 7.1 Performance Requirements
- Page load time: < 2 seconds
- System response time: < 1 second
- Support 500 concurrent users

### 7.2 Availability Requirements
- 99.5% uptime during business hours (7am-7pm ET)
- Planned maintenance window: Sundays 1am-5am

### 7.3 Security Requirements
- Multi-factor authentication
- Role-based access control
- All data encrypted at rest and in transit
- Audit trail of all transactions

### 7.4 Compliance Requirements
- GDPR compliant for EU customer data
- SOC 2 Type II certified
- PCI DSS compliant for payment processing

### 7.5 Usability Requirements
- Mobile responsive design
- WCAG 2.1 Level AA accessible
- Support for Chrome, Firefox, Safari, Edge
- Maximum 2 hours training required for new users

---

## 8. Constraints and Assumptions

### 8.1 Constraints
- **Budget**: Maximum $500,000
- **Timeline**: Must launch by Q4 2025
- **Technology**: Must use existing cloud platform (AWS)
- **Compliance**: Must meet industry regulations

### 8.2 Assumptions
- Users have modern web browsers
- Stable internet connectivity available
- Existing systems will remain available
- Stakeholders available for requirements validation

---

## 9. Dependencies

### 9.1 Internal Dependencies
- Customer database migration project (must complete first)
- Network upgrade project (parallel)

### 9.2 External Dependencies
- Third-party payment gateway API
- Vendor software license approval

---

## 10. Risks

[High-level risks - detailed analysis in separate risk register]

| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| Integration failure | High | Medium | Early POC, backup vendor |
| User adoption | Medium | High | Change management, training |

---

## 11. Implementation Approach

### 11.1 Recommended Approach
[High-level: Agile/Waterfall/Hybrid, phased approach]

### 11.2 Project Phases

**Phase 1: Core Functionality** (Month 1-3)
- [Key deliverables]

**Phase 2: Advanced Features** (Month 4-5)
- [Key deliverables]

**Phase 3: Optimization** (Month 6)
- [Key deliverables]

---

## 12. Cost-Benefit Analysis

### 12.1 Estimated Costs
- Development: $300,000
- Infrastructure: $50,000
- Training: $25,000
- **Total**: $375,000

### 12.2 Expected Benefits
- Labor savings: $150,000/year
- Error reduction: $50,000/year
- Revenue increase: $100,000/year
- **Total Annual**: $300,000/year

### 12.3 ROI
- **Payback Period**: 15 months
- **3-Year NPV**: $525,000
- **ROI**: 140%

---

## 13. Success Metrics and KPIs

| Metric | Current | Target | Measurement Method |
|--------|---------|--------|-------------------|
| Processing time | 45 min | 15 min | System logs |
| Error rate | 15% | 2% | Quality reports |
| User satisfaction | 6.5/10 | 8.5/10 | Quarterly survey |
| System uptime | 95% | 99.5% | Monitoring tools |

---

## Appendices

### Appendix A: Glossary
[Define key terms and acronyms]

### Appendix B: References
[Related documents, standards, policies]

### Appendix C: Detailed Requirements
[Link to FRD, use cases, detailed specifications]
```

### 5.2 Functional Requirements Document (FRD)

#### FRD Template

```markdown
# Functional Requirements Document

**Project Name**: [Project Name]
**Related BRD**: [BRD version reference]
**Document Version**: [Version]
**Date**: [Date]

---

## 1. Introduction

### 1.1 Purpose
This document specifies the detailed functional requirements for [system name].

### 1.2 Scope
[What functions/features are detailed in this document]

### 1.3 Audience
- Development team
- QA team
- Business stakeholders

---

## 2. System Overview

### 2.1 System Context
[How this system fits in larger ecosystem, context diagram]

### 2.2 User Roles

| Role | Description | Permissions |
|------|-------------|-------------|
| Administrator | System admin, full access | Create/Read/Update/Delete all |
| Manager | Approves requests, views reports | Read all, Approve, Generate reports |
| User | Daily operations | Create/Read own records, Submit requests |
| Guest | Limited read access | Read public information only |

---

## 3. Functional Requirements

### 3.1 Module: User Authentication

**FR-001: User Login**

**Description**: Users must authenticate before accessing the system.

**Priority**: Must Have
**Complexity**: Medium
**Estimated Effort**: 3 days

**Preconditions**:
- User has valid account
- System is accessible

**Inputs**:
- Username (email format, max 255 chars)
- Password (min 8 chars, max 128 chars)

**Process**:
1. User enters credentials
2. System validates format
3. System checks against user database
4. System verifies password hash
5. System creates session token
6. System redirects to dashboard

**Outputs**:
- Success: Session token, redirect to dashboard
- Failure: Error message, remain on login page

**Business Rules**:
- BR-001: Max 5 failed attempts, then 15-minute lockout
- BR-002: Session expires after 30 minutes of inactivity
- BR-003: Password must meet complexity requirements

**Error Handling**:
- Invalid email format: "Please enter a valid email address"
- Incorrect credentials: "Invalid username or password"
- Account locked: "Account locked due to failed attempts. Try again in X minutes"
- System error: "Unable to process login. Please try again"

**Acceptance Criteria**:
1. Given valid credentials
   When user clicks Login
   Then user is redirected to dashboard
   And session is created

2. Given invalid credentials
   When user clicks Login
   Then error message is displayed
   And user remains on login page

3. Given 5 failed login attempts
   When user tries 6th attempt
   Then account is locked for 15 minutes
   And lockout message is displayed

**UI Mockup**: [Link to wireframe]
**Test Cases**: TC-001 through TC-008

---

**FR-002: Password Reset**

[Similar detailed structure for each functional requirement]

---

### 3.2 Module: Order Management

**FR-050: Create Order**
[Detailed specification]

**FR-051: Update Order**
[Detailed specification]

**FR-052: Cancel Order**
[Detailed specification]

---

## 4. Data Requirements

### 4.1 Data Entities

**Entity: User**

| Field | Type | Required | Validation | Description |
|-------|------|----------|------------|-------------|
| user_id | UUID | Yes | - | Unique identifier |
| email | String(255) | Yes | Valid email format | User's email |
| password_hash | String(255) | Yes | - | Hashed password |
| first_name | String(50) | Yes | Alpha only | User's first name |
| last_name | String(50) | Yes | Alpha only | User's last name |
| role | Enum | Yes | Valid role | User's role |
| created_date | DateTime | Yes | - | Account creation date |
| last_login | DateTime | No | - | Last successful login |
| is_active | Boolean | Yes | - | Account status |

**Entity: Order**
[Similar structure]

---

## 5. Integration Requirements

### 5.1 External Systems

**Integration: Payment Gateway**

**Description**: Process credit card payments through Stripe API

**Endpoint**: https://api.stripe.com/v1/charges
**Method**: POST
**Authentication**: API Key (Bearer token)

**Request**:
```json
{
  "amount": 1000,
  "currency": "usd",
  "source": "tok_visa",
  "description": "Order #12345"
}
```

**Response** (Success):
```json
{
  "id": "ch_1234567",
  "status": "succeeded",
  "amount": 1000
}
```

**Error Handling**:
- Card declined: Notify user, keep order in pending status
- Network timeout: Retry 3 times with exponential backoff
- API error: Log error, notify admin, show user generic error

**SLA**: 95% availability, 2-second response time

---

## 6. Reporting Requirements

**Report: Daily Sales Summary**

**Description**: Shows sales by product category for selected date range

**Parameters**:
- Start Date (required)
- End Date (required)
- Category Filter (optional)

**Data Elements**:
- Date
- Category
- Number of Orders
- Total Sales Amount
- Average Order Value

**Format**: Excel export, PDF view
**Refresh**: Real-time
**Access**: Manager role and above

---

## 7. Validation Rules

| Rule ID | Field | Validation | Error Message |
|---------|-------|------------|---------------|
| VAL-001 | Email | Valid email format | "Please enter a valid email" |
| VAL-002 | Phone | 10 digits, US format | "Phone must be 10 digits" |
| VAL-003 | ZIP Code | 5 or 9 digits | "Invalid ZIP code" |
| VAL-004 | Order Total | Greater than $0 | "Order total must be greater than zero" |

---

## 8. Traceability Matrix

| FR ID | Business Req | Use Case | Design Doc | Test Cases |
|-------|--------------|----------|------------|------------|
| FR-001 | BR-001 | UC-001 | DD-Auth-001 | TC-001 to TC-008 |
| FR-002 | BR-001 | UC-002 | DD-Auth-002 | TC-009 to TC-012 |

---

## Appendices

### Appendix A: Wireframes
[UI mockups and wireframes]

### Appendix B: API Specifications
[Detailed API documentation]

### Appendix C: Database Schema
[Entity-relationship diagram]
```

### 5.3 Data Flow Diagrams

#### DFD Levels

**Level 0 (Context Diagram)**: Shows system as single process with external entities

```markdown
## Context Diagram: Order Management System

```
┌─────────────┐                           ┌──────────────┐
│  Customer   │──── Orders ──────>        │   Payment    │
│             │<─── Confirmation ───      │   Gateway    │
└─────────────┘                           └──────────────┘
                           │                       │
                           ↓                       ↓
                    ┌─────────────────────────────────┐
                    │                                 │
                    │   Order Management System       │
                    │                                 │
                    └─────────────────────────────────┘
                           │                       │
                           ↓                       ↓
┌─────────────┐                           ┌──────────────┐
│  Warehouse  │<─── Pick List ───         │   Inventory  │
│   Staff     │──── Shipment ──────>      │    System    │
└─────────────┘                           └──────────────┘
```
```

**Level 1 (Overview)**: Shows major processes within system

```markdown
## Level 1 DFD: Order Management

```
Customer ──order──> [1.0 Validate Order] ──valid order──> [2.0 Check Inventory]
                            │                                      │
                            │ invalid                              │ available
                            ↓                                      ↓
                     [Error Notification]              [3.0 Process Payment]
                                                               │
                                                               │ approved
                                                               ↓
                                                        [4.0 Fulfill Order]
                                                               │
                                                               ↓
                                                        [5.0 Ship Order]
                                                               │
                                                               ↓
                                                        Customer <──confirmation
```
```

**Level 2 (Detailed)**: Shows sub-processes

```markdown
## Level 2 DFD: Process 3.0 - Process Payment

```
Valid Order ──> [3.1 Calculate Total] ──amount──> [3.2 Apply Discounts]
                                                          │
                                                          ↓
                                               [3.3 Submit to Gateway]
                                                          │
                                   ┌──────────────────────┴────────────────────┐
                                   │                                           │
                              approved                                    declined
                                   │                                           │
                                   ↓                                           ↓
                        [3.4 Record Payment]                        [3.5 Notify Customer]
                                   │
                                   ↓
                        Order Database
```
```

#### DFD Notation

**Processes**: [Process ID.# Process Name]
- Rectangle with rounded corners
- Verb-noun naming

**Data Stores**: ||Store Name||
- Open rectangle
- Noun naming

**External Entities**: □ Entity Name
- Square
- Outside system boundary

**Data Flows**: ──data name──>
- Arrow showing direction
- Named with data being transferred

### 5.4 Entity Relationship Diagrams

#### ERD Example

```markdown
## Entity Relationship Diagram: E-commerce System

```
┌─────────────────┐
│     CUSTOMER    │
├─────────────────┤
│ PK customer_id  │
│    first_name   │
│    last_name    │
│    email        │
│    phone        │
└────────┬────────┘
         │
         │ places (1:M)
         │
         ↓
┌─────────────────┐         ┌─────────────────┐
│     ORDER       │ contains│   ORDER_LINE    │
├─────────────────┤  (1:M)  ├─────────────────┤
│ PK order_id     │───────→ │ PK line_id      │
│ FK customer_id  │         │ FK order_id     │
│    order_date   │         │ FK product_id   │
│    status       │         │    quantity     │
│    total        │         │    unit_price   │
└─────────────────┘         └────────┬────────┘
                                     │
                                     │ references (M:1)
                                     │
                                     ↓
                            ┌─────────────────┐
                            │    PRODUCT      │
                            ├─────────────────┤
                            │ PK product_id   │
                            │    name         │
                            │    description  │
                            │    price        │
                            │    stock_qty    │
                            └─────────────────┘
```

**Relationship Types**:
- 1:1 (One-to-One)
- 1:M (One-to-Many)
- M:M (Many-to-Many) - requires junction table

**Cardinality Notation**:
- │ (one and only one)
- ○─ (zero or one)
- ├─ (one or many)
- ○< (zero or many)
```

#### ERD with Attributes

```markdown
## Detailed ERD

CUSTOMER ||──o{ ORDER : places
CUSTOMER {
    uuid customer_id PK
    string email UK "NOT NULL"
    string password_hash "NOT NULL"
    string first_name
    string last_name
    string phone
    datetime created_at
    boolean is_active "DEFAULT TRUE"
}

ORDER ||──o{ ORDER_LINE : contains
ORDER {
    uuid order_id PK
    uuid customer_id FK
    datetime order_date "DEFAULT NOW()"
    string status "DEFAULT 'pending'"
    decimal total_amount
    string shipping_address
    string payment_method
}

ORDER_LINE }o──|| PRODUCT : references
ORDER_LINE {
    uuid line_id PK
    uuid order_id FK
    uuid product_id FK
    int quantity "CHECK > 0"
    decimal unit_price
    decimal subtotal
}

PRODUCT {
    uuid product_id PK
    string sku UK "NOT NULL"
    string name "NOT NULL"
    text description
    decimal price "CHECK >= 0"
    int stock_quantity "DEFAULT 0"
    string category
    boolean is_active "DEFAULT TRUE"
}
```

---

## Best Practices Summary

### Requirements Gathering
1. Engage stakeholders early and often
2. Use multiple elicitation techniques
3. Validate and verify requirements
4. Document assumptions explicitly
5. Prioritize ruthlessly

### Process Modeling
1. Start high-level, then detail
2. Use standard notation (BPMN)
3. Validate with process owners
4. Show both as-is and to-be
5. Identify metrics for improvement

### Requirements Documentation
1. Write clear, testable requirements
2. Use consistent templates
3. Maintain traceability
4. Version control all documents
5. Get formal approval

### Analysis
1. Data-driven decision making
2. Consider multiple perspectives
3. Quantify impacts where possible
4. Document assumptions and risks
5. Present recommendations clearly

### Deliverables
1. Tailor to audience
2. Use visuals effectively
3. Keep documents current
4. Link related artifacts
5. Follow organizational standards

---

**End of Business Analysis Skill**

This comprehensive skill covers all major aspects of business analysis from requirements gathering through deliverable creation. Use these patterns, templates, and techniques to deliver professional business analysis work.