Introduction
Using visual models when implementing Dynamics 365 helps to create a shared understanding of what are the key features of your solution. They can help you map out the requirements and how they relate to one another. In this article, I will focus on the Use Case Diagram, which is one of the diagrams I use on my Dynamics 365 implementation. Check out my previous article on an introduction to some of the other diagrams I use. “Model your Dynamics 365 Solution – Overview (Part 1)”.
When I start a new project, my team and I are often in one of two situations. Either the client has created a mountain of documentation on everything and anything (Word docs, emails, meeting notes, diagrams…) which as a consultant is impossible to tie-together, or there is nothing documented at all and all requirements are in the heads of the stakeholders.
In either case, as a consultant that needs to analyse the client’s requirements, the task ahead might seem daunting. In my experience, I’ve found that the best way to start, is with a Use Case diagram.
When I start a new project, my team and I are often in one of two situations. Either the client has created a mountain of documentation on everything and anything (Word docs, emails, meeting notes, diagrams…) which as a consultant is impossible to tie-together, or there is nothing documented at all and all requirements are in the heads of the stakeholders.
In either case, as a consultant that needs to analyse the client’s requirements, the task ahead might seem daunting. In my experience, I’ve found that the best way to start, is with a Use Case diagram.
Insider tip
Getting some context before starting your use case, can give you some very high- level guidelines. I have three questions I regularly kick-off with:
• What is the company’s business plan for the next 5 years?
• What are the issues they are trying to solve to help them achieve that plan?
• What are the key success factors for the system?
Knowing the answer to these questions can allow you to help the client to stay on the straight and narrow.
What is a Use Case Diagram?
A Use Case diagram is a graphical representation of the interactions between an actor and a system. To understand “what is the Use Case Diagram” it’s important to define each component of the Use Case Diagram:
- The Actor [Required]: An Actor is an object that has a role and performs an action in your Dynamics 365 system. It can be a person, organization or another system.
- The Use Case [Required]: A Use Case represents a function or an action done by an Actor within Dynamics 365.
- A System (or Sub-System) [Optional]: A system can be used to define the scope of the Use Case and drawn as a rectangle. This an optional element but useful when you’re visualizing large systems. For example, you can create all the Use Cases and then use the system object to define the scope covered by each sub-system. Or you can even use it to show the different areas covered in different releases.
Why and “when” using Use Cases
Use cases are a powerful technique to help visualize high-level requirements very quickly. I personally create a Use Case Diagram during my very first workshops or meetings together with key stakeholders of the current or future Dynamics 365 system.
Below the key benefits I get by creating a Use Case Diagram:
- It helps me quickly understand the big picture of the requirements. The more complex Actions will be elaborated using a Business Process Flow Diagram.
- By doing it together with my client, it is a good way to initiate communication and collaboration.
- The Actors will usually give an initial understanding of the Security Model within Dynamics. Be mindful that the Use Case Diagram will not tell you what an Actor can’t do in Dynamics 365 unless you add additional details to your Diagram.
- Sub-systems can highlight the Dynamics 365 Apps and Modules required by the overall Solution. As well as any of the other Microsoft related applications like SharePoint or Azure.
Steps to create the Use Case Diagram
- Identify the Actors:
- External parties like Clients, Suppliers or Partners
- Internal users being part of a team or role: Here typically we are going to identify some of the roles of our Dynamics 365 Solution.
- Dynamics 365: The automation done by Dynamics 365. Ex: Sending out an Auto response.
- Complete the Use Cases: For each of the actors, complete the Use Cases with enough level of details to give you a good understanding of what is required. I usually start with external parties like the Client or the Supplier. Ex: If we are implementing a Customer Service Solution for a School or University, I usually start with creating all the Use Cases about the Student touchpoints with our System.
- Identify the Use Cases that will require a Business Process Flow. Typically, if a Use Case includes more than 2 others Use Cases, then it probably requires a Business Process Flow Diagram. A Business Process Flow can also include multiple Actions from your Use Case Diagram. Ex: If we are going to create the Business Process Flow for a “Case Creation” this will typically involve Actions from both the Client and Customer Service Agent.
- Highlight the Sub-systems or other applications part of our Solution. Ex: If you have Use Cases that incorporate the usage of a Portal, you can draw a square around those Use Cases and indicate they are part of the Portal Sub-System.
Summary
Use case diagrams can be incredibly helpful at the start of the analysis. They help you and your client achieve a common understanding and determine together what you are going to focus on during analysis, and what your next steps are going to be. Since the effort is limited, following the four steps outlined above can ensure you use your time most efficiently and will prove to your client that you are capable of helping them define and then achieve the outcomes they are after.