Experiment 2 – Business Requirements

Business Requirements

Many years ago I was a Business Analyst. I’m not anymore but I still remember the role and how difficult the job can be. I still remember how frustratingly difficult it can be to write good business requirements. I remember how you could spend significant amounts of effort writing those requirements, think them “bullet proof” only to have people shred them (not always for the right reasons). It is frustratingly difficult to write about business level gaps and not barge in to solution description. In my role as a tester I read the business requirements and, more often than I would like, wonder what problem the client is really having, what are we trying to solve. Sometimes I even wonder why the business requirements make relatively simple changes seem complex. This is not a statement about the quality of Business Analysts, we have some very capable, smart people in these roles, it is a statement about the difficulty of the task.

When you commute to work you have a bit of thinking time on your hands. Now I’m not sure if I read something recently or a bunch of recent events just crystallised in my mind, but either way I started thinking about business requirements. Now I should state here that I’m really talking about business requirements in the contexts I have worked. Others may not identify with the following and may feel that business requirements are AOK.

Business requirements are an abstraction of a problem. Business requirements are a statement that:

• a business has a problem that needs to be solved
• are solution agnostic.

Business requirements tell us that there is a problem but not specifically what the problem is. Now that may sound strange but the language of business requirements moves the writer away from directly expressing the issue. “The system shall……” nobody has ever verbally stated a business requirement that way since the ark was constructed (and possibly not even then). So we are using, what I think of, as an artificial rather than a natural language. Why? Because we need to make sure that the requirements are specific, not ambiguous, etc, etc. Don’t forget that the books and courses also tell us this is the way to capture them. Does it work? Not well enough I’d say. Client discussions around what a requirement meant, post delivery, are not that uncommon.

So let’s get back to the discussion and gathering process. The client tells us they have a problem, they may not understand exactly what the problem is, especially the full depth of it. The Business Analyst is taking notes, asking questions, forming impressions. Eventually these impressions make it to the specification document. Ever play the game Chinese whispers? You whisper a phrase and pass it down the line of people. By the time it gets to the end of the line it is not the initial message. Business requirements gathering is that game. The BA is documenting their impressions of someones impressions of a problem and then abstracting that to a specific language style. Yep things get a bit iffy.

We gather business requirements while discussing the client problems. As a business analyst am I focused on understanding the problems being described or abstracting these to business requirements? Given that the business requirements are a deliverable of the exercise I’m fairly sure they get in the way of really understanding the problem. I think human nature is to focus on the thing you are directly accountable for, even if that may not be in the best interests of client happiness. Business Analysts I have discussed this with tend to support the theory.

A further complication, a potential proliferation of business requirements. If you can read, understand, and, hold in your head 50 (100, 200, or more) business requirements, you might, just might, get an inkling of the client problem. Most likely not because that kind of human memory allocation lies beyond normal limits (and it’s impacted by the other issues I’ve noted).

I’m proposing an experiment where I work. Let’s try not abstracting away from the business problem. Let’s try actually capturing the problems and describing those in direct terms, natural language if you like. Let’s demonstrate to the client that we actually do understand the problems to be fixed. Let’s work closely with the client. Let’s see if we can move away from the post delivery “but we thought the requirement meant……..” syndrome. When we engage with clients we do so to deliver a meaningful solution to a real problem. Let’s get clients to talk to us about the problems they need solved, no branching in to possible solutions, just the problems (I’ve done this with a client, it works. They do you give you a strange look when you tell them no solution discussion). What does the problem look like using real world data, how does it manifest, how does it impact? Of all those problems which are the ones that need priority attention? When we really understand what needs to be solved we can construct holistic, high quality solutions that really do delight clients. When we get this level of understanding we are not guessing using abstract requirements statements we are working with descriptions of real problems and we are talking to clients about those problems using language we both understand.

Will the problem statements work better than business requirements? I don’t know (I think they will but I have no detailed history of success in this context). I’d like to think they will as they should focus directly on how we can deliver value. Will our clients accept this a change of practice? I don’t know. If we can experiment and show value I think they will but no guarantees. Sometimes lack of change seems to keep people happy, even if it is not a great practice. I can’t tell our clients what value is, I can try to help them understand that a particular practice could be beneficial but I can’t force that on them.

I’m really interested in any thoughts people may have on this approach or past experiences.

Advertisement