Requirements
Break the need down without losing it.
Requirements decompose from epic to detail over six levels, each typed, prioritised and owned, with its parent and children on the record.
Most requirements tools keep a backlog. AlignX connects each requirement to the business case it serves, the framework clauses it must satisfy and the acceptance criteria that define when it's done, so delivery stays connected to the reasons behind the work.
You have the requirements. You've lost the reasons.
Requirements sit in documents and tickets, apart from the case that funded them and the rules they must meet, so the why is gone by the time the work starts.
Why are we building this?
The answer is in a business case nobody linked, written months before the backlog.
Does this meet the standard we're audited against?
Compliance reads the policy, delivery reads the ticket, and nobody joins the two.
What did we actually agree?
Sign-off happened in an email thread, against a document that's changed since.
So delivery builds to the ticket, not to the need.
How a need becomes something you can build and prove
Seven connected records, from the case that funds the work to the change it makes.
- Business caseThe investment the work serves, its options and the objectives behind it.
- RequirementEach need, from epic down to detail, typed, prioritised and owned.
- ScopeWhat's in, what's out, and the assumptions and constraints, each rated for confidence.
- AcceptanceGiven, when, then: the conditions that say when it's done.
- ClauseThe framework and standard requirements it must satisfy.
- Sign-offApproval through a governed step, not an email.
- ChangeThe move from current to target the case drives, with its dependencies.
Keep the need, the rule and the build on one thread.
Business analysts, delivery and compliance work from the same requirement record, so the argument about scope uses the same facts.
Prioritisation
Agree what matters, where everyone can see it.
MoSCoW on a board you drag requirements across, alongside urgency, so must-haves and won't-haves are a view, not a spreadsheet debate.
Acceptance and scope
Say what done means before you start.
Acceptance criteria as ordered given-when-then statements with a test method, and scope, assumptions and constraints as rated records.
Compliance
Know which rule each requirement satisfies.
Requirements link to the clauses of the frameworks and standards you answer to, the same library your risk and compliance teams use.
Business case and change
Connect the business case to the change it drives.
Requirements sit under the business case they serve. That case carries its options and objectives, and the change it drives records the move from current to target, with dependencies that can't form a loop.
Every requirement on the record, with its reason beside it.
Build what was agreed
Sign-off on the record
Approval goes through a governed step, not an email thread.
Compliance designed in
The clauses a requirement must meet are on it before the work starts, not found in the audit.
Done is defined up front
Acceptance criteria are written down before delivery, in a form testers can use.
Requirements shouldn't just describe the build. They should explain it.
Start with the requirements you already have
You don't need a new method to start.
- Bring them inYour current requirements, imported from a spreadsheet rather than retyped.
- Link one business casePut a project's requirements under the case that funded it.
- Trace one frameworkLink the requirements that carry a compliance obligation to the clauses they satisfy.
Built inside your Microsoft 365. Your data. Your controls. Your requirements.
Questions business analysts ask
Six levels, from epic through feature, user story, task and sub-task to detail, each with its parent and children on the record.