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.

Cut, Paste, and Why Requirements are Tricky

I've been using PDAs for about 10 years now.  So, while I wasn't the among the fist Apple Newton users,  and I didn't buy the first version of the PalmPilot®, I did follow shortly thereafter with another Palm device and was a Palm fan until it came time for me to move to a "crackberry" because I could no longer wait for Palm to come out with an email-over-air device.

Rest assured, when Palm came out with its Treo 650, it couldn't have been a moment too soon, as I lusted for it upon its announcement and needed only the smallest excuse to plunk down about 500US$ for it at the time.  That excuse came in the form of hardware failure on my RIM device.  (It was getting up in age -- not to mention that I bought it 2nd-hand.)

Well... my life with the Treo was bitter-sweet.  Software and synchronization/integration issues brought my productivity to a grinding, frustrating, halt.  By then I was keeping tabs on the latest Windows Mobile® devices purveyed by my wireless provider and saw that a device was due with *everything*.  A good phone, Email, text, browsing, broadband-over-wireless, WiFi, and simultaneous phone and Internet access all built-in.  I practically counted the hours until it was finally released after being tantalized mercilessly by the press releases and ads.

Life was good.  I really had no complaints.  Until a few days ago.  It died.  Well... mostly died.  The touch screen stopped responding, to be specific.  Despite a built-in keyboard, the device relies on its touch screen.  And, in the middle of a business trip, the touch screen stopped working.  Back at the hotel, and a while at my laptop, I learned that this seems to be common for that device.  In fact, I found myself considering myself to be lucky it lasted the roughly 20 months it did.

I put together my list of requirements, prioritized them, and a bit of research later I'd settled on my next device.  Being due an upgrade anyway, I decided to stop in at a local store to get one on my way to the airport for my flights home.  I decided to go with a device from another manufacturer that didn't have a touch screen since the previous day's experience taught me that relying on a particular feature for functionality was risky.  I was even willing to sacrifice the WiFi requirement to gain a form-factor benefit, so I had a bit of technical/performance trading-off to do.

A few hours of messing around with the new device and I was both pleased and perplexed.  Everything seemed to be what I had read about it.  Oddly enough, I couldn't figure out how to cut or copy and paste.  Furthermore, I could only find one alarm.  Which, for anyone power-using their PDA knows, alarms are critical.  So, back in my home, I downloaded the complete user's guide (since all they put in the box these days with new phones is the "quick start" guide).

Reading through the guide I learned that, indeed, the device should have Copy/Cut & Paste, as well as two alarms (which is still lame, but 'fixable' with 3rd party software).  So I called the manufacturer -- a world-wide company renowned for being early adopters of what's known in the industry today as "6-Sigma" -- and spoke to a customer technical representative. 

The conversation went something like this:

Me: I can't seem to cut and paste, but the user guide says I should.  I mean, it's not that it's not working, it's not even in the menu.

Rep: No, my technical notes [a.k.a. "release notes"] don't say anything about being able to cut and paste unless you're in [application].

Me: Yes, I can do it in [application] but I should also be able to do it elsewhere.

Rep: Why do you think so?

Me: Because it's in the user guide and it's a basic function.  Why wouldn't you be able to cut and paste?

Rep: What user guide are you looking at?

After guiding the representative to the exact user guide I was looking at, she apologized and said that the guide is wrong, but the phone doesn't actually have that functionality.  So I moved on the why the phone doesn't have more than one alarm.

Me: OK, so can you tell me where I might find the functionality to set more than one alarm?

Rep: Sure, just go to [......]

Me: Yes, I'm there, just like in the user guide.

Rep: [Sounding surprised] Oh, that's strange, I've got a phone like yours right here and you're right, it only has one alarm.

Me: Would that be another user guide defect?

Rep: Yes, it seems so, I'm very sorry.

Me: "Sorry" doesn't change the fact that your defect rate is way too high here.  What happened to 6-sigma over there?

Rep: I'm very sorry.  I don't have any other information for you.

. . .

I was rather quite disgusted and was halfway out the door to my local store to return the device by the time the phone was back on hook.

After all, I'd become accustomed to copy/cut and paste on a PDA for over 10 years.  What sort of PDA doesn't have cut and paste?  How is that a business device as it's intended to be sold and used?  No copy/cut and paste from email, text messages, or the web?  Furthermore, it seemed that the manufacturer *did*, in fact, expect that basic function to be shipped.  So what happened?

Clearly, there were errors in the user guide, in the representative's information, and inconsistencies with the device.  In CMMI, we'd find these defects avoided in strong practices in traceability, work product verification against requirements, technical data packages, releases/baselines, and configuration audits, and validation, among others.

Yet, I realized that none of my research included checking whether I could cut and paste, or even how many alarms the devices have.  In fact, they weren't among my requirements at all.  They were just assumed to be "basic" functions!

So, in the store I look at the device I ranked #2 in my previous research.  Lo-and-behold!  It has the exact same lack of functionality as the earlier device despite being from different manufacturers!  What does that indicate? 

It's a supplier issue!  Both manufacturers must get the software from the same supplier!  Hence, the one company's expectation of functionality to the point of including it in their user guide and release notes only to later take shipment of the supplied wares without all expected features and functions!  What I then put together (in about a nanosecond) was that someone (sometimes someone tied with marketing?) promised to ship the product to the consumers but the product wasn't ready!  In fact, they expected certain features and functions but for some other reason the supplier of the software couldn't keep to the pre-defined delivery schedule!

(In any case, I ended up with my #3 choice, the one with the touch-screen I was trying to avoid.  I'm quite pleased with the improvements they've made since the previous version.  They've also improved on the form-factor.  And, as a bonus, I've already got plenty of accessories for it.  So I can save a little money there.)

Were there defects in the first attempted purchase?  Were these defects excusable?  Those aren't really the point to this post, are they?

The point is this: Requirements are tricky.  For lack of complete requirements a company has earned themselves a tarnished reputation, and I spent several hours being frustrated and having to take unscheduled time to deal with the error.  However, at least from my perspective, I could recover easily.  The iteration time and the correction were both fast.  In other words, I failed early and adjusted.

Were my requirements unreasonable?  Probably not.  But the episode highlights the challenge with requirements and the benefits to being flexible, iterative, and able to correct quickly.  Customers or developers who believe anyone will have all the requirements right and complete -- including all the assumed and derived ones -- are fooling themselves.  Witness the supposedly 6-Sigma manufacturer who "froze" the requirements based on what they thought they'd get and now they've got a black eye.  Whereas for myself, I iterated, and got the right product after all.