a blog

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.

July 4, 2007 | Filed Under Software delivery 

comments

Comments are closed.

Additional comments powered by BackType

  • subscribe

  • One man's microISV

    Playground - an on-demand requirements management tool helping you get the right things done.

  • Lifestream

    • ... problem is they are already there about 23 days ago
    • So the Taliban stoned some adulterers recently. I wish US/NATO would bomb them back to the Stone Age but the problems about 23 days ago
    • Not sure that Wave is gone altogether. I can imagine it creeping into Gmail eventually. But why didn't they kill Buzz instead? about 33 days ago
    • Rooting for Uruguay. Still bad memories of CZ vs NL a couple years back. Plus I really like URU's game. #worldcup about 64 days ago
    • @ktorn what kind of app are you going to make for your Samsung? about 65 days ago
    • Firefox 4 nighly looks pretty good to me. But I still have to restart it after installing add-ons? Hope they'll fix that one day soon. about 70 days ago
    • I love that I can put MY photo on friggin Google HOMEPAGE! about 90 days ago
    • Or more precisely, it does seem a bit smarter AFTER you've visited a given URL that corresponds with the query about 92 days ago
    • Safari 5 doesn't seem to have a "smart" location bar. Enter "Google Reader" and it tries to navigate to http://google%20reader/. #fail about 92 days ago