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.
John Terzakis
John Terzakis has more than twenty-five years of experience developing, writing, and testing software. With Intel for fourteen years, John is currently a staff engineer working with teams on enhancing product requirements to reduce planning and development times, reduce defects, and improve overall product quality. He is a certified Intel instructor for Requirements Engineering courses. John’s prior experience includes director and manager roles with Shiva, Racal InterLan, and Dataproducts. He was also a member of the technical staff at Bell Labs.
One key to specifying effective functional requirements is minimizing misinterpretation and ambiguity. By employing a consistent syntax in your requirements, you can improve readability and help ensure that everyone on the team understands exactly what to develop. John Terzakis provides examples of typical requirements and explains how to improve them using the Easy Approach to Requirements Syntax (EARS). EARS provides a simple yet powerful method of capturing the nuances of functional requirements. John explains that you need to identify two distinct types of requirements. Ubiquitous requirements state a fundamental property of the software that always occurs; non-ubiquitous requirements depend on the occurrence of an event, error condition, state, or option. Learn and practice identifying the correct requirements type and restating those requirements with the corresponding syntax. Join John to find out what’s wrong with the requirements statement—“The software shall warn of low battery”—and how to fix it.