How the work is actually done
No listicles, no career-change motivation. Each note takes one piece of the job, shows a finished artifact and says what a reviewer would object to.
Three clusters
Every note belongs to one of three threads. Each starts from a pillar and goes deeper from there.
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.
Requirements That Survive Review
The acceptance criteria piece opens with five checks and points at the twenty-five in the scorecard. These notes go deeper: what to check, how to trace it, how to settle a dispute between two people who are both right, and when a requirement is ready at all.
The Document That Gets Read
The BRD piece shows one fragment before and after eleven edits. These notes take the document's sections one at a time: the business need, the scope, the measure of success, and what happens to all of it when a change request lands.
Latest notes
Writing an Integration Requirement Without Designing the API
An integration requirement names the fact that crosses, the event, the owner and the failure. Eight crossings in one case, and the design words to strike.
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 →Business Analyst or Product Owner: Who Owns the Requirement
One requirement cut into lines, and who can change each. The product owner holds the order, the analyst the wording, the rule owners the numbers.
Read →Discovery Deliverables That Decide Whether Build Starts
One published case read against two public discovery checklists. Which deliverables can stop a build, which only prepare one, and the gap that decides.
Read →Splitting a User Story Without Losing the Value
One story from a published case, run through nine splitting patterns. Which slices keep the point, which lose it, and what each has to carry.
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 →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 →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 →Turning Acceptance Criteria Into a UAT Script
A UAT script names who acts, what they do, the result they should see and the acceptance criterion each step proves. One scenario, filled in and blank.
Read →BRD or SRS: What Changes When Rules Meet a System
BRD vs SRS as one test: swap the system out and see which sentences survive. Run on all 19 rule and criterion lines of one worked case.
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 →Requirements Governance: Who Approves What, and When
Nine items on a status ladder, four approval gates and ten changes I counted in the case, replayed against a change policy. Reviewed is a rung below approved.
Read →Next in the queue: Before the Migration Starts: What the Analyst Must Settle · A Requirements Pattern Library Worth Reusing.
A letter when I have something worth sending
New notes go up on this page as they are written, and the Proof Pack comes when you join. No schedule, no sequence, no webinar funnel.
Subscribe