Why aren’t textual requirements enough?

There are many reasons why textual requirements by themselves fail to result in usable, high-quality systems.

First, it is difficult to ensure all the functionality is present:

• All normal (sunny day) functionality?
• All edge-cases?
• All variations of inputs, sequences, and timings?
• All exception, error, and fault cases?
• Qualities of service such as performance, range, precision, timing, safety, security, and reliability?
• All stakeholders appropriately represented?

Getting that much detail is a daunting task indeed. But even beyond that, there is an “air gap” between realizing a possibly huge set of “shall” statements and actually meeting the stakeholder needs. The stakeholder believes that if the system performs a specific function, then in practice, their needs will be met. Experience has shown that this is not always true. Customers often ask for features...