Specifying Effective Non-functional Requirements

Non-functional requirements present unique challenges for authors, reviewers, and testers. They often begin as vague concepts such as "The software must be easy to install" or "The software must be intuitive and respond quickly." As written, these requirements are not testable because they are subjective. Definitions of "easy", "intuitive" and "quickly" are open to interpretation and dependent on the experiences of the reader. In order to be testable, non-functional requirements must be quantifiable and measurable. John Terzakis discusses the subjectivity problems with non-functional requirements-weak words, ambiguity, and unbounded lists. To facilitate the development of quantifiable and testable non-functional requirements, he introduces a solution-Planguage-and its associated keywords. By documenting requirements-specific parameters-scale (unit of measure), meter (method to determine the position on a scale), and range of success-you can remove subjectivity and ambiguity so that non-functional requirements are expressed in quantifiable and testable terms.