The Requirements Language Dilemma

Writing requirements has been a challenge for us for many decades now. Why is it so difficult? Well, one of the reasons is the challenge of the requirements language. We know we need to write requirements in a manner that can be read and understood by the reader. If we are writing user requirements, the reader is a business owner, end user, or stakeholder and the focus on writing in a “natural” language. The problem with a “natural” language however, is that is very imprecise and likely to be misconstrued or misunderstood. How do we bridge that gap?

I am amazed at the number of analysts I speak with that resist any kind of structure in their requirements writing. They appear to be quite happy with their unstructured approach that usually consists of descriptive paragraphs and sentences that imply many additional requirements. Their readers like this method they argue. The problem is that once these “requirements” are handed over to developers or systems analysts there is usually a lot of discussion back and forth to clarify what these requirements really mean.

I believe there is a compromise to be made here. Look at this slide from our Requirements Management Course.

Here are some tips to help bridge this gap.

1. Write in active voice, making sure one of the actors is the subject of every sentence.
2. Make sure every sentence is a complete and grammatically correct sentence with a subject, verb and predicate.
3. Clearly specify what information is passed between actors.
4. Maintain a consistent level of detail. (i.e. user requirements – an end user is the subject of every sentence, system requirements – a system is the subject of every sentence)

Good luck with your requirements and Happy New Year!