How we capture requirements
From a business description to requirements a team can build
Our elicitation process turns a plain-language description of what your business needs into a structured requirements package. Every part of your description is tracked by ID, every ambiguity and gap is put to a person for a decision before anything is written, and code checks at each stage that nothing was dropped and nothing was invented.
One example, all the way through
Every file on this page is shown for the same worked example, so you can follow it from the business description to the finished requirements package. That package is where our build pipeline starts.
Worked example
Expense Report Processing
Replace Acme's Oracle Forms, email, and shared-drive expense workflow with a single web application that covers creation, approval, finance review, and reimbursement recording. The business target is submission-to-reimbursement in under 3 business days for reports that need no correction; today it takes 2-3 weeks.
Starts from a 9 KB business description with 32 items. Ends with 13 requirements, 38 acceptance criteria, 10 business rules, 8 data entities.
Reading the page
An AI model does the work; its output is checked by code.
Deterministic code, no AI.
The pipeline stops and a person decides.
Runs only when there is something to fix.
Click any file to see the example. Each file is labeled with how it was produced.
The flow
Work moves forward through seven phases. The process stops at each decision point until a person has decided every entry, and the optional review rounds at the end can repeat as often as needed; both are marked where they start.
Next: the build pipeline
The finished requirements package is the input to our requirements-to-code pipeline, which designs the architecture, plans and builds the work test-first, and has it reviewed. See the build pipeline guide, which follows the same worked example.