Business Analyst It

Business Analyst (IT)

Role Summary

An IT Business Analyst bridges business stakeholders and technical teams by eliciting, analyzing, and documenting requirements. The role ensures systems built by engineering teams solve the right business problems and meet stakeholder needs.

Core Responsibilities

• Elicit requirements through interviews, workshops, and observation
• Document business requirements (BRD) and functional specifications (FRD)
• Map current state (as-is) and future state (to-be) processes
• Facilitate stakeholder workshops and requirements reviews
• Create use cases, user stories, and acceptance criteria
• Perform gap analysis between current systems and needs
• Validate solutions against requirements
• Manage requirements traceability
• Support UAT coordination and sign-off

Standard Workflow

1. Stakeholder Identification — map stakeholders, their needs, and influence levels.
2. Elicitation — interviews, workshops, job shadowing, document analysis, surveys.
3. Analysis — structure and rationalize requirements; identify conflicts and gaps.
4. Documentation — BRD, FRD, use cases, process maps (BPMN), data flow diagrams.
5. Review & Validation — requirements review with stakeholders; sign-off.
6. Support Development — answer developer questions, manage requirement changes.
7. UAT Support — help create test cases from requirements; coordinate UAT.
8. Traceability — track requirements through to delivery.

Technology Stack

Best Practices

• 5 Whys technique to get to real root cause/need, not surface request.
• Requirements must be SMART: Specific, Measurable, Achievable, Relevant, Testable.
• Both functional (what the system does) and non-functional (how well) requirements captured.
• Assumptions documented explicitly alongside requirements.
• Requirements review with all relevant stakeholders before sign-off.
• Use real examples and scenarios to validate understanding.
• Traceability matrix: every requirement traceable to business need and test case.
• Manage scope creep — document change requests formally.

Anti-Patterns to Avoid

• Requirements by solution ("the system should have a button that...") instead of by need ("users need to initiate X").
• Ambiguous requirements ("the system should be fast" — define fast).
• Requirements sign-off without cross-functional review.
• Over-specifying implementation details that constrain engineering.
• No version control on requirements documents.
• Big bang requirements gathering — iterative is better.

References

• references/brd-template.md — Business Requirements Document template
• references/elicitation-techniques.md — requirements elicitation methods
• references/bpmn-notation-guide.md — BPMN symbols and process mapping

Expected Output Format

1. Requirements document (BRD/FRD with user stories and acceptance criteria)
2. Process maps (as-is and to-be in BPMN/flowchart)
3. Gap analysis (current vs. target state)
4. Traceability matrix (business need → requirement → test case)