Work case 02 / Requirements & process design
From a request to a shared understanding.
What should it do—and how will we know it does it well?
Real experience / Public scope
Connect business language to system behaviour.
In this requirements and process-improvement role, I translated policies and stakeholder needs into requirements documents, field dictionaries, interface mock-ups, calculation logic and acceptance criteria across eight-plus internal workflows.
I care about whether these deliverables agree: what the requirement says, how the interface presents it, how a developer implements it, and how someone checks the result.
Read the CV edition ↗The translation / Four connected deliverables
One question. Through every layer.
NEED
Hear the problem
Identify who needs a change, what they are trying to achieve, and what remains undecided. “The system should handle it automatically” is not yet a buildable task.
RULE
Define the boundary
Make inputs, conditions, exceptions and ownership explicit. A field dictionary and calculation logic should answer the same business question.
INTERFACE
Make behaviour visible
Put the rule back into a person’s workflow: missing information, an exception, the next owner, and a clear way to continue.
ACCEPTANCE
Check the understanding
Prepare normal, boundary, exceptional and incomplete-input checks. Give business and implementation teams a result they can discuss together.
Deliverable relationships / Keep a trace
Documents that can speak to one another.
Connect the goal, actors, flow and open decisions so the next design has a clear start and finish.
Define meaning, source, validity and related records so the same value stays consistent across the workflow.
Make input order, actions and feedback locations visible enough to discuss together.
Connect inputs, calculation order and branches so implementation and testing can follow the same logic.
Explain who can act, which conditions trigger an exception and who handles the next step.
Connect requirements to repeatable inputs and expected results across normal, boundary, exceptional and incomplete cases.
TRACE DESK / ONE EXAMPLE, FOUR DELIVERABLES
Change a condition. Follow it through the work.
Choose an acceptance situation and follow the requirement through fields, interface behaviour and checks. This independent reconstruction uses the same fictional 500 threshold as the working-method notebook.
SITUATION 01
A complete request
- Amount
- 350
- Purpose
- Workshop supplies
- Exception record
- Not attached
ROUTEStandard review
- 01 / REQUIREMENT
Explain the intended behaviour.
A person enters an amount and purpose. The system checks the information, then uses the amount and exception record to choose a review route.
- 02 / FIELDS & RULE
The same fields should give a clear route.
With valid fields, an amount of 500 or less can proceed. Above 500, the example requires an exception record.
- 03 / INTERFACE
Make the next step visible.
Keep the entered fields visible and send the request to a person for review.
- 04 / ACCEPTANCE
Check adjacent conditions.
A complete request at exactly 500 stays on the standard route. An exception record allows 800 onto that route too.
Open the field dictionary and all acceptance examples
| Field | Meaning & constraint |
|---|---|
amountDemonstration amount | A number greater than 0 and no more than 100000; unitless. |
purposePurpose | At least 3 characters after trimming whitespace. |
exceptionException record | Used to route an amount greater than 500. |
| Situation | Expected route |
|---|---|
| A complete request | Standard review |
| Exactly at the boundary | Standard review |
| Just above the boundary | Exception review |
| An exception record attached | Standard review |
| The purpose is missing | Correct the fields first |
| The amount is invalid | Correct the fields first |
RULE CHANGE / CHECK BOTH VERSIONS
Add “or equal to”. What changes?
Keep the six acceptance inputs fixed and compare the original rule with a revised threshold or boundary. Inspect the changed routes, then try your own fields. This remains a fictional, unitless method example.
Valid fields, an amount greater than 500 and no exception record lead to exception review.
Field validation, exception records and human review stay the same.
situations change routeThis is a count of fixed examples, not their frequency in a business.
| Situation | Original> 500 | Revised≥ 500 | Comparison |
|---|---|---|---|
| A complete requestAmount 350No record · Purpose complete | Standard review | Standard review | Same routeUnaffected input |
| Exactly at the boundaryAmount 500No record · Purpose complete | Standard review | Exception review | ChangedDifferent boundary |
| Just above the boundaryAmount 501No record · Purpose complete | Exception review | Exception review | Same routeUnaffected input |
| An exception record attachedAmount 800Record attached · Purpose complete | Standard review | Standard review | Same routeRecord attached |
| The purpose is missingAmount 350Record attached · Purpose missing | Correct the fields first | Correct the fields first | Same routeFields need correction |
| The amount is invalidAmount 0No record · Purpose complete | Correct the fields first | Correct the fields first | Same routeFields need correction |
Try your own fields under both rules
The amount must be greater than 0 and no more than 100000; the trimmed purpose needs at least 3 characters.
- Original
- Standard review
- Revised
- Exception review
HANDOFF & REVIEW / LEAVE A WAY FORWARD
Four questions to leave clear at handoff.
The role covered requirements material, clarification, development handoff, feedback and testing follow-up. Looking back, these are four questions I would use to review whether someone else can continue the work.
Who confirms the meaning?
Management, finance, HR and implementation teams bring different questions. Keeping an open definition beside the person who can confirm it gives the next owner a practical way to continue.
Do the materials agree?
A field constraint should connect to the prototype, calculation flow and acceptance examples. After changing a condition, trace the field across those materials rather than updating only the prose.
Who takes the exception?
Permissions and exceptions need an operational next step: who can start, view or amend a request, how incomplete information is returned, and what record the next person needs.
How does feedback return?
Put the input, expected route and observed behaviour together. Add the rule version and any open question so the next change and retest have a clear starting point.
MATERIAL GUIDE / FOLLOW THE WORK
Open the material behind the case.
Each entry identifies the kind of material: an experience record, a submitted artifact or a later method example.
The CV account
The August 2026 edition records the workflows, deliverables and cross-functional handoffs.
Open material↗02 / Method demonstrationThe trace desk
Inspect six fictional situations across requirements, fields, interface behaviour and acceptance.
Open material↗03 / Interactive demonstrationEdit the request yourself
Change the fields in the fictional notebook and inspect the route.
Open material↗
AFTER READING / THE CONVERSATION
What would you add?
Add an experience, ask a question or point out a correction. Both language editions share this article’s discussion.
Public comments are not open yet. Keep a draft on this device, or send your thoughts through the contact page.
Write a local draft
Only “Save on this device” stores the draft. Clear it on shared devices; it is not published automatically.
0 / 1600