Draft for Tamir's review. Not published.
What makes a requirement testable
A testable requirement names who does what, under which conditions, and how you will know it worked. "The system shall be user-friendly" can't fail a test. "A clerk opens a case and attaches a document within a stated time" can.
Write the acceptance test next to each requirement while you draft. A requirement without a test gets rewritten or removed.
Where case-management tenders get vague
Migration of existing cases, integrations, permissions and reporting often decide whether the system works for you. They are also easy to write vaguely. Give them the same test-first treatment as the screens.
Ask bidders to show key requirements on your own sample data during evaluation. That way, the bid you score is closer to the system you accept.
Keeping your options open
Require full data export in a documented format. The next tender then starts from your data, without depending on this vendor's goodwill.
Asking me is free. You get my initial view and the question I think matters most. A full review runs under a short agreement, and the first one includes a no-value, no-fee clause.
What to check before you decide
- Next to each requirement, write the acceptance test, the test data and the pass criteria.
- Rewrite or remove any requirement that no test can fail, such as "user-friendly" or "modern".
- Write the migration of existing cases as testable requirements, including record counts that must reconcile.
- List every integration with its owner, and how you will test it before go-live.
- Require full data export in a documented format, so you aren't tied to one vendor later.
- Ask bidders to demonstrate key requirements on your own sample data during evaluation.