The Case File
The portfolio guide names the six documents a reviewer asks for and shows a slice of each. The notes in this cluster build those documents one at a time, on the same returns case, with the decisions behind them written down.
Start with the pillar
Business Analyst Portfolio: The Six Artifacts I Look For
What a business analyst portfolio actually is, the six documents I look for when one lands on my desk in review, and the objections two reviewers raised.
The notes, in reading order
As-Is Before To-Be: Modelling the Process That Actually Runs
Two models of the same returns process side by side, and the table of differences between them, with the column most people skip: what each change breaks.
Read →Decision Tables: Business Logic You Can Test
A returns rule that reads well in prose, laid out as a sixteen-row decision table: which combinations the policy settles, and what to do with the rest.
Read →The Questions a Reviewer Asks About Your Work Sample
What reviewers look for in a BA work sample, in the order they look for it: seven questions across twenty minutes, and what stops the read at each one.
Read →The Stakeholder Map That Survives Contact With the Project
A stakeholder map lists who can stop the work, what each one can stop, and where I know that from. A blank row to copy, three filled in from public sources.
Read →Writing a Use Case: The Main Flow Is the Easy Half
The main flow of a use case writes itself. A worked returns case where the exceptions take three times the space, with the source of each one named.
Read →The Eight Questions in a First Stakeholder Interview
First stakeholder interview questions, built backwards from the six things a case assembled from public sources could not settle, and what each answer changes.
Read →Five Whys Stops Working at Why Number Two
When five whys does not work, and what to do instead: one incident from a published returns case, three honest why chains, three different recommendations.
Read →A Risk Register With Owners, Dates and a Trigger
A risk register derived from artifacts I already had: eight candidates pulled out of a published case, three thrown out for having no trigger, five rows kept.
Read →How Long Will the Analysis Take? An Estimate You Can Defend
Three clocks on one published case: thirteen hours of work, seven to nine hours a plan could name in advance, and twenty-eight days of calendar.
Read →Cutting Scope Without Cutting the Point
Eleven cuts a published case made and four it refused, each run through one test: on release day, is the problem the work exists to fix still there?
Read →Gap Analysis Between Two Process Models, Line by Line
Every as-is row walked to its fate in the to-be, then every to-be line walked back. Two residual gaps, one shared verb and one step neither model draws.
Read →A Requirements Workshop That Ends With a Document
A workshop agenda built backwards from the document cells it must fill, an invite list read off decision rights, and three bins for whatever leaves the room.
Read →Elicitation When Nobody Has Time to Talk to You
A case built with zero stakeholder minutes: what public sources settled, and six open questions sorted by whether silence can answer them.
Read →Reading a Data Model to Find the Rules Nobody Wrote Down
The data model a requirements register forces, drawn and read back move by move: eight rules the register never wrote down, and where each one goes.
Read →Use Case, Sequence, Activity: Which Diagram Answers Which Question
Eleven questions asked of one published case, routed to the UML diagram that can answer each. Seven go to no diagram at all.
Read →BPMN for the Path Where Things Go Wrong
Every place a case waits needs an event that can move it. Six waits in a returns case, drawn in BPMN, and four answers the notation forced.
Read →The other two clusters
Requirements That Survive Review · The Document That Gets Read · All field notes
These notes stand on one worked case, and every figure in that case carries a source tag. What the tags mean.