Requirements craft for BA and functional-consultant roles, where the interview tests elicitation and precision rather than technology.
14 published across 7 topics.
Business analysis fundamentals58 short answers on one page, for revising rather than studying.Interview and workshop technique, handling vague or conflicting input, and separating want from need.
Treat the churn as a symptom and work out which cause you have, because a stakeholder still discovering their own requirements needs concrete artefacts to react to, an unrecorded decision needs a written log, and a proxy who cannot decide needs replacing with someone who can.
Do not arbitrate between the stated requirements; trace each back to the business objective behind it, because most contradictions dissolve at that level, and escalate the genuine ones as a documented decision for a named owner rather than deciding yourself.
BRD, FRD, and SRS structure, use cases, user stories with acceptance criteria, and traceability matrices.
Convert the adjective into an observable: who is doing what task, under which conditions, and what result counts as a pass. Where no honest measure exists, record it as a design constraint with a named reviewer rather than leaving an unverifiable sentence in a document somebody signs.
A BRD holds the business case and is signed by the sponsor, an FRD holds system behaviour and is signed by delivery, and a user story is one testable slice owned by the team. In agile the BRD survives as a product goal and the FRD dissolves into acceptance criteria.
BPMN and flow diagrams, as-is versus to-be analysis, gap analysis, and simple ER and data-mapping work.
Agree the business meaning and the grain of each entity before touching field names, profile the real data to find the overloaded and sentinel values, then write a mapping where every target field has a source, a rule, a default and a decision for records that cannot be mapped.
Model the process as performed rather than as documented, in swimlanes so handoffs are visible, then quantify cycle time and rework rate before proposing anything; without baseline numbers a to-be design is just the current mess with software on top.
Backlog refinement, story splitting, definition of ready, and working with a product owner.
Separate what cannot be released from what cannot be built, because the two are almost never the same thing. Then slice along business dimensions such as workflow step, rule variation or customer segment, and hide the incomplete parts behind a toggle so the release stays whole while the build arrives in pieces.
The analysis does not shrink, it changes container: elicitation, rule-finding and precision now land in refined backlog items and acceptance criteria at the point of build. What a specification gave you free — traceability, cross-cutting requirements, a scope baseline — you rebuild on purpose.
Mapping influence, managing scope creep, negotiating priorities, and running a sign-off.
Stop arguing about the label and test the request against the accepted criteria: if the behaviour or the effort changes, it is a change whatever it is called. Hand the product owner a delta and options rather than a refusal, and keep a log so a fortnight of small clarifications stays visible.
Establish who owns the decision before arguing about the decision, then make it cheap for that person to decide by putting the trade-off in writing with options, consequences, a recommendation and a decide-by date. You are not the arbiter; you are the reason the arbiter can choose quickly.
Data analysis for decisions, defining UAT scope and scripts, and driving business acceptance.
Usually both are correct and they are answering different questions, so stop comparing totals and reconcile down to the first point of divergence. Publish a bridge that explains the gap in named components, then have one definition made authoritative with a named owner instead of declaring a winner.
Plan UAT backwards from the business outcome rather than forwards from the specification, and have real users run real work on realistic data. If sign-off lands on the wrong thing, measure the gap against the original objective and raise it as a change with its own business case.
Situations to work through: an absent stakeholder, a mid-sprint scope change, contradictory requirements.
Do not campaign to reverse a signed purchase; change what the requirements are for. Capture the business needs and outcomes independently of the product, run a fit-gap against them, and report each gap with a closure option and a cost so the sponsor can decide where to configure, change process or accept a shortfall.
Find the decision the dashboard is meant to support and the event that triggered the request, define every metric word precisely, check the data exists before promising the picture, and take back a one-page note that fixes scope against the date instead of accepting the date against unknown scope.