Design is a poor substitute for nonfunctional requirements

ArgonDigital - enterprise automation experts

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

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage