Loading...
Requirements craft for BA and functional-consultant roles, where the interview tests elicitation and precision rather than technology.
21 published across 7 topics.
Interview and workshop technique, handling vague or conflicting input, and separating want from need.
Agreement on wording is not agreement on meaning, so stop re-reading the text and test it with concrete examples that force a different answer from each reading. Attack the words that hide ambiguity, use real data rather than hypotheticals, and record the resolution as examples instead of a rewritten sentence.
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.
A BRD explains the business objective and sponsor decision, an FRD describes required system behavior, and a user story is a small testable slice with acceptance criteria. Choose the artifact by audience, governance need and delivery granularity.
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.
Decide which documents deserve to be current before updating anything, because each one is read for a different decision and drift matters in only some of them. Retire what nobody reads, point people at the real record of truth, and cost the maintenance honestly rather than promising to keep everything in step.
BPMN and flow diagrams, as-is versus to-be analysis, gap analysis, and simple ER and data-mapping work.
As-is to-be process mapping starts with the process as performed, uses swimlanes to expose handoffs, baselines cycle time and rework, then designs a to-be process that eliminates work before automating it. Use this process modelling answer to show the decision, trade-off, and evidence rather than a memorised definition.
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.
Sort the variation by what causes it, because a legal or market difference has to be kept while habit and workarounds should not be. Model a common core with named variants rather than eleven processes or one, and say who loses from each standardisation before you propose it.
Backlog refinement, story splitting, definition of ready, and working with a product owner.
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.
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.
Sort the decision by reversibility rather than by who is senior enough to make it. Decide the reversible ones yourself in writing, build the cheapest option that keeps both answers available where you can, and record an assumption with an owner and a deadline rather than a silent guess.
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.
Stakeholder sign-off should not stall a project indefinitely. Confirm the decision owner, shrink the ask, proceed on a dated assumption, and escalate the delivery risk rather than complaining about the person. Use this stakeholder management answer to show the decision, trade-off, and evidence rather than a memorised definition.
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.
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.
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.
Convert the open defects into business consequence and volume rather than counts, construct a phased or partial cutover as a real third option, and give the steering group one explicit recommendation with the conditions that would change it. A date treated as fixed while exit criteria stay negotiable is the failure to name.
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.
Triage by what is expensive to reconstruct after they leave rather than trying to capture everything, watch the work rather than only interviewing about it, and verify what you are told against system evidence. Capture the decisions and the exceptions, because the happy path can be rebuilt and the judgement cannot.
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.