These requirements "smell" and not because they’re in a gym.

It’s been said ad nauseam, to the point of being a "law" of engineering: writing requirements well is not easy.  The sign depicted here is in a hotel fitness room and is a clear example of just how true this is.  (Click on it for a larger, more readable image.)  Some requirements simply "smell" funny.

Agile doesn’t "fix" this and neither does CMMI. 

What agile does, however, is provide several ideas on how to minimize the negative impact on the challenge of poorly written requirements.  Some of these ideas include close proximity of the customer and/or users, frequent iterations and demonstrations, only incremental value added between demonstrations as opposed to huge bounds between them.  These ideas, however, are their own practices, processes and procedures. 

What’s in CMMI regarding requirements has more to do with eliciting them, decomposing them, thinking them through, validating them and then managing them.  What CMMI doesn’t supply is anything about writing them well in the first place.  Before any CMMI experts argue this point, make it through the next two paragraphs.

Notice that agile doesn’t either.  All agile does is mitigate the risks posed by poorly formed requirements.  While a few practices in CMMI can foster opportunities to catch poorly formed requirements, none of the practices in Requirements Development (RD) or Requirements Management (REQM) actually prevent an organization from writing them poorly in the first place. 

True that review of the work products of RD and REQM *could* uncover poorly written requirements but that assumes the organization has experts or standards capable of creating well-written requirements or catching when requirements aren’t well-written.  An organization poor in the requirements expertise bench wouldn’t glean much from CMMI by way of what "well written" means to that particular product, project, user or organization.

A good friend and colleague, Dale Emery has a few ideas on how to ferret out requirements that "smell".  While Dale’s material dealt with "problems" that smell, I’ve adapted them to smelly requirements.  Whether they are buried in user stories or come to you in a BHB ("big honkin’ binder"), here are a few of the "tests" you can run to determine whether your requirements "smell" or not:

• No user(s) identified for a feature.
• An identified user is not part of the system.
• A solution is embedded into the expectation that’s not validated as a priority for the system.
• Exceptions are the rules.
• Exceptions are ignored because they’re "rare".
• Written on non-validated needs.
• Unexpressed (unfunded?) pre-requisites.
• Any hint of emotion or blame.
• Uses terminology of what’s not desired rather than what is.
• Assumes/asserts a priority (in a vacuum).
• Can’t find an audience to care about what’s in it.
• "Should", "Can", "Could", "Might", etc.
• Assigns responsibility to another part of the system.
• Any absolutes.  (Some are necessary, but all should be verified/tested.)

What makes the above sign smell?

Hint: it’s not the sweat.