Design is a poor substitute for nonfunctional requirements

Share This Post

I’ve traditionally been somewhat neutral on what amount of design gets slipped into a requirements document. I’m a consultant, and to a certain extent, I’m willing to accept that the things that are important to a customer ARE the requirements, whether they are true “business requirements” or a design that indicates a choice by the customer to solve a business problem in a particular way.

What I don’t like, however, is for design to be used as a substitute for non-functional requirements. Non-functional requirements are hard. It’s not easy to define at an abstract level what your “usability” requirements are. Since people don’t want to take on the hard task of defining “usability”, they tend to instead simply “design” something that they think is “usable”.

How do you know when this is happening? Take a look at the non-functional requirements section in a document. If it’s small compared to the functional requirements, it’s a good indication that someone has decided to use “design-like” functional requirements to get around doing a good job on the non-functional requirements.

More To Explore

It’s a Matter of Trust

The combination of pandemic and moving to a rural community has increased the amount of shopping I do online, but even before those events I found myself depending more and

Thoughts from SAMA

I was recently able to attend the San Antonio Manufacturers Association Trade Show & Conference (SAMA). Like all live events I have had the pleasure to attend this year, the