Customer onboardingv0.1
Draft requirement
Make onboarding easier for new customers.
A new admin can complete or resume setup without losing answers.
Still open
What happens if setup fails partway through?
How it works
Give the work a method. Then examine it.
Start with a question or existing material, work through a business analysis playbook, and read the review findings. A person decides what the result means and what is ready to move forward.
Illustrative work record · KRY-DEMO-01
DeliverableRisk assessment
Sources referenced
Scope definedFinding resolvedVersion recorded
Methods belong in the work
A method is useful only when it changes what you do.
Business analysis methods and requirements standards offer useful criteria. Applying them consistently to a real, messy brief takes work.
Kryterea puts guided steps and review criteria in the workspace. Findings make a weakness visible while you can still improve the result.
See the productThe loop
The work gets stronger each time it is checked.
Follow an illustrative requirement from first draft to human decision. Available stages vary by pilot release and workspace.
Follow the workIllustrative example
The next pass starts with what the last one revealed.
Kryterea / review cycleIllustrative work surface
The starting point
A request becomes a requirement.
A first pass gives the team something specific to examine.
Working draft
Review → revise → decideThe person remains accountable
Illustrative criteria library
What a useful review might examine.
These sample criteria show the intended approach across document types. Business analysis is the first deep capability; this browser is illustrative, not a catalogue of live modules.
Requirements specification
Whether each requirement can be built, tested and traced without interpretation.
What the standard checks
- Every requirement carries a unique identifier and states one thing only.
- Every requirement is verifiable, with an acceptance condition that could fail.
- Every requirement traces to a stated business need, and every stated need has at least one requirement.
- No requirement encodes a design decision the solution has not yet earned.
- Conflicts, duplicates and gaps are surfaced rather than left for the reader to find.
What a finding looks like
FR-014 says the system should handle large files quickly. Neither large nor quickly is defined, so the requirement cannot be tested. Give the file size ceiling and the time budget, or move it to the non-functional set with a measurable threshold.
The gate explains a gap.
"Not ready" is useless on its own. "Not ready because three acceptance criteria use subjective language and one dependency has no fallback" tells you what to fix and in what order.
Every finding names the problem, the clause it comes from, why it matters, and what would resolve it. The gate explains; it does not just judge.
Inside every check
Enough to challenge. Enough to approve.
Assessment record
Ready for a human decision
Traceable result
Input
What was checked
The document type, its scope, and the standard it was held to.
- Deliverable
- Recorded
- Scope
- Bounded
- Standard
- Cited
Evidence returned
What meets the standard
Each item that holds up, with the evidence behind it.
Evidence attachedWhat needs work
Each item that falls short, with the specific gap and the fix that would close it.
Gap and fix namedWhat remains open
Open questions, unstated assumptions, and areas where the evidence was not enough.
Held open, not guessedRight for the job, not perfect for its own sake.
The question is not whether the document is perfect. It is whether it is good enough for the person, team, or coding agent that will build from it.
That is what the Kryterea gate checks: fitness for purpose, measured against the standard your profession already uses.
Argue with the standard.
Put a real document through the gate. Read the findings. If the check missed something, that is the conversation worth having.
Built on business analysis practice and ISO/IEC/IEEE 29148.