The Third International Conference on Access Networks ACCESS 2012 June 24-29, 2012 - Venice, Italy

Tutorials

T1. Specifying Effective Non-Functional Requirements
John Terzakis, Intel, USA

Non-functional (quality and performance) requirements present unique challenges for requirements authors, reviewers and testers.  They often begin as ambiguous 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 in nature.  The definitions of words like "easy", "intuitive" and  "quickly" are open to interpretation and dependent on the experiences of the reader.  One person's "easy" could be another person's "difficult".  In order to be testable, non-functional requirements need to be quantifiable and measurable.  This tutorial introduces the concept of Planguage, and its associated keywords, that facilitates the development of effective, testable non-functional requirements.

Writing effective non-functional requirements involves removing all subjectivity and replacing it with well defined testing parameters.  Subjectivity is removed by eliminating weak words, ambiguity and unbounded lists.  Well defined testing parameters include a scale (unit of measure), meter (device or process used to determine the position on a scale) and the Landing Zone (or range of success).  With the non-functional requirement now rewritten in quantifiable terms, the testing space is bounded and the requirement becomes verifiable.

This tutorial will first present definitions and examples of functional and non-functional requirements.  It will then show examples of non-testable, non-functional requirements and an analysis of why each one is not testable.  Next, the concept of Planguage and its associated keywords will be introduced, along with an explanation of how they help improve testability .  Several of these keywords will be discussed in depth including scale and meter.  Finally, this tutorial will revisit each of non-testable, non-functional requirements examples and rewrite them to be testable.  Hands-on class exercises will reinforce the concepts taught.  Students will be able to begin applying the concepts immediately.