Its not what your Requirements do...

…but its what people do with your Requirements.

If you’ve been reading this blog for long now, you know that I’m an unabashed Apple fanboy (who also works with Linux and Windows at his day job, has a Chrome OS netbook, 2 Apple laptops, 2 iPhone 4s, a classic iPod and a 1G iPad). Given that, you probably won’t be surprised at how much this article captured my attention. Its something I’ve believed for a while, that when a product is right, it can do amazing things in the hands of the most common (or even sub-par) user.

Why are requirements not the same? I remember, not so long ago, when I actually told one of my BAs that “You just start requirements by saying ‘Have the ability to…’ no matter the subject of the requirement.” I think back on that and just want to slap my younger self in the side of the head for completely missing the point.

I can only imagine what it must have been like for my user community to read that document. (Come to think of it, that project got killed before it started, so its unlikely anyone ever read that document. Thankfully.) It was likely so dry that they decided War and Peace was a less painful, and shorter, read.

But in the right hands, dare I say the hands of a master requirements craftsman, your requirements can do amazing things for your stakeholders. The biggest thing quality requirements can do is to get your stakeholders to use them.

I’ve noticed that stakeholders seem to care about requirements at two points. First, when they are outlining their vision or problem to you, the analyst. Second, when they need someone to blame that their vision can’t be accomplished or their problem isn’t solved by the process and/or system that has been implemented. Part of this is because stakeholders often view requirements as a bothersome process that takes them away from their important work.

Imagine if we wrote our requirements not with system implementations in mind, but with the idea that they teach the business how to operate more effectively regardless of the software they use. Imagine if our requirements documents provided the basis for departmental policy and procedure and not just how we display text on a screen. And most crazy, what if our requirements could plot the future strategy of the organization and not just the layout of the new coversheet for your TPS reports.

So how do we get there? How do we help our stakeholders understand that what we do isn’t a prelude to software but is a truly value-add part of their business? I don’t know of any magic, but here’s a few things I do to try and help.

First, make it about the relationship. Requirements are not a document, series of statements or a big set of process flows. Requirements define needs and wants of stakeholders. The only way to really understand and draw out those items are through relationships with our stakeholders. Its corny, but our stakeholders really don’t care how much we know until they know how much we care. Take the time to get to know them as people and to let them know you as a person.

Second, make requirements something they want to review. I’m not suggesting lacing a document with 1 liners or even hiding 'easter eggs’ with door prizes attached to see who really reads that 300 pound document. It doesn’t need to read like a romance novel, but it does need to be read, comprehended and then become actionable by our stakeholders. We’re told we should write to achieve clarity, but what does that mean? The dictionary is written for clarity but by no means do I want to sit down and read that!

It is easier said than done. Most of the time BAs sit between the business and the project team. We’re trying to write with multiple audiences in mind. Creating one version of requirements in business-speak and another in tech-speak is a recipe for disaster. Creating one version for all purposes is nearly as bad. What our goal should be is a single, common lexicon that all members of the project speak, one that is specific and measurable enough for the programmers yet encompasses all the vagaries that make up our business people’s lives.

This isn’t easy; its a delicate balancing act that I have come to realize is something that can not really be taught but must be learned. I’ve been thinking about ways to teach this for years, yet continually come up empty when trying to show new BAs how to do this. No answer has yet presented itself, but with time I hope to find better ways and then share my insights with all of you.