Understanding Customer Requirements
The High Impact of Understanding
A business analyst meets with customer stakeholders to collect requirements for a solution her company will develop. She transcribes the requirements into a template to ensure she gets every aspect of what they need. After the meeting, she reviews the requirements and finds some are incomplete. She completes them by assuming she knows what the customer wanted. The business analyst shares the requirements with a software architect. The architect asks her about the requirements. The business analyst only knows what she transcribed into the template and her assumptions about the incomplete requirements. She passes the architect’s questions to the customer stakeholders. As she’s unfamiliar with each person’s responsibilities, she sends some questions to the wrong people. Some stakeholders have additional follow-up questions with their answers. One stakeholder points out an incorrect assumption she made about an incomplete requirement.The business analyst returns to the architect with the stakeholder questions. He answers the questions and asks her what she thinks of his answers. She says she doesn’t have an opinion - she represents the customer. The architect replies her job goes far beyond that. A customer expects a business analyst to understand their requirements so s/he can advocate for those requirements during the development process. The architect encourages the business analyst to engage with the customer when capturing their requirements to understand what they mean. Had she done so in this case, she would have avoided incomplete requirements and inaccurate assumptions. The architect would have asked fewer questions, and she could answer most of those. She would return to the customer with fewer questions, knowing which stakeholder should get which question.
A Critical Junction in the Discovery Journey
Understanding what a customer needs forms the core of Discovery with a C.A.U.S.E.: Capture, Acknowledge, Understand, Show and Edit. Discovery reaches a critical junction when it comes to understanding customer needs. For example, the business analyst in the above story filled in an incomplete requirement with an incorrect assumption. Had the development team built the solution based on the incorrect assumption, the solution would disappoint the customer and could take substantial time, effort and money to correct. This often happens when software development projects fail.Understanding customer requirements is critical to discovery. A business analyst who captures all of the customer requirements and does not understand them sets the solution project on a trajectory to failure. When a business analyst understands the requirements, s/he sets the project on a course to success. S/he can even recover incomplete requirements.
A Model of Understanding
A person in a business analyst role first prepares for discovery. Then, s/he captures and acknowledges enough requirements to cover the solution scope. At that point, s/he should understand:
The customer’s terminology
Who and what the solution will deal with (people, places and things)
What the solution will do
Creating models helps a lot with understanding how a customer will use a solution. Models often start with a glossary, diagrams and eventually a proof of concept.
Developing the models helps the business analyst understand the customer needs better, possibly introducing new questions about the customer requirements. The business analyst ultimately uses the models to show the other stakeholders his or her understanding of their requirements. This could lead to discovery of new requirements, or improving the captured requirements. The business analyst edits the models based on stakeholder feedback.
Once the stakeholders and developers have a common understanding of the models, the development team has greater clarity of what the customer expects and to deliver on those expectations.
A solution's success depends on understanding customer requirements more than any other factor.