Business analysis and requirements gathering

In short

Business analysis is the work of understanding a business problem, identifying who is affected and defining what a software system must do to solve it; requirements gathering (elicitation) is the step in which those needs are drawn out of stakeholders and documented. It is the first and cheapest place to catch a defect - an error found in requirements costs a fraction of what the same error costs after release - so it decides whether a project is deemed successful. Indian university syllabi examine it under Software Engineering as requirement engineering, the SRS and IEEE 830 structure, use cases and DFDs; GATE CSE/IT touches it lightly through SDLC and models. In industry it is the daily work of Business Analysts, Functional Consultants and Product Owners at TCS, Infosys, Wipro, Accenture, Cognizant, Capgemini and every product company, and placement interviews routinely ask the difference between functional and non-functional requirements, between BRD and FRD, and how you would elicit requirements from a reluctant client.

Explained

What business analysis is, and the BA role

• Business analysis: identifying business needs and recommending solutions that deliver value - the solution may be software, a process change, training or buying a product, not necessarily new code.
• Requirement: a documented, testable statement of a capability or condition the system or organisation must satisfy.
• Requirement engineering is the whole discipline: elicitation → analysis → specification → validation → management.
• BABOK (Business Analysis Body of Knowledge, IIBA) is the reference framework; its knowledge areas include planning and monitoring, elicitation and collaboration, requirements life-cycle management, strategy analysis, requirements analysis and design definition, and solution evaluation. Certifications: ECBA, CCBA, CBAP (IIBA) and PMI-PBA.
• Levels of requirement:
  • Business requirement - why the organisation is doing this ("cut invoice processing time by 40%").
  • Stakeholder/user requirement - what a particular user needs ("a clerk must see all pending invoices for a vendor").
  • Solution requirement - functional and non-functional behaviour of the system.
  • Transition requirement - temporary needs: data migration, parallel run, training (dropped after go-live).
• Titles in Indian IT: Business Analyst, Functional Consultant (SAP/Oracle/Salesforce), Product Owner, Systems Analyst, Pre-sales Consultant, Domain Consultant (BFSI, insurance, telecom, healthcare).

Types and classification of requirements

• Functional requirements (FR): what the system does - inputs, processing, outputs. "The system shall calculate GST at the rate applicable to the item's HSN code."
• Non-functional requirements (NFR) / quality attributes: how well it does it. Commonly examined set:
  • Performance - response time, throughput ("search returns in under 2 seconds for 95% of queries").
  • Scalability, capacity - concurrent users, data volume growth.
  • Availability and reliability - uptime %, MTBF, MTTR, RPO/RTO for disaster recovery.
  • Security - authentication, authorisation, encryption, audit trail.
  • Usability and accessibility - learnability, language support, WCAG/GIGW conformance for government sites.
  • Maintainability, portability, interoperability, compliance, localisation.
• Domain requirements: imposed by the application area (an accounting system must follow double entry; a bank must run end-of-day settlement).
• Constraints: non-negotiable boundaries - technology stack mandated by the client, budget, go-live date, data to stay in India.
• Business rules: policy statements that outlive any one system ("a purchase order above ₹5 lakh needs two approvals") - documented separately so they can change without rewriting the specification.
• Assumptions and dependencies: taken as true but unverified; a wrong assumption is a project risk.
• Explicit vs implicit (implied): implicit requirements are expected even if never stated (a login screen must mask the password).
• Normal / expected / exciting (Kano model): expected requirements cause dissatisfaction only when absent; exciting ones delight if present.

Elicitation techniques - and when each is right

1. Interviews - structured (fixed questionnaire) or unstructured (open). Best for depth and for senior stakeholders; expensive in time. Use open questions, avoid leading the witness, send notes back for confirmation.
2. Questionnaires/surveys - cheap and wide; good when users are many and geographically spread (e.g. a state-wide portal); poor at probing "why".
3. Workshops / JAD (Joint Application Development) - facilitated session with users, BA, designer and decision-maker in one room; resolves conflicts fast; needs a skilled facilitator and a scribe.
4. Observation (ethnography / job shadowing) - watch the actual work; surfaces tacit knowledge and workarounds users never mention. Active (ask while watching) or passive.
5. Document analysis - study existing forms, reports, circulars, legacy screens, SOPs; essential in legacy replacement work.
6. Prototyping - throwaway, evolutionary or wireframes/mock-ups; the best cure for "I'll know it when I see it"; risk is the client mistaking the prototype for a finished product.
7. Brainstorming - generate options without criticism, then converge.
8. Focus groups - a representative set of users reacting to a concept.
9. Reverse engineering - deriving requirements from an existing system when documentation is lost.
10. Interface analysis - identifying every external system, file or API the solution must talk to.
11. Benchmarking / competitive analysis - compare with competitor products or peer institutions.
12. Backlog refinement and user story workshops - the agile equivalent of JAD, run continuously.
13. Choosing: many stakeholders and little time → survey + workshop; conflicting departments → workshop; unclear or undocumented process → observation + document analysis; fuzzy vision → prototype.

The process, step by step

1. Define the problem and scope - problem statement, objectives, measurable success criteria; a context diagram fixes what is in and out of scope.
2. Stakeholder analysis - list everyone affected: sponsor, end users, SME, regulator, auditor, operations, vendor, support. Classify on a power/interest grid (manage closely, keep satisfied, keep informed, monitor); name a single decision-maker; RACI for who is Responsible, Accountable, Consulted, Informed.
3. Plan elicitation - technique per stakeholder group, calendar, questions, logistics.
4. Elicit - run the sessions; record raw notes.
5. Analyse and model - group, de-duplicate, remove ambiguity, resolve conflicts; model with use cases, user stories, DFDs, ER diagrams, process flows (AS-IS and TO-BE), BPMN swimlanes, state machines, decision tables, CRUD matrix.
6. Prioritise - MoSCoW, Kano, value-vs-effort, weighted scoring, 100-point method.
7. Specify - write the BRD / FRD / SRS or the product backlog with acceptance criteria.
8. Validate and verify - reviews, walkthroughs, inspections, prototype demos, checklist against the quality criteria; obtain sign-off.
9. Baseline and manage change - version the document, route changes through a Change Control Board (CCB) with impact analysis on cost, schedule and other requirements.
10. Trace and close - maintain the traceability matrix through design, code, test and UAT.
11. Common problems: stakeholders cannot articulate needs, requirements expressed in solution terms, conflicting stakeholders, volatile requirements, political requirements, the "yes to everything" sponsor, and gold-plating by analysts.

Documenting: BRD, FRD, SRS, user stories

• BRD (Business Requirements Document) - why and what, in business language, for the sponsor. FRD/FSD (Functional Requirements/Specification Document) - detailed system behaviour for designers and testers. SRS - the engineering specification of the software product (often merges FRD + NFRs). Use case document, user story + acceptance criteria in agile. In Indian service companies the typical chain is RFP → proposal/SOW → BRD → FRD → design document → test cases.
• IEEE 830 / ISO-IEC-IEEE 29148 SRS outline (29148 supersedes IEEE 830-1998 but exams still ask the 830 structure):
  1. Introduction - purpose, scope, definitions, references, overview.
  2. Overall description - product perspective, product functions, user characteristics, constraints, assumptions and dependencies.
  3. Specific requirements - functional, external interface, performance, logical database, design constraints, software system attributes.
  4. Appendices and index.
• Characteristics of a good SRS / good requirement: correct, unambiguous, complete, consistent, verifiable (testable), ranked for importance and stability, modifiable, traceable, feasible, atomic (one requirement per statement), necessary. Write "shall" for mandatory, "should" for desirable.
• Avoid: "user-friendly", "fast", "efficient", "etc.", "as appropriate", "and/or", and passive voice that hides the actor.
• Use case elements: actor (primary/secondary), pre-conditions, post-conditions, main success scenario, alternate and exception flows, triggers, business rules; relations include, extend, generalisation. A use case diagram shows actors, system boundary and use case ovals - it shows *what*, never the sequence of screens.
• User story: "As a <role>, I want <goal>, so that <benefit>", sized by story points, with acceptance criteria often in Given-When-Then; quality checked by INVEST (Independent, Negotiable, Valuable, Estimable, Small, Testable) and the 3 Cs (Card, Conversation, Confirmation). Epic → feature → story → task.
• Traceability matrix (RTM): maps each requirement ID forward to design, code and test cases and backward to its business need - proves coverage, finds orphan code and untested requirements, and is a mandatory artefact in CMMI Level 3+ and ISO 9001 audits.

Prioritisation, estimation of effort and change

• MoSCoW: Must have (no release without it), Should have (important, has a workaround), Could have (nice to have), Won't have (this time). Convention: Must-have effort kept at roughly 60% or less of total so there is contingency.
• Kano: must-be, one-dimensional (performance), attractive, indifferent, reverse.
• Value vs effort (2×2): quick wins, big bets, fill-ins, money pit. WSJF = cost of delay ÷ job size (SAFe).
• Requirement volatility = changed requirements ÷ total requirements - a health metric; high volatility signals weak elicitation or a moving market.
• Scope creep (uncontrolled additions) vs gold plating (team adds unasked features) vs approved change (through the CCB with revised cost and date). Fixed-price Indian contracts control this through a signed baseline and a change request/CR note.
• Cost of late defects: the classic Boehm curve - relative cost to fix a requirements error rises roughly by an order of magnitude per phase (requirements → design → code → test → production). The exact multipliers are study-specific and disputed, so quote the shape, not precise figures.

Indian context: standards, Acts and practice

• IT Act 2000 (with the 2008 amendment) - Section 43A and the SPDI Rules 2011 governed sensitive personal data; Section 65B of the Indian Evidence Act, 1872 (now Section 63 of the Bharatiya Sakshya Adhiniyam, 2023) governs admissibility of electronic records, which drives audit-trail requirements.
• Digital Personal Data Protection Act, 2023 - consent notice, purpose limitation, data principal rights (access, correction, erasure), consent manager, breach notification, children's data. Rules were notified in 2025 with phased implementation, so verify current enforcement dates before citing deadlines. For a BA this becomes concrete requirements: a consent screen, a purpose field, retention and deletion rules, a grievance officer workflow.
• RBI - data localisation for payment system data (2018 directive), cyber security framework for banks, KYC master direction; SEBI, IRDAI and TRAI add sector requirements. GST - e-invoicing (IRN/QR), HSN codes, GSTR filing formats - a staple of ERP requirement work.
• Accessibility - GIGW (Guidelines for Indian Government Websites, STQC/MeitY) and the Rights of Persons with Disabilities Act, 2016 make accessibility a stated requirement for government portals; IS 17802 is the Indian accessibility standard for ICT.
• Quality frameworks used by Indian service providers: CMMI (requirements management and requirements development process areas), ISO/IEC/IEEE 29148, ISO 9001, ISO 27001; many large accounts mandate an RTM and a signed SRS as contractual deliverables.
• Government procurement - RFP/EOI on GeM or a department portal, with functional requirement specifications annexed; vendors respond clause by clause in a compliance matrix.

Key points

• Business analysis - finding the business need and the right solution, which may not be software.
• Requirement engineering - elicitation, analysis, specification, validation, management (five activities).
• Elicitation, not collection - needs must be drawn out; users rarely state them completely or correctly.
• Functional requirement - what the system does; non-functional - how well (performance, security, usability, availability).
• Constraint - a fixed boundary (budget, stack, date); business rule - a policy independent of any system.
• Stakeholder analysis - identify everyone affected and map them on power vs interest; fix one decision-maker.
• JAD workshop - facilitated multi-stakeholder session; fastest way to resolve conflicting requirements.
• Observation - the only reliable way to capture tacit knowledge and undocumented workarounds.
• Prototype - cures vague requirements; risk is the client treating a mock-up as the product.
• SRS quality criteria - correct, unambiguous, complete, consistent, verifiable, ranked, modifiable, traceable.
• IEEE 830 / ISO 29148 - the standard SRS structure; 29148 is the current standard.
• Use case - actor-goal interaction with main, alternate and exception flows; include and extend relations.
• User story and INVEST - "As a… I want… so that…" with Given-When-Then acceptance criteria.
• MoSCoW - Must, Should, Could, Won't; keep Must-haves near or below 60% of effort.
• RTM - two-way map from business need to requirement to design, code and test; proves coverage.
• Validation vs verification - validation asks "the right requirements?"; verification asks "built right?".
• Scope creep vs change control - uncontrolled growth vs an impact-assessed, approved CR through the CCB.
• DPDP Act 2023, IT Act 2000, RBI localisation, GIGW - the Indian rules that turn into concrete requirements.

Formulas and examples

• Requirements volatility and stability. A college ERP baselines 120 requirements. During build, 18 are modified, 6 added and 4 deleted - 28 changes in all.
  • Volatility = 28 ÷ 120 × 100 = 23.3% (above a typical 10-15% comfort band → elicitation was weak with the examination department).
  • Stability index = (1 − 28/120) × 100 = 76.7%.
  • Effort impact at an average 1.5 person-days per changed requirement = 28 × 1.5 = 42 person-days; at ₹6,000 per person-day = ₹2,52,000 of unplanned effort.

• Cost of catching requirement defects early. A banking project reviews its SRS and finds 35 requirement defects. Fixing one at requirement stage costs about ₹4,000 (re-work of the document and re-review); the same defect reaching production costs about ₹1,20,000 (analysis, code fix, regression, release, customer impact) - a 30× factor, in line with the shape of the Boehm curve, though exact multipliers vary by study and organisation.
  • Review cost = 35 × ₹4,000 = ₹1,40,000.
  • Avoided production cost = 35 × ₹1,20,000 = ₹42,00,000.
  • Net saving = ₹42,00,000 − ₹1,40,000 = ₹40,60,000; return = 40,60,000 ÷ 1,40,000 ≈ 29 times the review spend.

• MoSCoW with a fixed capacity. A 6-sprint release has a velocity of 30 story points per sprint → capacity = 6 × 30 = 180 points. The backlog is Must 120, Should 60, Could 50, total 230 points.
  • Must share = 120 ÷ 230 = 52.2% of the backlog, and 120 ÷ 180 = 66.7% of capacity - slightly above the 60% guideline, so contingency is thin.
  • After the Musts, 180 − 120 = 60 points remain → all Shoulds fit only if nothing overruns; the 50 Could points (21.7% of the backlog) are the planned buffer and are dropped first.
  • If velocity drops to 25, capacity = 150 → Musts (120) leave only 30 points, so half the Shoulds slip. This arithmetic is the argument used in scope negotiation.

• Weighted prioritisation of four requirements. Criteria and weights: business value 0.4, regulatory need 0.3, user reach 0.2, technical risk reduction 0.1; ratings out of 10.

• Working: R1 = 2.4 + 3.0 + 1.6 + 0.7 = 7.7; R2 = 3.6 + 1.5 + 1.8 + 0.4 = 7.3; R3 = 3.2 + 0.6 + 2.0 + 0.3 = 6.1; R4 = 2.8 + 0.3 + 0.8 + 0.2 = 4.1.
  • By raw score the order is R1 > R2 > R3 > R4; by value per effort it is R1 > R3 > R2 > R4 - the costly gateway drops below mobile attendance once effort is divided in. Interviewers look for exactly this distinction.

• Turning an NFR into a testable statement. A client says "the portal must never be down".
  • Negotiated: availability 99.5% in a calendar month, excluding a 4-hour notified maintenance window.
  • Allowed downtime = 0.5% × 30 × 24 h = 0.005 × 720 = 3.6 hours per month (≈ 43.8 h/year at 8,760 h).
  • With MTBF = 700 h and MTTR = 3 h, availability = 700 ÷ 703 × 100 = 99.57% - meets the target.
  • Written as: "NFR-07: The portal shall be available for at least 99.5% of each calendar month, measured by external monitoring at 1-minute intervals, excluding notified maintenance of up to 4 hours."

Requirement ID: FR-012                Priority: Must
Source: Accounts Officer, interview dated 14-10-2026
Statement: The system shall block submission of a purchase order above
           ₹5,00,000 until two distinct approvers have recorded approval.
Business rule: BR-04 (two-tier approval limit, Finance Manual clause 7.2)
Acceptance criteria (Given-When-Then):
  Given a PO of ₹6,00,000 with one approval recorded
  When the maker clicks Submit
  Then the system rejects it with message "Second approval pending"
   And the attempt is written to the audit log with user ID and timestamp
Verification: Test cases TC-121, TC-122 | Design: DD-3.4 | Code: po_approval.java

Where it is used

• IT services and consulting (TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Accenture, Cognizant, Capgemini): BRD/FRD authoring, RFP response and compliance matrices, CMMI-mandated requirements management on fixed-price accounts.
• BFSI: core banking and lending transformations, UPI and payment integrations, KYC and AML rules, RBI reporting - functional consultants translate master directions into system requirements.
• ERP and package implementation: SAP, Oracle, Salesforce, Zoho - fit-gap analysis, AS-IS/TO-BE process maps, GST e-invoicing and HSN requirements, RICEFW objects for every gap.
• Government and e-governance (NIC, C-DAC, state IT departments, UIDAI, GSTN, IRCTC): functional requirement specifications annexed to tenders, GIGW accessibility and bilingual requirements, STQC testing before go-live.
• Product companies and startups (Flipkart, Zomato, Razorpay, Zoho, Freshworks): Product Owner writes epics and stories, defines acceptance criteria, runs discovery and A/B experiments instead of a single frozen SRS.
• Healthcare, telecom and manufacturing IT: HIS and ABDM-aligned health records, telecom OSS/BSS charging rules, MES and shop-floor digitisation where observation and document analysis dominate.
• Entry-level roles that need this: Business Analyst, Systems Analyst, QA analyst (writes test cases from requirements), pre-sales/bid support, implementation consultant.

Interview questions

• Q: What is the difference between a functional and a non-functional requirement? A: A functional requirement states what the system does (calculate GST on an invoice); a non-functional requirement states how well it must do it (compute within 2 seconds for 95% of invoices, with an audit trail). NFRs usually drive architecture.
• Q: Difference between a BRD and an FRD? A: The BRD states the business need, objectives and scope in business language for the sponsor; the FRD details the system behaviour - screens, fields, validations, interfaces - for designers and testers. One BRD typically spawns several FRDs.
• Q: What makes a requirement "good"? A: It is unambiguous, complete, consistent, feasible, necessary, atomic, traceable and above all verifiable - you can write a test that passes or fails on it.
• Q: How would you elicit requirements from a client who says "just make it like the old system, but better"? A: Document-analyse and reverse-engineer the legacy system, observe users to find workarounds, then run a workshop on a prototype so they react to something concrete, and convert each reaction into a prioritised requirement with acceptance criteria.
• Q: What is a requirements traceability matrix and why do audits insist on it? A: A two-way map from business need to requirement to design, code and test case; it proves every requirement is built and tested, exposes untested requirements and orphan features, and is evidence for CMMI and ISO quality audits.
• Q: Validation or verification - which applies to requirements? A: Both: validation checks we captured the right requirements (stakeholder review, prototype demo, UAT), verification checks the specification is internally correct and the build matches it.
• Q: Two stakeholders give you contradictory requirements. What do you do? A: Document both with their sources and rationale, assess impact on the business objective, take it to a facilitated session with the identified decision-maker, and record the resolution and its rationale in the requirement's change history - never quietly pick one.
• Q: What is scope creep and how do you control it? A: Uncontrolled addition of requirements after baselining; controlled by a signed baseline, a change request with impact analysis on cost, schedule and dependent requirements, approval by the CCB, and re-prioritisation against a fixed capacity.
• Q: Explain MoSCoW and the trap in it. A: Must, Should, Could, Won't-this-time. The trap is every stakeholder calling everything a Must - the test is "is the release useless without it?", and Must-haves should stay around 60% or less of capacity to leave contingency.
• Q: How do requirements differ in Waterfall and Agile work? A: Waterfall freezes a signed SRS up front and manages change formally; Agile keeps a living, prioritised backlog of stories refined each sprint with the Product Owner - the analysis work is the same, its documentation depth and timing differ.
• Q: Give one Indian regulation that becomes a requirement you have written. A: The DPDP Act 2023 turns into explicit consent capture with purpose, retention and deletion rules, data-principal access and correction features, breach notification and a grievance officer workflow; RBI's localisation directive turns into a requirement that payment data be stored only in India.
• Q: A client cannot articulate response-time needs. How do you specify performance? A: Measure the current system or a comparable one, propose a baseline with percentiles (95th percentile under 2 s at 500 concurrent users), get it agreed in writing, and define how it will be measured - an unmeasured NFR is not a requirement.
• Q: What is a use case "extend" versus "include"? A: Include factors out common behaviour that the base use case always invokes (validate login); extend adds optional or conditional behaviour at a defined extension point (apply coupon during checkout).

Common mistakes

• Writing solutions instead of needs - "add a dropdown of states" instead of "the user must select a valid state for the delivery address".
• Using unverifiable words - user-friendly, fast, robust, secure, flexible, "etc." - which cannot be tested and therefore cannot be accepted.
• Treating elicitation as transcription: writing down what the loudest stakeholder says without analysis, conflict resolution or checking against the business objective.
• Ignoring non-functional requirements until late; performance, security and availability drive architecture and cannot be bolted on after coding.
• Confusing a use case diagram with a flowchart - drawing sequence and screens on it, or putting system components in place of actors.
• Skipping stakeholder analysis and missing silent-but-powerful parties - auditor, regulator, operations, support - whose requirements surface at UAT.
• Bundling several requirements in one numbered statement, which breaks traceability and makes partial failure untestable.
• Confusing validation with verification in exams, and confusing an approved change request with scope creep.

Related topics

SDLC and Agile · Software project management and estimation · Software testing basics · System design case studies · Agile tools: Jira and Confluence · Database design and ER modelling