ArgonDigital - enterprise automation experts

Share This Post

Design is a poor substitute for nonfunctional requirements

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.

Design is a poor substitute for nonfunctional requirements

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage