Business Analyst

Aon is hiring a Business Analyst in Gurugram, India. Level rates it ; you can apply on Aon.

Level's read on this job

Level rates this business analyst role Little AI ●○○○: aI is not part of the work.
Level classes it as a mid-level role.
Aon has 1,000+ other open roles on Level.

AI in this role

Title- : Business Analyst Position type- Full Time Work Location- Gurgaon Working style- Hybrid Shift Time- 10PM to 7PM People Manager role: No Required education and certifications critical for the role- bachelor’s degree in engineering, Computer Science, Information Technology, Analytics, Data Science, Business, or related field. Required years of experience – 4-6 years of work experience Job in relevant field AON IS IN THE BUSINESS OF BETTER DECISIONS At Aon, we shape decisions for the better to protect and enrich the lives of people around the world. As an organization, we are committed to our purpose as one firm, united through trust as one inclusive, diverse team and we are passionate about helping our colleagues and clients succeed. GENERAL DESCRIPTION OF ROLE: About the Role As a Business Analyst within the Assessment Solutions business, you will own the translation of business and product needs into clear, structured requirements that engineering teams can design and build from. The Aon Assessment Platform is the enterprise solution for accurate and fair workforce assessments at scale, used by millions of participants worldwide — and the quality of what engineering delivers depends heavily on the quality of what goes into the pipeline. You are the primary bridge between product stakeholders, business owners, and the engineering group. Your central deliverable is the Product Requirement Definition (PRD) document: a clear, well-structured articulation of what needs to be built, why, and within what constraints — including acceptance criteria that QA and engineers can actually test against. Engineering Team Leads and Solution Architects take your PRDs as their starting point; if requirements are ambiguous, incomplete, or contradictory, the cost shows up in rework, delayed delivery, and misaligned solutions. This role demands rigour, curiosity, and strong analytical thinking. Our platform is large and deeply interconnected; understanding the downstream impact of a new requirement — on existing workflows, integrations, data structures, and non-functional behaviour — is as important as capturing the requirement itself. Key Responsibilities Requirements Elicitation & Analysis Lead requirements elicitation sessions with product owners, business stakeholders, and subject matter experts — translating business needs, user journeys, and product vision into structured, implementation-ready requirements. Analyse incoming requests critically: identify ambiguities, contradictions, and missing detail before handing requirements to engineering — not after design has begun. Map the impact of new requirements on existing platform features, integrations, and data flows; surface dependencies and risks that stakeholders may not have considered. Distinguish clearly between business requirements, functional requirements, and non-functional requirements (performance, accessibility, security, data privacy) — ensuring all are captured, not just the functional happy path. PRD Authorship & Maintenance Author and maintain Product Requirement Definition (PRD) documents that Engineering Team Leads and Solution Architects can translate into Technical Specification Documents (TSDs) with confidence. Write acceptance criteria that are specific, testable, and unambiguous — criteria that QA can use directly to build test cases without requiring interpretation. Maintain a clear, versioned record of requirement decisions and changes — documenting the rationale behind scope inclusions and exclusions so that context is not lost as delivery progresses. Ensure PRDs account for the full scope of a feature: not just the core user journey but edge cases, error states, integration behaviour, and non-functional expectations. Stakeholder Management & Communication Manage a diverse stakeholder group across product, commercial, operations, and technology — building trusted relationships and navigating competing priorities effectively. Facilitate workshops and collaborative sessions to align stakeholders on requirements, priorities, and tradeoffs — driving decisions rather than documenting disagreements. Communicate requirement status, risks, and dependencies clearly to both technical and non-technical audiences. Work effectively in an international environment across time zones and cultures (our squads span Germany and India). Delivery Collaboration Partner closely with Engineering Team Leads, Solution Architects, QA, and Project Managers throughout delivery — answering clarification questions quickly, managing scope change, and ensuring the team always has the information it needs to move forward. Support the QA team in translating acceptance criteria into test coverage, and participate in acceptance testing to validate that delivered features meet the original intent. Contribute to sprint planning and backlog refinement — ensuring stories are well-formed, appropriately sized, and ready for engineering commitment. Proactively raise scope creep, unplanned dependencies, and requirement changes that affect delivery timelines — giving the project manager the visibility needed to manage accordingly. Continuous Improvement Identify patterns across requirements that point to recurring business pain points or missing platform capabilities — feeding these back into product planning. Evolve BA practices, templates, and tooling within the team to improve the consistency and quality of requirements over time. Use AI tools in your day-to-day work — for requirements drafting, gap analysis, acceptance criteria generation, and documentation — and apply them effectively and responsibly. This is a core expectation, not a nice-to-have. Required Skills & Experience 4–6 years of experience as a Business Analyst or Product Analyst in a software product or SaaS environment — experience working directly with engineering teams as part of an Agile delivery process. Proven ability to produce high-quality PRDs and functional specifications: clear, complete, and structured well enough that engineers can design from them without requiring repeated clarification. Strong analytical thinking — able to map complex workflows, identify dependencies and edge cases, and reason about the downstream impact of requirements on an interconnected platform. Demonstrated experience writing testable acceptance criteria that QA teams can work from directly. Excellent stakeholder management skills: able to navigate competing priorities, drive decisions in workshops, and maintain trusted relationships across business and technical audiences. Solid understanding of Agile delivery practices and how BA work fits within sprint cycles and release planning. Strong written and verbal communication skills for an international team — clear, precise, and comfortable adapting tone for technical and non-technical audiences. Organised and self-directed: able to manage multiple concurrent requirements streams without losing track of quality or detail. Day-to-day use of AI tools in analytical and documentation work. This is a core expectation, not a nice-to-have. Nice to Have Experience working in HR technology, talent assessment, recruitment, or a related domain. Familiarity with API-driven product behaviour and integration requirements — able to specify data exchange, field mappings, and integration acceptance criteria clearly. Exposure to non-functional requirements in large-scale platforms: performance, accessibility (WCAG), data privacy (GDPR), and security considerations. Experience with enterprise ATS platforms (Workday, SAP SuccessFactors, Taleo, or equivalent) from a functional or integration requirements perspective. Working knowledge of SQL at a query-reading level — able to validate data behaviour during acceptance testing without requiring engineering support for every check. Experience with requirements and collaboration tooling (Confluence, Jira, or equivalent). 2584002

How we rate this

Business Analyst at Aon rates 37 out of 100 for how much of the daily work is AI. That makes it Little AI (AI Level 1 of 4). The level is about AI in the job, not seniority.

Classification

Little AI. AI is not part of the work.

●●●● Builds AI80 to 100
●●●○ Works on AI60 to 79
●●○○ Uses AI40 to 59
●○○○ Little AI0 to 39

Levels come from how often the tools, models and workflows of the role are named in the posting itself. Read the description and count the AI tools, models and workflows it names.