Operion Journal
"The system is complicated." "We need a better report." "Invoicing takes too long." "Make it like the old system." Each hides a real problem, but none is a requirement; built as-is, they become random customisations. The real skill is turning complaints into requirements.
Why a complaint is not a requirement
| Complaint | Missing | Risk if built as-is |
|---|---|---|
| Too complicated | Which screen, step, user? | Random simplification removing controls |
| Need a report | For which decision, detail, frequency? | A report nobody uses |
| Invoicing is slow | Performance or steps? | Fixing the wrong thing |
| Like the old system | What was the goal? | Copying old limitations |
Five steps
- Record the complaint in the speaker's words.
- Ask for a real example.
- Find the goal, not the proposed fix.
- Write it as "As a [role], I need [capability] so that [benefit]" with acceptance criteria.
- Classify: standard feature, setting, training, workflow or development.
A worked example
| Stage | Content |
|---|---|
| Complaint | Accountant: "invoicing takes too long" |
| Example | A 50-line wholesale invoice keyed from a paper order |
| Goal | Stop re-entering items already on the order |
| Requirement | As a sales accountant, I need to create the invoice from the approved sales order so I do not re-enter items and prices |
| Acceptance | One click, items, quantities, prices and taxes carried, partial billing possible |
| Classification | Standard setup and training: enter orders in the system |
Preferred solution order
- Existing feature.
- Settings.
- Workflow or notification; see clear workflows.
- Report or dashboard.
- Small customisation.
- Development, documented, only when needed.
Organising requirements
- One register, managed as tasks or tickets.
- An owner per requirement.
- Clear priority.
- Linked to scenarios.
- Regular reviews with key users.
Common mistakes
- Building the user's proposed fix without the goal.
- No acceptance criteria.
- Every complaint becomes development.
- Ignoring "unclear" complaints until they become resistance.
This is a strong tool against resistance to change. Operion's methodology builds analysis on it; talk to us.
Frequently asked questions
Complaint vs requirement?
A complaint expresses pain; a requirement states a specific need for a role with benefit and acceptance criteria.
Requirement format?
As a [role], I need [capability] so that [benefit], plus testable criteria.
Does every requirement need development?
No; many are solved by features, settings, training or workflow.
Who approves requirements?
The department key user and the project decision-maker.
