1. Get SMART

Requirements should be specific and appropriate for the desired system.

Remember get SMART:

• Specific
• Measurable
• Achievable
• Realistic
• Testable

2. Clear and Precise

Requirements should be documented in a clear concise manner for the vendor or supplier.
Do not leave any room for ambiguous requirements allowing scope for the vendor to suggest their product meets the requirement when it doesn’t.

3. One at a Time

Do not double up on requirements; make it clear in your URS one requirement at a time. It will be easier to see how the requirement is handled and it will also make it easier to test later in the life cycle.

4. Testable/Verifiable Requirements

Requirements should be written such that they can be tested. Individual requirements should be traceable through the life cycle from design to test.

5. Prioritize Requirements

Prioritize with emphasis on identifying the mandatory requirements.

Classify them as you see fit.

They could be:

• Mandatory (high)
• Beneficial (medium)
• Nice to have (low)

6. Avoid Duplication

Do not over complicate the requirements of the system and do not duplicate the requirements to bulk up the URS. Having duplicate requirements will lead to more testing, documentation, and review time.

7. Design Review & Traceability

Assure all requirements have been satisfied by performing a design review and traceability. This will prove that the functionality is appropriate, consistent, and meets pre-defined standards and that the system is appropriately tested.

8. Change Control

Changes to requirements should be controlled. Changes to subsequent specification documents that affect the requirements should lead to an update of the requirements.

9. Avoid Ambiguous Terminology

There are several red flag terms you should avoid when describing requirements as they will be difficult to test against.

Some include:

• Easy or Simple
• Intuitive
• Fast or Slow
• Higher or Lower
• Reliable
• Robust
• Flexible
• Efficient

10. Ownership

Without user ownership the business operational needs and any associated issues can never be fully understood and captured. Subject Matter Experts (SMEs), including those from third parties, may help both the user and technical communities analyse and understand the operational needs and develop and document appropriate requirements.