Chapter 8. Nonfunctional Requirements

in which we look at those requirements that specify how well your product does what it does

How can something called “nonfunctional” be important? Consider this—it really happened. The client rejected some help desk software after it was delivered. The functionality was correct in that the software supported the help desk’s activity, but the client didn’t want it. Why? Because the users were refusing to use it, preferring to go back to their manual procedures. Why was the product so bad? Because the requirements team ignored the nonfunctional requirements.