Step 3 · Turn Needs Into Requirements

Translate the problems identified during the needs assessment into clear operational, technical, integration, security and usability requirements.

Full guide planned · 12 min read
Step 3 · Turn Needs Into Requirements

The short version

A need sounds like “we need to know what equipment is on each apparatus.” A requirement sounds like “the system must allow crews to verify assigned equipment at shift change and identify missing or expired equipment.” One describes the gap; the other can be tested, demonstrated and written into a contract. Sort what you write into must have, should have, nice to have and deal breaker, and keep the categories separate — operational, technical, integration, data, cybersecurity, reporting and support requirements each get answered by different people, and mixing them is how the awkward ones get lost.

See it applied

Go deeper

Questions to ask your vendor

  1. Which requirements are must have, and which are genuinely nice to have?
  2. What is an outright deal breaker for us?
  3. What must the system do operationally, at shift change and on the fireground?
  4. What must it integrate with, and in which direction?
  5. What data must it hold, produce and let us export?
  6. What cybersecurity requirements apply, and who decides them here?
  7. What reports do we need out of it, and who reads them?
  8. What support and response times do we require?

This is a reading list, not a guide

Everything above was published by someone else, and is here because it is the clearest treatment of the subject we could find and verify. The Hub’s own guide to this topic is still being written. If you know a better source than the ones listed, that is worth telling us before it is.

Send a note