Building Bathrooms and Applications part 2

Posted: June 9, 2008 in Requirements and specifications, Thoughts on development

In part 1, I wrote about some of the reasons I think requirement specifications often have a less than optimal quality. In this post I’ll try to proliferate.

Let’s look at a possible scenario:
The user wants to be able to create/edit and format texts online, no Flash or Silverlight is allowed only DHTML. The editor is going to be part of the company’s CMS.

It should be possible to:

  • Create new text documents
  • Edit old text documents
  • Choose the font type,size and color
  • See the contents in all browsers
  • Include pictures and sounds
  • Insert links
  • Use all Unicode characters

At first this might look simple but ok. However just digging a little we’ll find several problems. Most of them are based in an All-the-cool-stuff-should-reflect-back-on-us-and-al-the-bad-things-on-somebody-else way of thinking. So let’s dig and look at a few of those problems

“See the contents in all browsers”
The coolness of this requirement is of cause that the text will seems as intended in all browsers giving all end users the same experience.
The cost of the requirement would seem to be an incredible amount of testing but hi, thats somebody else’s problem.
A better requirement would be a fixed set of browsers. That would probably end up with a more user friendly editor increasing the coolness but that’s not so obvious to the person specifying the system so the fear of lowering the value will win.

Fonts
How about choosing font type? This requirement leaves a lot of decisions to the developers
Should the font changes apply to the entire text or just a part of the text? Should the editor validate against design guide lines? believing that the developers will make the exact decision the users would want each and every time is a bit too naive.
Again the specification is leaving more unanswered questions than it’s answering.

Actually every single requirement in the list above has the same basic problem. I like to think of it as the “Demand a lot and make no decisions” problem.

The above requirements could be implemented as a online version of notepad, where the user would have to write the HTML by hand.
Even though it would meet the requirements it would be absolutely useless to the customer.
Then the developers and the customer could argue who were to blame.
One could argue that every requirement is met but for the customer to accept that argument would mean they had to acknowledge a loss of Personal Value, which they will be very unlikely to do.
Getting out of a situation like that with every body smiling is a skill on it’s own. My point is that the project ended up there and stays there for the same reason: PPV.

The trick is to act early to make the users realize that there’s a higher PPV in taking those domain specific decisions only leaving the IT decisions to the IT professionals. That’s where building bathrooms comes in which will be the subject of part 3.

Advertisements

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s