See exactly what you get for ₹99

Say this: They sit at different levels of detail and have different audiences. The BRD states what the business needs and why — objectives, scope, stakeholders, high-level requirements and success criteria — and its reader is the sponsor. The FRD states what the system must do to satisfy that, screen by screen and rule by rule, in language a developer and a tester can work from.

Make it concrete with one line from each: BRD — "Employees must be able to apply for leave without email." FRD — "The system shall display the employee's available balance by leave type on the application screen, and block submission when the requested days exceed it."

Follow-up: "And the SRS?" → The fullest technical version, adding non-functional requirements — performance, security, availability — plus interfaces and constraints.

The honest addition that scores: In an Agile project the FRD is usually replaced by a backlog of user stories with acceptance criteria, and only a lightweight BRD survives. Saying you would ask what the team actually uses beats reciting all three.

Don’t say: "They're the same thing with different names" — the audience and the level of detail is the entire answer.

Say this: "Fast" is untestable, so as written it is not a requirement — no developer knows when to stop and no tester can pass or fail it. I would not push back on it, though; I would turn it into something specific by asking three questions: fast compared with what they have today, at what data volume, and what happens at peak — because a report that is fine on Tuesday and unusable on the first of the month is really a peak-load requirement.

The rewritten version: "The monthly sales report shall render within 5 seconds for a 12-month range across all regions, with up to 50 concurrent users." That is now a non-functional requirement someone can build to and verify with a load test.

Follow-up: "Why a percentile rather than an average?" → Because an average response time hides the bad experience. "Under 5 seconds for 95% of requests" is honest; "average 3 seconds" can still mean one user in twenty waits half a minute.

Don’t say: just "I'd write it as an NFR" — the mark is in the questions you ask to get the number, not in naming the category. Other red-flag words worth spotting: user-friendly, seamless, flexible, "handle all cases".

Say this: A BA sits between the business and the technical team and turns a business problem into something that can be built and measured. Concretely that is four things: understanding the problem and the current process, eliciting and documenting requirements so they are unambiguous and testable, keeping stakeholders aligned when priorities conflict, and validating at the end that what was delivered actually solves the problem. The part I would emphasise is that a BA is not a note-taker — the value is in asking why, so you deliver the underlying need rather than the feature someone asked for.

Follow-up: "How is that different from a Project Manager?" → A PM owns delivery — timeline, budget, resources, risk. A BA owns the what and the why. In small teams one person does both, and it is worth saying so.

Follow-up: "And from a Product Owner?" → A PO owns the backlog and prioritisation and has decision authority on scope; a BA typically supports that with analysis and documentation. In many Indian service companies the BA effectively plays the PO role on the client's behalf.

Don’t say: "A BA gathers requirements from the client and gives them to developers" — that describes a messenger, and it is the answer that gets a fresher marked down.

Say this: They sit at different levels of detail and have different audiences. The BRD, Business Requirements Document, says what the business needs and why — the objectives, scope, stakeholders, high-level requirements and success criteria. Its audience is business sponsors. The FRD, Functional Requirements Document, says what the system must do to meet that — screen by screen, rule by rule, in language a developer and a tester can work from. The SRS, Software Requirements Specification, is the fullest technical version — functional plus non-functional requirements, interfaces and constraints, often following the IEEE template.

The honest addition that scores: in practice many organisations do not use all three. Agile teams often replace the FRD with a backlog of user stories and acceptance criteria, and keep only a lightweight BRD or a one-page vision. I would ask what the team actually uses rather than assuming.

Follow-up: "Give one line from each for the same feature." → BRD: "Employees must be able to apply for leave without email." FRD: "The system shall display the employee's available balance by leave type on the application screen." SRS adds: "The balance shall be retrieved from the HRMS API within 2 seconds."

Don’t say: "They're the same thing with different names" — the audience and level of detail is the whole answer.

Say this: It is both, split into two requirements — and that split is the point of the question. "The system shall send an OTP to the registered mobile number on login" is functional: what it does. "The OTP shall be delivered within 10 seconds for 95% of requests" is non-functional: how well it does it. I would write them separately because they are verified differently — the functional one by a test case, the performance one by a load test with a stated percentile.

The categories of NFR to name: performance, scalability, availability, security, usability, accessibility, maintainability, compliance and localisation.

Follow-up: "Why do NFRs get missed?" → Because stakeholders only talk about features. Nobody asks for "the page must load in 2 seconds" until it does not. So I ask about them explicitly — expected concurrent users, peak load, uptime expectation, data-retention rules and who must not be able to see what.

Follow-up: "Is 'the system should be user-friendly' an NFR?" → It is an intention, not a requirement, because it cannot be tested. Make it measurable: "a new user can complete a leave application in under 90 seconds without training."

Say this — and pair each with when you'd use it, because listing them is easy: Interviews — one to one, best for depth and for senior stakeholders who will not attend a workshop. Workshops — several stakeholders together, best when you need to resolve conflicting views in the room rather than discovering them later. Observation or job shadowing — best when people cannot articulate what they do; watching an ops team for an hour reveals workarounds nobody mentions. Document analysis — existing policies, current system screens, past tickets. Surveys — for many users where you need breadth, not depth. Prototyping — a wireframe, because people critique something concrete far better than they describe something abstract. Brainstorming and focus groups for early ideation.

The line that lands: "I'd never rely on one technique. Interviews give you what people say they do; observation gives you what they actually do, and those are usually different."

Follow-up: "Which would you use for a leave-management system?" → Interview the HR head for policy and the sponsor for objectives, workshop with managers because they will disagree with HR, survey employees for pain points, and read the existing leave policy document. Naming the technique per stakeholder group is the strong answer.

Don’t say: "I'd ask the client what they want" — that is the absence of a technique.

Say this: The test I apply is: could a developer build it and a tester verify it without asking me a question? Concretely a good requirement is unambiguous — one interpretation only; testable — you can state how you would prove it is met; complete — it covers the negative and edge cases, not just the happy path; consistent — it does not contradict another requirement; traceable — it links back to a business objective; feasible; and atomic — one requirement per statement, so "and" in a requirement usually means it should be two.

Show the fix, not just the list: "The system should be fast and handle errors properly" fails almost all of those. Rewritten: "The search results page shall load within 2 seconds for 95% of requests under 500 concurrent users" and "If the payment gateway does not respond within 30 seconds, the system shall display 'Payment could not be confirmed — do not retry' and log the transaction for reconciliation."

Follow-up: "Which words are red flags in a requirement?" → "Fast", "user-friendly", "etc.", "as appropriate", "should handle all cases", "flexible", "seamless". Any of them means a conversation has not happened yet.

Good answer hits: sits between business and technical team, turning a business problem into something buildable and measurable · understands the current process, elicits and documents requirements, keeps stakeholders aligned, validates the outcome · the value is asking why, so you deliver the underlying need rather than the requested feature · not a note-taker or a messenger.

One-liner: I turn a business problem into unambiguous, testable requirements — and the value is in asking why, not in writing down what was asked for.

Good answer hits: BRD — what the business needs and why, for sponsors · FRD — what the system must do, for developers and testers · SRS — the fullest technical spec including NFRs and interfaces · different audiences and levels of detail, not different names for the same thing · and the honest addition: Agile teams often replace the FRD with stories and acceptance criteria.

One-liner: BRD is the why, FRD is the what, SRS is the full technical specification — different audiences.

Good answer hits: both, and it should be split into two · "sends an OTP on login" is functional, what it does · "within 10 seconds for 95% of requests" is non-functional, how well · they are verified differently — a test case versus a load test · NFR categories: performance, security, availability, usability, scalability, compliance.

One-liner: Two requirements, not one — the OTP is functional, the 10 seconds is a performance NFR and needs a percentile.