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
Posted on:
Flashback: This Week in the Past on Tyner Blain [Feb 16]
A look back at the best from this week in the past.
Communication / Requirements / Writing
Posted on:
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.
Communication / Requirements / Requirements gathering / Writing
Posted on:
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…
Outsourcing / Product Management / Requirements / Software requirements specification / Writing
Posted on:
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.
Communication / Requirements / Software requirements specification / Writing
Posted on:
Writing Requirements Unambiguously
Writing requirements without ambiguity
This is one of the harder parts of writing good requirements. Marcus tells us to avoid it with a good example here. Jerry Aubin at Seilevel has written an outstanding post on the subject, The art and science of disambiguation. Jerry starts his post with a gripping example from Weinberg and Gause:
Communication / Software development
Posted on:
Outside reading: Enterprise versus consumer software
Cote’ recently posted a good comparison of the features of Enterprise Software versus Consumer Software. Although we may not agree with all the items in his lists (consumer software can have a login, and very often does have upgrade paths), we do appreciate the general classification. And we really like his insight: