# BA Best Practices

> Apply industry best practices in business analysis work including requirements quality, documentation standards, and collaboration techniques

- Skill: `danhvb/ba-best-practices` (Agent Skill)
- Install (CLI): `npx skillmds@latest add danhvb/ba-best-practices`
- Raw SKILL.md: https://api.skillmd.com/api/skills/danhvb/ba-best-practices/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: danhvb (https://skillmd.com/u/danhvb)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/danhvb/ba-best-practices

---


# BA Best Practices Skill

## Purpose
Guide AI assistants in applying professional BA best practices to ensure high-quality requirements, effective collaboration, and successful project outcomes.

## Requirements Quality Attributes

### 1. Clear
- Use simple, unambiguous language
- Avoid jargon without definition
- One requirement per statement
- Specific and concrete

❌ Bad: "System should be user-friendly"
✅ Good: "System shall complete checkout process in maximum 3 clicks"

### 2. Complete
- All necessary information included
- Edge cases addressed
- Exceptions documented
- Success and failure scenarios covered

### 3. Consistent
- No contradictions with other requirements
- Consistent terminology throughout
- Aligned with business objectives
- Follows documentation standards

### 4. Testable
- Can be verified through testing
- Measurable acceptance criteria
- Observable outcomes
- Objective pass/fail determination

❌ Bad: "System should load quickly"
✅ Good: "System shall load homepage in < 3 seconds on 4G connection"

### 5. Traceable
- Linked to business need
- Source documented
- Unique identifier
- Impact analysis possible

### 6. Feasible
- Technically achievable
- Within budget constraints
- Realistic timeline
- Resources available

## Documentation Standards

### Naming Conventions

**Requirements IDs**:
- Format: [TYPE]-[MODULE]-[NUMBER]
- Examples: FR-AUTH-001, NFR-PERF-005, BR-PRICING-003

**Documents**:
- BRD_ProjectName_v1.0.pdf
- FRS_ModuleName_v2.1.pdf
- UseCases_FeatureName_v1.0.pdf

### Version Control

**Semantic Versioning**:
- Major.Minor.Patch (1.0.0)
- Major: Significant changes, restructuring
- Minor: New sections, requirements added
- Patch: Corrections, clarifications

**Change Log**:
| Date | Version | Author | Changes | Reason |
|------|---------|--------|---------|--------|
| 2026-01-15 | 1.0 | John | Initial | New project |
| 2026-01-20 | 1.1 | Jane | Added FR-005-010 | Stakeholder feedback |

### Document Structure

**Standard Sections**:
1. Document Control (version, approvals, distribution)
2. Table of Contents
3. Introduction (purpose, scope, audience)
4. Main Content
5. Appendices (glossary, references, diagrams)

## Requirements Traceability Matrix (RTM)

**Purpose**: Link requirements to business needs, design, and tests

| Req ID | Business Need | Design Element | Test Case | Status |
|--------|---------------|----------------|-----------|--------|
| FR-001 | BN-001 | DES-UI-001 | TC-001, TC-002 | Implemented |
| FR-002 | BN-001 | DES-API-003 | TC-003 | In Progress |

**Benefits**:
- Ensure all business needs addressed
- Impact analysis for changes
- Test coverage verification
- Audit trail

## Change Management

### Change Request Process

1. **Request Submission**
   - Change description
   - Business justification
   - Impact assessment
   - Priority

2. **Impact Analysis**
   - Requirements affected
   - Design impact
   - Development effort
   - Testing impact
   - Timeline impact
   - Cost impact

3. **Review & Approval**
   - Change Control Board (CCB) review
   - Stakeholder approval
   - Budget approval (if needed)

4. **Implementation**
   - Update requirements
   - Update design
   - Communicate changes
   - Update traceability

5. **Verification**
   - Validate changes implemented correctly
   - Update documentation
   - Close change request

### Change Request Template

```markdown
# Change Request CR-001

**Date**: 2026-01-20
**Requested By**: Marketing Manager
**Priority**: High

## Change Description
Add social login (Google, Facebook) to registration process

## Business Justification
- Reduce registration friction
- Increase conversion by estimated 25%
- Competitive parity

## Impact Analysis
**Requirements**: Add FR-AUTH-015, FR-AUTH-016
**Design**: New OAuth integration components
**Development**: 2 weeks (40 hours)
**Testing**: 1 week UAT
**Timeline**: Delay release by 2 weeks
**Cost**: $8,000

## Approval
- [ ] Product Owner
- [ ] Technical Lead
- [ ] Project Manager

## Decision
☐ Approved  ☐ Rejected  ☐ Deferred

**Reason**: _____________________
```

## Review & Approval Workflows

### Requirements Review Checklist

**Content Review**:
- [ ] All requirements follow quality attributes
- [ ] Business rules clearly documented
- [ ] Assumptions explicitly stated
- [ ] Constraints identified
- [ ] Dependencies mapped
- [ ] Acceptance criteria defined

**Technical Review**:
- [ ] Technically feasible
- [ ] Integration points identified
- [ ] Performance requirements realistic
- [ ] Security requirements addressed
- [ ] Scalability considered

**Business Review**:
- [ ] Aligned with business objectives
- [ ] Business value clear
- [ ] Stakeholder needs addressed
- [ ] Priorities appropriate
- [ ] Budget and timeline realistic

### Approval Levels

| Document Type | Approvers | Timeline |
|---------------|-----------|----------|
| BRD | Business Owner, Product Manager, Finance | 1 week |
| FRS | Technical Lead, Architect, BA | 3 days |
| User Stories | Product Owner, Scrum Master | 1 day |
| Change Requests | CCB, Affected Stakeholders | 2-5 days |

## Communication Best Practices

### Stakeholder Communication

**Frequency**:
- Executive: Monthly status updates
- Product Owner: Weekly sync
- Development Team: Daily standup, sprint ceremonies
- End Users: Milestone demos, UAT sessions

**Communication Channels**:
- **Formal**: Email, official documents, presentations
- **Informal**: Chat (Slack, Teams), quick calls
- **Collaborative**: Workshops, working sessions
- **Broadcast**: Newsletters, town halls

### Meeting Best Practices

**Before Meeting**:
- Clear agenda sent 24 hours ahead
- Pre-read materials shared
- Objectives defined
- Right participants invited

**During Meeting**:
- Start and end on time
- Follow agenda
- Take notes and action items
- Encourage participation
- Park off-topic items

**After Meeting**:
- Share notes within 24 hours
- Distribute action items with owners and due dates
- Follow up on commitments

## Collaboration Techniques

### Hybrid Team Collaboration

**Challenges**:
- Time zone differences
- Communication gaps
- Tool fragmentation
- Cultural differences

**Solutions**:
- Overlap hours for real-time collaboration
- Async communication (Lark, Notion)
- Single source of truth for documentation
- Regular video calls for relationship building
- Clear documentation of decisions

### Conflict Resolution

**When stakeholders disagree**:

1. **Understand Both Perspectives**
   - Listen actively to each side
   - Ask clarifying questions
   - Document concerns

2. **Find Common Ground**
   - Identify shared objectives
   - Focus on business value
   - Separate positions from interests

3. **Explore Options**
   - Brainstorm alternatives
   - Consider compromises
   - Evaluate trade-offs

4. **Use Data**
   - Customer feedback
   - Analytics
   - Competitive analysis
   - Cost-benefit analysis

5. **Escalate if Needed**
   - Document the conflict
   - Present options with pros/cons
   - Let decision-maker decide
   - Accept and move forward

## Common Pitfalls & How to Avoid

### Pitfall 1: Gold Plating
**Problem**: Adding unnecessary features
**Solution**: Always tie requirements to business value, challenge "nice-to-haves"

### Pitfall 2: Scope Creep
**Problem**: Uncontrolled growth of requirements
**Solution**: Formal change management process, clear scope boundaries

### Pitfall 3: Analysis Paralysis
**Problem**: Over-analyzing, never finishing
**Solution**: Time-box analysis, "good enough" vs. perfect, iterative approach

### Pitfall 4: Assuming Understanding
**Problem**: Not validating requirements with stakeholders
**Solution**: Always confirm understanding, use prototypes, get sign-off

### Pitfall 5: Ignoring Non-Functional Requirements
**Problem**: Focus only on features, ignore performance, security
**Solution**: Explicitly elicit NFRs, include in DoD

### Pitfall 6: Poor Documentation
**Problem**: Incomplete, outdated, or unclear documentation
**Solution**: Documentation standards, version control, regular reviews

### Pitfall 7: Weak Stakeholder Engagement
**Problem**: Stakeholders not involved or committed
**Solution**: Regular communication, show value, involve in decisions

## Continuous Improvement

### Retrospectives

**After Each Project/Sprint**:
- What went well?
- What could be improved?
- What will we do differently?
- Action items for improvement

### Metrics to Track

**Requirements Quality**:
- % requirements changed after approval
- # defects traced to requirements
- Requirements review cycle time

**Stakeholder Satisfaction**:
- Survey scores
- Feedback themes
- Engagement levels

**Delivery**:
- % requirements delivered on time
- % requirements delivered in scope
- Rework rate

### Professional Development

**Certifications**:
- CBAP (Certified Business Analysis Professional)
- PMI-PBA (Professional in Business Analysis)
- IIBA Certifications
- Agile certifications (CSPO, CSM)

**Continuous Learning**:
- Industry conferences
- Webinars and workshops
- Professional communities
- Reading (BABOK, industry blogs)

## Tools & Templates

### Recommended Tools

**Documentation**:
- Lark Docs (collaborative)
- Notion (knowledge base)
- Confluence (enterprise)

**Diagrams**:
- Figma (UI/UX)
- Miro (collaboration)
- Lucidchart (process flows)
- Mermaid (code-based diagrams)

**Requirements Management**:
- Jira (Agile)
- Azure DevOps
- Lark Base (flexible)

**Communication**:
- Lark (all-in-one)
- Slack/Teams (chat)
- Zoom (video)

## References

- BABOK® Guide (IIBA)
- PMI-PBA Handbook
- Agile Extension to BABOK®
- IEEE 29148 Standards
- Requirements Engineering by Klaus Pohl