Knowing what you need before looking.
WHAT TO DO FIRST
Document how the business actually works.
WHY BEFORE LOOKING AT PRODUCTS
Otherwise vendors define your requirements for you.
WHAT TO CAPTURE
The processes that matter Volumes and transaction counts Who does what Where problems occur What must not change
WHAT TO DISTINGUISH
Must-have requirements Desirable features Preferences
WHY THAT DISTINCTION MATTERS
Everything appears essential until it is prioritised.
WHAT TO LIMIT MUST-HAVES TO
Things whose absence would prevent operating.
WHAT TO BE SPECIFIC ABOUT
Statutory and compliance requirements Integration with systems you keep Volumes and performance Reporting that is genuinely required
WHAT TO AVOID IN REQUIREMENTS
Descriptions of your current system Feature lists copied from vendors Vague terms like user-friendly
WHY DESCRIBING THE CURRENT SYSTEM IS HARMFUL
It selects for replicating what you have, including its faults.
WHAT TO DESCRIBE INSTEAD
The outcome required.
WHO TO INVOLVE
People who actually perform the work.
WHY
They know the exceptions that break systems.
WHAT TO PRODUCE
A document you would give any vendor.
