notes and views on crm, social media, and the human side of information technology

Requirements vs design

THERE ARE 2 TYPES OF PEOPLE WHO PROVIDE YOU WITH REQUIREMENTS:

The first group has a vague feeling about their need. You need to find the spot that itches and scratch it. They’ll expect you to know what they are thinking and won’t talk to you unless you are finishing their sentences and materializing their ideas on paper. They are easy to deal with when you’ve done your share of similar projects and can be their partner.

The other bunch is tricky. They may or may not know what they need but they sure as hell will tell you how you are supposed to do it. Example:

You walk into a meeting determined to (finally) get to the matter; if it takes interrogation of the 3rd degree, so be it. You’ve recently had a training of negotiation and other soft skills, so you are pretty confident you will, at the end of the day, know what they really want.

After a short chit-chat, they cover the table with Visio printouts and tell you where the buttons should be, what color, how will Systems X and Y integrate, how exceptions should be handled (the form will turn red and the user will click away a series of error messages…), et cetera.

Now, what’s a BA worth his name to do?

Talk about requirements, and you annoy them because they obviously know what they want and you are wasting their time. Concede the point and discuss their design, and you might end up with a solution that - surprise! - doesn’t serve their needs in the end. Why? Because their needs were so obvious they haven’t been tested.

Which brings me to my point. Business analyst is a natural partner and advocate of business needs and should fight for their fulfillment with both PM’s eager to slash the scope and developers who just want to do their thing. And as a good advocate, he has the right to extract and validate any information from his client that he needs to build his case. And damn well test it is since the opposing counsel will use whatever weakness he can find.

This isn’t about “translating” business requirements into technical specs, as the popular misconception about business analysis goes. Translating would mean taking whatever the client says and telling developers to build it. But if you do just that, you are wasting the oxygen in the room since developers could take such orders from business directly - who said they don’t speak plain English?

So - burn those Visio printouts. They stand in the way of understanding and obscure, not convey, what the needs are.

Additional reading

July 4, 2007 | Filed Under Software delivery 

comments

Leave a Reply