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:

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

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

# 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

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