It’s a requirements analyst’s worst nightmare. You’ve been assigned to capture requirements for an insanely complex system. Your customer is suffering with their existing system. You’re excited, because you know you’re going to make a big difference in the next generation of the customer’s software.
And then you hit the wall: the users.
You’d think that a user base would be excited to be able to tell you what they want in a piece of software. You’d think they’d feel empowered by getting a chance to feed their requirements and pet peeves into the replacement for the system that they hate. They’ve been living with work-arounds and limitations for years, and you’re going to set them free.
But instead, the users are distracted and resentful.
Why would this be? There are actually a number of reasons why users may be reluctant or disillusioned with the requirements process:
1. They have real jobs to do.
Users may have been told to go meet with you, but many of them have “real jobs” to do. They have deadlines, work backed up, and a family waiting at home that they are going to see less of this week because of you.
2. They’ve been through this before.
Think you’re the first guy to come through and ask them about use cases? Many companies have made efforts over the years to collect requirements. They’ve burned a lot of user cycles on this effort, and some users may be remembering the last guy who came through to ask them “What’s the first thing you do in the morning?” If that exercise wasn’t worthwhile, why would they expect yours to be?
3. Cynicism says that user input is secondary to business concerns
One statement I’ve heard frequently from users is basically: “I know you mean well, but our opinions don’t really matter. The management is going to buy/build whatever piece of software they get suckered into paying for. Our input isn’t going to matter.”
None of these problems are insurmountable, but we need to address each of them separately, and probably in a different blog post!