21 Nov 2007 0500H

Some thoughts on reqs analysis

First off, I’ve worked with lots of clients, thousands of users, and not a few analysts along the last 12 years — some good, some awful, like anything else in life — and I tend to think that the fact I’m still here in this industry working with some pretty happy clients indicates that I know something about user experience. But the one thing is, requirements are requirements and they’re guided by the different reasons why we’re gathering them in the first place. Oh sure, you can do ethnographic techniques such as guided walkthroughs of actual users in settings, or you can do more surreptitious methods of observation, but, in the end those requirements have to be guided, sifted through, balanced against other business and functional requirements, and documented and refined just like every other set of requirements. The process is fundamentally the same. There are edge cases, there are unhappy paths, and there are people whose needs we shouldn’t be designing for at all. Maybe we throw a little agile here to get whiteboarding and testing sooner on the UI, maybe we throw a little waterfall here so that there are stage gate/checkpoints in our process. But really, the stuff isn’t so different for different groups of people and I challenge anyone to tell me otherwise.

The second thing is, man — you think you can do without a good business analyst or requirements architect, but then when you really do need one,when you don’t have one for a project, you really miss that role and then you have to sacrifice time you don’t have to pick up the slack, which can be quite considerable depending on the complexity of the project. The worst part is that when someone is underperforming on a gig, others are required to work even harder to make up for that person. Many years ago I was in that position where I was junior and suddenly found myself having to pick up whole new skills and get used to working on a very large, complex job without much guidance, and in the end I recognized that I was becoming more of a burden to the project than an asset. At the time of course, I think there was a lot of anger at how the situation had spiralled down this road, but, basically, you have to recognize this yourself. It’s kind of unfair to bring in a junior person into such a job, and people should know that ahead of time, because inevitably, you’ll need to either hold that person’s hand a lot or you’ll need to spend a lot, I mean a lot of time reworking things. Bring in a seasoned reqs architect and no one gets hurt.

The third thing is that ironically after all the work goes into generating the document, no one actually READS the requirements, which seems to me to generate more meetings because we still have to go through the requirements document since no one will actually read the darn thing and yet we still have to get cued up to get our job on. Collective read out of the requirements is essentially an alignment session for everyone on a team, much like everyone rehearsing a script. See, ultimately everything is an act of theater, even computing.

Permanent link to Some thoughts on reqs analysis

Filed under Technology, Work

Be the first to respond to "Some thoughts on reqs analysis"

RSS feed for comments on this post. TrackBack URL

No responses yet.

And now it's your turn.

Fire your weapon, soldier. Just be careful of friendly fire. NAME & EMAIL required.

Your response