How do your requirements smell?

04 Aug

While delivering the Business Systems Analysis course today one of the participants (Paul Wolf) asked about the FRUEMP acronym (ISO standard 9126: Functionality, Reliability, Usability, Efficency, Maintainability, Portability) for requirements types – he suggested PERFUMe instead, which brings to mind the smell of a system.

It has been my experience on many projects that the NFR’s (Non-Functional-Requirements) are frequently poorly defined – if they are defined at all; getting them wrong or leaving them out is a predictor of project problems.  

Irrespective of the lifecycle model being used on a project we need to understand the quality drivers from a business perspective – where does the “good enough” bar sit for this product, and what are important quality characteristics that actually matter to the customers and how will we know they have been met.

In the Agile space we refer to “smells” as visible indicators of underlying problems.  Perhaps we should consider the lack of a plesant PERFUMe (well understood non-functional requirements) as a really bad smell on any project.

What do you think?

Posted by Shane Hastie


Posted by on August 4, 2009 in Quality



2 responses to “How do your requirements smell?

  1. John Watson

    August 6, 2009 at 10:20 am

    PERFUMe, FRUEMP, FURPSSSS+ whatever flavour you prefer(the smell governs what it tastes like) it should be the Quality Attributes (aka Quality Requirements, Non-functional Requirements…)that make up the majority of the fitness-for-purpose criteria of any product or service.

    80% or more of the designer’s problem is governed by the “smell”; less than 20% is governed by the functional requirements.

    I suggest that at least 90% of the requirements effort in every sprint, iteration, time-box or whatever you want to call it should go into applying deodorant: focus on the Quality Attributes.

    Next question — “Why don’t people put more effort in the Quality Attributes?”

    Answer — “Cos it’s hard to do”

    Solution 1 — Keep on asking “How will you know when it’s (the product or service) a good one?”

    Solution 2 — Deliver a little, deliver early, and deliver often — but don’t cut code until the last possible moment.

  2. jwpegasus

    August 6, 2009 at 10:26 am

    Actually Solution 2 should be:

    deliver and test a little, deliver and test early, deliver and test often — but don’t cut code until the last possible moment


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: