Business analysts make understanding requirements the primary goal of the discovery process. Understanding business needs starts with learning about the organization, its goals, and processes to establish context for a solution. Clear communication enables stakeholders to gain insight into the problems and opportunities they want the solution to manage. Then, business analysts use these insights to curate and understand requirements. Creating the following documents develops understanding of the customer's terms and solution needs.

Click a title to see excerpts

Understanding Customer Requirements (Key Story)

Understanding Customer Requirements excerpts:

• 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:
  • 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.

Purpose: Delivering Value

Purpose: Delivering Value excerpt:

• When you understand the value your customer delivers, you can appreciate how your efforts contribute to that value. Developing a solution always uncovers problems, often expressed as risks. Keep in mind that risk has three parts: how likely it will occur, a downside and an upside. Risk analysis focuses on the first two parts - the impact of the downside and how likely it will occur. The upside fulfills the Purpose of the solution, delivering value to the customer. Recognizing your part in delivering value to the customer will sustain your motivation to work through the inevitable problems.

Your First Deliverable: Curiosity

Your First Deliverable: Curiosity excerpt:

• The meeting starts well, with Emily asking detailed questions about the prospect's product development process. This astonishes the pilot team, who did not expect Emily to take so much interest in how they work. They expected Emily to show off her technical knowledge and challenge their integration approach. Instead, the team appreciates Emily's questions - they indicate that she understands their project and its challenges. Emily's questions show her technical competence far more than her reciting what she knows. Everyone left the meeting excited and looking forward to working together.

Discovery with a C.A.U.S.E.

Discovery with a C.A.U.S.E. excerpts:

• Once you have captured and acknowledged the client's needs, you review them after the workshop to understand them. You note any questions or doubts about a need and follow up with the client for answers. You create a document outlining each department's needs, adding one section for common needs and another for conflicting needs. You create diagrams showing the flow of each process the clients outlined, supported with more detailed diagrams of complex processes. You make a list of all your assumptions about their needs.
• After you complete the documentation, you schedule a series of shorter sessions to show your understanding of each department's needs. You review the department's needs, along with the common needs. You go through the process flow diagrams to make sure they clearly cover each process. You check each assumption you made in understanding the client's needs. They point out where they have resolved some data access conflicts. You note those and all variances between your understanding and the client's feedback. You capture and acknowledge new needs that emerge from this process.
• When you complete the follow-up sessions, you edit your documents with changes. You make sure you understand any needs captured in the follow-up sessions. You show these changes in a final summit meeting that includes the client CEO and the departmental managers. They are impressed with how clearly and completely you captured their needs. The CEO likes how you show the data access conflicts between departments, commenting that you made her job a lot easier. She says she’s excited to work with you in the future. You share how much you respect and appreciate her leadership.
• The success of the client's Salesforce implementation hinges on capturing their business needs thoroughly and clearly. You acknowledge the needs as you capture them as the first level of confirmation that you have their needs. You review all that you've captured to develop understanding and insight into what the client needs from Salesforce. You create documents reflecting what you've learned and use them to show your understanding as a second level of confirmation. You edit the documents based on feedback from the client that varies from your initial understanding. You're discovering customer needs with C.A.U.S.E.: capture, acknowledge, understand, show, edit.

Discovering Quality

Discovering Quality excerpt:

• The IT Director agrees. What will encourage the sales team to use Sales Cloud? It started when you observed the client’s sales rep and admin using their current system. Since you understand what matters most in their sales processes, you will have Sales Cloud customized to exceed their expectations. For example, sales reps often forget to enter notes when they are at the office. Sales Cloud will enable them to dictate the notes into their phone. It will provide help for new users, while enabling experienced users to efficiently work anywhere.

Dealing with Stakeholder Conflict

Dealing with Stakeholder Conflict excerpt:

• A Global Customer Service Summit
  • You inform the managers they can have a multilingual knowledge base with Salesforce Service Cloud. The Europe and the Americas managers like the idea and ask the Asia, Middle East, and Africa managers if they would like to join them in adopting a global knowledge base. Each manager politely declines. They want to continue providing customer service with the mobile apps. You ask to see the app to understand the benefits it provides. The Asia manager gives a brief

Continuous Improvement of Discovery

Continuous Improvement of Discovery excerpts:

• Understanding Ticket Request Needs
  • I started understanding the ticket request process by dividing it into high-level steps: Putting the steps in a process map showed the ticketing manager my understanding in a clear, visual way. Each box depicts a step, connected by arrows labeled with the motivation for each step.
• Showing Understanding and Getting Additional Information
  • While the process map demonstrated my understanding of ticket request needs so far, I had questions for the ticketing manager
  • Agile software development arose from the need for software to adapt to rapidly changing customer requirements. It begins most effectively with continuous improvement of discovery, capturing new requirements as they emerge from the customer. Continuous improvement of discovery demonstrates understanding of what the customer needs, so that development can quickly fulfill urgent needs. Customers remain happy with their solution as it keeps meeting their needs through continuous improvement of discovery.

Empathy for the Customer

Empathy for the Customer excerpts:

• Lessons Learned
  • The purposeful architect had enough when the product manager asked her to capture her own use cases. She had already taken the initiative for him to ask what she needed. She had to take the lead again, asking him to record their conversation instead of struggling with a template. If she provided him with her needs in writing, what initiative would he take to understand them?
• Assuming the perspective of customer stakeholders through discovery results in a better understanding of their mindset and needs, leading to a more beneficial solution.

Developing Firm Skills

Developing Firm Skills excerpts:

• There Must Be a Better Way
  • The Purposeful Architects representative meets with the team, summarizing what she understands about their requirements so far and asking follow-up questions. She uses the organization’s terminology to minimize misunderstandings. She then demonstrates a donation campaign management proof of concept built on the Salesforce platform. It includes a form where donors can register themselves for a fundraiser.
  • A team member whispers to the manager how Purposeful Architects seems too good to be true. The manager acknowledges the comment and turns to the representative. She asks the representative about tracking sophisticated metrics, such as a donor’s capacity and inclination to increase donations. The representative asks how they would get the data for the metrics while clarifying the terms. The manager answers her questions as much as she can. The representative offers some approaches while stressing the need to fill gaps in understanding. The team expresses their appreciation for Purposeful Architects’ preparation, attention, and demonstration of what they offer.
• Develop firm skills by combining empathy and understanding of a customer’s business needs with technical aptitude. Firm skills enhance understanding of the customer’s needs and showing solution models that meet their needs.

Coming to Terms

Coming to Terms excerpts:

• The Path to Understanding
  • Business analysts and architects learn a new vocabulary on a discovery journey - the customer’s terminology within the scope of a solution. All stakeholders on the journey need a common set of terms to understand each other. Agreeing to these common terms streamlines discovery of what the customer needs from a solution.
  • Discovery with a C.A.U.S.E. introduces five aspects of the discovery journey - capture and acknowledge customer needs, understand their needs, show this understanding to customer stakeholders and edit understanding based on customer feedback. A business analyst should capture customer terminology along with their needs during discovery. The graphic below shows how C.A.U.S.E. applies to discovering the customer’s terminology.
• Clearing the Path to Success
  • A customer terminology glossary helps the development team understand what the customer means through discovery. If customer stakeholders have different interpretations of a term, they should reconcile those differences before using the term in discovery. The glossary owner will capture and acknowledge the reconciled definition in the glossary, providing a common understanding of the term. The glossary lays the groundwork for clear communication and understanding of customer needs.

Showing Customer Concepts

Showing Customer Concepts excerpts:

• Relating the Customer Terms
  • Once a purposeful architect has compiled a glossary of customer terms in discovery, how can s/he show his or her understanding of the terms? Reviewing the glossary term by term will turn a discovery meeting into an executive snoozefest, losing the attention of most stakeholders. Besides, there’s more to customer terms than their definitions.
• Showing Concepts and Their Relationships
  • Once a purposeful architect understands customer concepts and their relationships, how does s/he show that understanding to the other stakeholders? S/he creates a diagram representing concepts as shapes connected by lines showing their relationships with each other. This diagram is called a concept map.
• Concept Map Considerations
  • A concept map works hand in hand with a glossary which defines each concept in the map. The glossary serves a reference for understanding. The concept map illustrates understanding. For example, a new stakeholder reviews the concept map and asks what a concept means. S/he finds the definition of the concept in the glossary.
  • A purposeful architect presents a concept map only to reflect his/her understanding of customer concepts and their relationships. Customer stakeholders have an opportunity to clarify, correct or complete that understanding when reviewing the map. A common understanding of concepts and relationships among all stakeholders clarifies their communications. It can prevent misunderstandings that result in a solution not meeting customer expectations.
• Diagramming customer concepts brings all stakeholders to a common understanding of the people, places and things a customer manages in the scope of a solution.

Mapping Out Complexity

Mapping Out Complexity excerpts:

• Breaking Down Complexity
  • When discovering customer needs for a solution, complex processes can emerge. Breaking complex processes down into simpler steps has these benefits:
  • A process is easier to review and understand as a sequence of steps.
  • Filling gaps between the steps makes understanding the process more complete.
• A process map shows stakeholders a visual layout of complex process steps, so they can understand and review the process efficiently.

What's the Story?

What's the Story? excerpt:

• What’s the Story For?
  • Complete, well-written user stories provide a rich context for designers and developers to understand what a customer does in the scope of the solution. A business analyst rarely reviews a user story itself with customer stakeholders. By the time s/he writes user stories, s/he has shown his/her understanding of the customer requirements.

Requirements on the Record

Requirements on the Record excerpts:

• Requirements, Party of One
  • If I started a software company by myself today, I would put requirements, user stories, process maps, and use cases into documents or a knowledge base. Doing so would give me a clearer understanding of those details in writing than in my memory. That alone makes the effort worthwhile, even at the smallest possible scale - one person.
• Requirements for All Stakeholders
  • The article Motivating Specific Requirements discusses capturing what a customer needs in enough detail to develop a valuable software solution. Once a business analyst or architect has the requirement details, s/he should document and organize them to clarify his/her understanding. The requirements details should have enough clarity to enable all stakeholders to achieve a similar level of understanding. These details come in six categories:
• An Important “How” Question
  • Once the stakeholders have answered the “why, who, what and when” questions in sufficient detail, an important “how” question emerges. How does one record and organize the answers to facilitate understanding of the requirements by all stakeholders?
• Requirements for Recording Requirements
  • A drawing tool enables a business analyst or architect to illustrate processes and concepts to other stakeholders. Process and concept maps accelerate understanding of the requirements for all stakeholders through visualization of relationships.

Understanding Customer Requirements Summary Map

Understanding Customer Requirements Summary Map excerpt:

• Documenting customer terms, concepts, processes, user stories, and use cases clarifies understanding of what the customer needs for a solution. Stakeholders review concept and process maps. Use cases, user stories and the glossary provide answers for specific questions. This collaboration keeps the intended solution close to customer expectations.

Discovering Your Client

Discovering Your Client excerpts:

• Good Questions
  • Why should business analysts or architects concern themselves with the client’s vision or mission statement, business practices, and processes? They connect the business analyst to the client’s values. With a thorough understanding of what a client values and how they create value, a business analyst has a clearer view of what the client needs and how to fill those needs.
• Business Analyst or Architect? Both!
  • After Stuart Edeal posted his business questions in the Salesforce Business Analyst community, he thought about them and wanted to make them more complete. He published BAs & CTAs – How to Begin?, where he starts with a key point from the Business Analysis Body of Knowledge (BABOK). A business analyst is a change agent, leading stakeholders through a process that changes the client’s business. This process starts with strategy analysis, which Stuart covers in detail in the article. A business analyst expecting “just” to gather requirements and deliver what the stakeholders ask for would find strategy analysis daunting. A business analyst with a thorough understanding of their client’s business and the value they deliver would welcome the change agent role.
  • A Salesforce architect is a change agent whether s/he is a CTA getting requirements from a team of business analysts or the client’s CEO. S/he thoroughly understands the client’s business, like a building architect understands their client’s property and their needs.
• Deepening Client Understanding
  • Stuart includes topics in Future State to determine what a client needs from a solution. Future State does not specify the solution or how it works. That comes later, after developing a thorough understanding of the client and what they need.
  • Getting accurate answers to these questions starts the business analyst or architect on the path to understanding their client and their needs. Once the business analyst or architect has confirmed that understanding with the client, they can take on the change agent role to meet the client’s needs to make their business more valuable.
• The best business analysts and architects dedicate themselves to understand their clients’ business, more than showing how much they know about their solutions.