Expressing Requirements

Writing clear specification text isn't easy. It must be clear to readers:

• exactly what a requirement is asking them to do
• how they know if they've "passed" (i.e. conformed)

Keep the following guidelines in mind when drafting the Profile and look at them again when reviewing the Profile for publication at any Stage.

1. Put requirements in the Checklist/Specification tables
   • The Discussion section is for additional information but can be skipped by folks who just want the requirements; hiding additional requirements in Discussion would be sneaky.
   • Requirements are grouped in Checklists (by Actor) and in Specification tables (by Activity). Copy/re-sort them carefully before you publish so they're not different.
2. Start each table requirement with the word "Shall"
   • It promotes direct wording and makes it clear this is a requirement.
   • Searching a document for Shall steps you through all the individual requirements.
   • Sentences with "must, has to, needs to" are not requirements so don't confuse readers by using those words.
   • Sentences with "should, could, might, etc." are also not requirements but may be useful to provide informative recommendations.
3. Don't use "shall" outside of tables or procedures.
   • Shall is for requirements. If it's a requirement, put it in a table. If it's not a requirement, don't use shall.
4. Use active voice
   • "| Physicist | Shall record the date/time of QC procedures." rather than "The date/time of QC procedures shall be recorded."
   • Passive voice makes it less clear who has responsibility for the requirement being met and what they have to do.
5. State requirements bluntly
   • Conformance is clearer/simpler/cheaper if it is binary; you either do or do not ("there is no try" 05.04).
   • Leaving ambiguity and wiggle room makes conformance checking more confusing.
   • Rigor is necessary to achieve the claimed performance (and the process of failing should hopefully lead to improvements).

   • Systems/sites that fail conformance will be correctly informed they are likely not achieving the claim (and they're no worse off than when they started).

6. List a single actor for each requirement.
   • It needs to be clear who is responsible for the requirement being met. You don't want the requirement unmet because two people both thought the other was taking care of it.
   • The Profile doesn't care HOW the actor gets it done, and if they explicitly delegate it or hire someone that's fine, but if the requirement is not met, it needs to be clear which Actor is responsible.
   • The Profile doesn't care if one human takes on multiple roles. In a given hospital the same person may take the role of both Radiologist and Image Analyst.
   • Some profiles add notes in the discussion to clarify these details.
7. For each requirement, consider how you would assess conformance.
   • If assessing conformance is obvious and will be done consistently, that's fine.
   • If it requires a specific procedure, add the procedure to section 4 and reference it.
   • If it's unassessable in practical terms, then it's not a useful requirement so drop it.
8. Speaking of dropping requirements, review the guidance on Vetting Requirements
   • Make the irreducible basic elements as simple and as few as possible but not simpler/fewer. (Einstein)
9. If you would not fail someone for not conforming to the requirement, then drop the requirement.
   • It doesn't have to go away completely. You can keep it as a suggestion in the Discussion if it's helpful.
10. Dropping requirements is fine but make sure you revise your claimed performance accordingly.
    • If dropping it leaves a source of variability in play, then your test data and the performance estimates should incorporate that variability.
    • If the Claim cannot be achieved with the stated requirements, you need to tighten the requirements or loosen the claim
11. Don't repeat requirements in the Claim section
    • The claim is already contingent on conforming to the requirements; restating requirements in the caveats of the claim is redundant.
12. State a requirement once.
    • Stating it twice means you have to remember to revise the text in two places each time you change it.
    • Worse, using different wording introduces conflicting loopholes and interpretations.
    • Checklists are a special case; it's recommended to either create Checklists first then clone and regroup them into the Specification tables when you are ready to publish, or visa-versa.
    • Don't reword requirements when cloning them between checklists and specifications (see loopholes above); if you prefer different wording, change both.
13. Exception: Symmetric do-then-check requirements
    • It is sometimes useful to do something, then later to confirm the result.
    • This is not technically a duplication since they can be for different actors, and the "do" requirement assesses the actions, while the "check" requirement assesses the result.
    • E.g. In the acquisition activity, "Technologist - shall instruct the patient to lie still and breathe as instructed" and in the QA activity, "Radiologist - shall confirm the absence of patient motion artifacts"
    • If the "problem" is rare but important, consider keeping the "confirm" requirement but dropping the "do" requirement.
    • An advantage is that it often makes sense to describe the required result in detail but not be too prescriptive on the method.
14. Avoid synonyms.
    • If it's the same thing, use the same word.

    • Don't refer to the workstation, the Image Analysis Tool, the measurement software, and the Analyzer if it's all the same thing. Pick one.

    • A single term makes it easier to search.
    • If you use different words, you make people think there is a subtle but meaningful difference and they may invent one.
15. If you figure something out that's not here, tell the Process Committee
    • These are just some guidelines we've figured out so far. Rome wasn't built in a day. Actually they've never stopped building it. So we start living in it and improve it as we go.