Traditional Business Analyst

Role Definition

The Traditional Business Analyst represents the foundational form of the profession, focusing on comprehensive requirements gathering, documentation, and stakeholder facilitation within structured project environments. These BAs typically work in Waterfall or hybrid methodologies where upfront planning and detailed specifications precede development work. They excel at creating order from complexity, translating vague business needs into precisely defined requirements that development teams can implement.

Traditional BAs often serve as the primary liaison between business stakeholders and technical teams throughout a project's lifecycle. They conduct formal requirements workshops, document business processes using standardised notation, create functional specifications, and manage requirements traceability from initial conception through user acceptance testing. This role demands exceptional communication skills, meticulous attention to detail, and the ability to navigate organisational politics whilst maintaining neutral objectivity.

The term "traditional" doesn't imply obsolescence—many organisations, particularly in regulated industries, government, and large enterprises, continue to require this structured approach. Complex systems integration projects, regulatory compliance initiatives, and enterprise resource planning implementations benefit from the rigour traditional BAs provide. Understanding this foundational role remains valuable even for BAs who eventually specialise in other areas, as it establishes core competencies that transfer across all BA types.

Traditional BAs carry responsibility for the complete requirements lifecycle, beginning with initial stakeholder engagement and concluding with solution validation. Their day-to-day work centres on elicitation activities—conducting interviews, facilitating workshops, observing current processes, and reviewing existing documentation to understand business needs comprehensively. They document these findings in Business Requirements Documents (BRDs), Functional Requirements Specifications (FRS), and Use Case descriptions that follow standardised templates and organisational conventions.

Engagement Types

Typical Projects & Deliverables

Traditional BAs engage with projects that benefit from comprehensive upfront planning and detailed documentation. Enterprise system implementations—such as customer relationship management (CRM) platforms, enterprise resource planning (ERP) systems, or core banking solutions—frequently employ traditional BAs to document complex requirements across multiple business units. These large-scale initiatives might span 12–24 months, require coordination among dozens of stakeholders, and necessitate extensive change management.

Regulatory compliance projects represent another common engagement type. When organisations must implement new regulatory requirements—data protection regulations, financial reporting standards, or industry-specific compliance mandates—traditional BAs document current processes, identify gaps against regulatory requirements, and specify changes needed for compliance. The structured, auditable nature of traditional BA work suits these contexts where documentation rigour directly impacts regulatory approval.

Business process re-engineering initiatives leverage traditional BA skills to analyse existing workflows, identify inefficiencies, and design improved processes. These projects might aim to reduce operational costs, improve customer experience, or integrate processes following a merger. The BA facilitates current-state documentation workshops, analyses process metrics to identify bottlenecks, designs future-state processes, and documents transition requirements.

Common Deliverables

Core Competencies

Required Skills

Traditional BAs require a balanced skill portfolio spanning technical comprehension, business acumen, and interpersonal effectiveness. Whilst they don't write code, they must understand technology sufficiently to bridge conversations between business stakeholders and development teams. This technical literacy includes comprehending database concepts, understanding systems architecture at a conceptual level, and grasping how different technologies enable business capabilities.

Communication Excellence

Communication skills sit at the absolute core of traditional BA work. The ability to conduct effective interviews that uncover unstated assumptions, facilitate workshops that build consensus among competing priorities, write clearly and concisely for diverse audiences, and present complex information in accessible ways determines success in this role. Traditional BAs spend 60–70% of their time in communication activities—meetings, documentation, presentations, and stakeholder engagement.

Analytical Capabilities

Analytical capabilities enable BAs to decompose complex problems, identify patterns across stakeholder inputs, recognise gaps in requirements, and think critically about business processes. They must apply structured analysis techniques—such as SWOT analysis, root cause analysis, and gap analysis—to move beyond symptoms to underlying issues. This analytical thinking manifests in questioning assumptions, validating stated requirements against business objectives, and identifying edge cases that stakeholders might overlook.

Domain Knowledge

Domain knowledge—understanding the business context, industry dynamics, and organisational culture—grows increasingly valuable with experience. Whilst entry-level BAs might lack deep domain expertise, they quickly develop understanding of their organisation's products, customers, competitive landscape, and operational realities. This contextual knowledge enables more insightful requirements elicitation, as experienced BAs anticipate needs stakeholders haven't articulated.

Progression

Career Path

Traditional BA careers typically follow a progression from junior analyst through senior BA roles, potentially advancing into business analysis management, product ownership, or strategic consulting positions. Entry-level BAs often begin by supporting senior analysts—documenting meeting notes, creating first drafts of requirements documents, conducting research, and handling administrative aspects of requirements management.

As BAs gain experience, they take ownership of increasingly complex requirements areas. A mid-level BA might independently manage requirements for a specific business unit or system module whilst senior BAs often coordinate requirements across multiple workstreams, mentor junior team members, and engage directly with executive stakeholders. The progression reflects growing capability to handle ambiguity, political complexity, and strategic thinking.

Beyond individual contributor roles, experienced traditional BAs can move into BA management (leading teams of analysts), programme-level BA roles (coordinating requirements across multiple related projects), business architecture (defining organisational capabilities and information architecture), or product management (owning product strategy and roadmap). Some transition into project management, leveraging their stakeholder management skills and project exposure, whilst others move into quality assurance leadership or business operations roles.

Real-World Context

A Day in the Life

Sarah, a traditional BA working for a retail organisation, arrives at her desk and reviews her calendar: morning requirements review meeting, lunch with the project manager, afternoon workshop with warehouse operations, and dedicated time for documentation. Her project involves implementing a new inventory management system, and she's currently in the requirements gathering phase.

The morning meeting brings together IT stakeholders and her project manager to review draft functional requirements she documented last week. Sarah walks through each requirement, explaining the business rationale behind specific system behaviours. The technical architect questions how one requirement integrates with existing systems; Sarah notes this as a clarification point requiring follow-up with the integration team. By meeting's end, they've agreed on 23 requirements with five flagged for additional investigation.

After lunch, Sarah facilitates a two-hour workshop with six warehouse supervisors and the operations manager. She's prepared process maps showing current receiving procedures and wants to validate her understanding whilst identifying pain points. Using a shared screen, she walks through the as-is process, pausing at each decision point to confirm accuracy. The supervisors highlight manual workarounds they've developed because the current system lacks certain functionality—these workarounds become requirements for the new system. Sarah captures these insights on sticky notes in the virtual whiteboard, grouping related points and asking clarifying questions about frequency, impact, and priority.

Her afternoon documentation time transforms workshop insights into structured requirements. She updates her requirements document with seven new functional requirements, each following her organisation's template: requirement ID, description, business rationale, priority, and acceptance criteria. For each requirement, she considers which other requirements it depends on and updates her traceability matrix. She drafts questions for follow-up with two supervisors about edge cases they mentioned but didn't fully explain.

Before day's end, Sarah prepares for tomorrow's stakeholder review by creating a presentation summarising requirements gathered so far, highlighting areas of uncertainty, and proposing next steps. She reviews her requirements backlog—34 requirements documented, 12 awaiting stakeholder validation, 7 requiring technical feasibility assessment. The systematic, structured nature of her work reflects traditional BA practice at its core.