coneblog

And no systems analyst is there to hear it and document it, does it represent a valid requirement? Like trees falling in the forest, this might seem like a frivolous question, but it gets at some important Requirements issues.

One issue is the question of User Needs as a basis for Requirements. My experience is that users are not successful at voicing their needs and systems requirements. This should not be a surprise. Highly skilled teams of IT specialists can work round-the-clock for months and not deliver a coherent set of requirements.

Over time our understanding of what we can learn from Users has changed. We can’t expect in most cases to get useful requirements from Users.

Users see only one part of a larger picture – it is like they are standing in a small brightly lit room, and looking out a window onto a dark landscape. Their perception is dominated by what is bright and close, and they don’t have the context, or map, to connect to the larger system. But they do know about their Pain.

When I talk to users about their needs, I don’t listen for requirements, I listen for Pain.

Users don’t know about requirements. They lack the context and experience to construct good requirements. I’d add that they lack training, as well, but I’ve yet to meet an analyst that was competent thru formal training, rather than thru experience. Not to say that effective analyst training programs aren’t out there… But I digress.

What Users do know is their pain. They know what doesn’t go smoothly, what doesn’t work, what takes too much time, what causes errors. This is valuable input to the Analyst, because making pain go away is an important role of a system.

But not the only role. A users pain is one measure of friction and dysfunction in the organization, but it might mask a “reengineering” opportunity. That is, re think the painful process rather than automate it.

In addition, a users pain might indicate problems in other areas that translate into requirements there, and take a different form.

Or that classic example, where this group of users has to capture and enter data (pain for them) in order to make downstream processes work better (gain for the system).

The lesson here is not to take user needs as requirements. Consider them expressions of pain, and look for root causes, and evaluate the cost-benefit issues surrounding any group or user’s pain.

When the tree falls in the forest, it means a tree is down. Its meaning depends on who is listening, and for what.