Requirements Engineering
Intentions become sentences you can sign off — with acceptance criteria instead of adjectives.
- User stories
- Acceptance
- Prioritised
How it works
Requirements are not born in a document but in conversations that somebody then writes down. We do both.
From wish to sentence
We phrase every requirement so it describes an outcome, not a feeling. Not “the search should be fast”, but what the search finds, in what order, and from what point the result is useful.
Acceptance criteria
For every requirement we write down how you can tell it has been met. Those criteria are the acceptance later. They are agreed before the build, not negotiated after it — that is the entire point.
Edge cases
We ask systematically about what rarely happens. What if two people edit at once? If someone closes the app mid-process? If the record from the legacy system is incomplete? These cases are why estimates burst when you only discover them during the build.
Prioritisation
At the end we sort. What has to be in version one, what can wait, what we cut. We insist that something is cut — a list where everything is important is not a prioritisation.
- Someone who decides on the subject matter and is reachable. Questions come daily, not weekly.
- The edge cases you carry in your head and nobody ever writes down.
- Existing rules: pricing logic, discounts, deadlines, approval paths.
A requirements catalogue of user stories with acceptance criteria, prioritised and signed off by you.
If you skip this
"Users should be able to manage invoices" is not a sentence you can sign off. Without criteria, acceptance turns into an argument about intentions, and that argument has no referee.
Questions about this step?
A conversation costs nothing and takes half an hour. Afterwards you will know whether we are a fit.