Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Monday, August 13, 2007

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.
Requirements Defined Newsletter Bookmark and Share

1 Comments:

Blogger Roger L. Cauvin said...

Great minds think alike, Marc.

8/13/2007 5:50 PM  

Post a Comment

<< Home