Recommendations For Producing Valid Requirements | for Business Analysts

Recommendations for producing valid requirements:

Prefer using the word “shall” to state a requirement. It enforces what the requirement must do.

Use one “shall” per requirement. If there are multiple “shall” then probably there are multiple requirements and break them accordingly.

Keep the requirement very short and simple.

Use consistent terminology

State the requirements positively. Do not use “shall not” or double negatives.

Prefer having notes and comments against requirements to support and clarify. It will give you a context of what you are covering and help you understand your assumptions with supporting info later.

State what the requirement would achieve explicitly and confidently without an iota of doubt.

 

Terms to avoid:

Avoid using the words “will”, “should”, “can”.

Always be clear and avoid terms that cause confusion like  “support”, “and/or”.

E.g System A shall support the reporting interface of System B. Instead be specific and you could say;  System A shall provide the data to be displayed by System B.

Always be precise and avoid words or phrases that may suggest incomplete thought. Avoid words like “but not limited to”, “etc”.

Avoid the terms that are not precise or cannot be measured or are open to multiple interpretations. E.g  Adequate, Approximately, Better than, Rapid, Substantial, Sufficient, Timely, Comparison, Easy, Maximise, Minimise, Optimise, etc.

Avoid terms that are unclear. E.g. Maintainable –  the system should be maintainable. Instead, be precise. The system should have a non-technical admin to perform upgrade or clean-up every month.

Avoid terms that suggest an assumption

E.g.

Normally – be explicit of what should happen each time

Quality product – explicitly state the quality indicators

The post is  based on my notes and understanding from this BA tutorial