Understanding the goal

When gathering requirements, one of the most important things to understand is the answer to the question, "Why?"

The answer to this simple question will provide clarity and guidance to your requirements gathering efforts. This is because you will be able to evaluate whether the requirements you are gathering will solve your problem (or capitalize on the opportunity.) Thus, a business analyst should always seek to understand the underlying business objective.

Suppose a client receives five sets of different reports. The client is concerned because it takes him a long time to get the necessary reporting. His request is for his five reports to run faster so he can perform his analytics. The business analyst (doesn't probe any deeper and) works with the IT developers to optimize the SQL used in the reports, create database views to reduce the number of multiple-table queries and revamps the reports so they are more efficient. Finally, the business analyst presents five optimized reports. The client promptly looks at each report, takes two pieces of information from each and then creates a dashboard sales report for one of his customers.

If the business analyst knew that the goal was to prepare a dashboard sales report, could a more optimal outcome have been achieved?

Here are a few comments about what happened:

1. The requirements were not design-independent. It was pretty much determined to rework the existing reports and make them more efficient.
2. Ultimately, a useful result was obtained however, it may not have been the most optimal one. The business analyst also ran the risk of not achieving the goal at all because the business analyst did not probe deeply enough to uncover the underlying objective.

If the business analyst had used active-listening techniques and probed the client, both of these issues could have been avoided.