Specifying Non-Functional Requirements NEW
Non-functional requirements present unique challenges for authors, reviewers, and testers. Non-functional requirements 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. Definitions of easy, intuitive, and quickly are open to interpretation and dependent on the reader’s experiences. In order to be testable, non-functional requirements must be quantifiable and measurable. John Terzakis discusses the problems with non-functional requirements—weak words, ambiguity, and unbounded lists. To facilitate the development of quantifiable and testable non-functional requirements, John introduces a solution—Planguage—and its associated keywords. By documenting requirement-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. Explore exercises to apply these ideas and develop the skills you need to improve your non-functional requirements.