Writing unambiguous requirements is about understanding what is written, and what is read. Without a clear understanding of your market, you can’t write unambiguously. Even when you understand your market, you risk writing something that is ambiguous to your readers. Documenting requirements is about communication. Don’t break this rule, or […]
You Must Not Write “The System Shall…”
A lot of books and blogs and experts tell us to use “The System shall…” when writing requirements. Read on to find out why that’s not a very good idea.
Flashback: This Week in the Past on Tyner Blain [Feb 16]
A look back at the best from this week in the past.
Logical Requirements
We talk about characteristics of good requirements, including completeness, correctness, and ambiguity. But how do we assure that our requirements are complete, correct, and unambiguous? Simple, Captain, with logic.
Monty Python and Software Requirements
The Monty Python troupe helps us remember five (no, three sir!) things about software requirements. And now for something completely different…
Writing Unambiguous Requirements
One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.