Creating effective use cases to drive a better CRM for your business
Why should I care about creating a use case?
- Use cases describe how users use the CRM system and what the system does for those users. Use cases are a simple, but powerful technique for capturing and communicating requirements.
- Use cases provide a unique way to build consensus about what the system MUST DO! Building consensus is critical to a project’s success.
- Because use cases help create understanding, they naturally provide an excellent principle around which to structure project activities.
- Use cases play an important role for business analysts, who work with requirements of the system; developers who apply use cases to design and develop the system; testers who verify that the system delivers the value demanded by the stakeholders; technical writers who document the system use; and user-experience professionals who help make the system easy to use. All of these project team members must understand use cases in order to develop better solutions using the software.
What makes up an effective use Case?
A use case captures how the CRM system is required to behave under various conditions as it responds to a request from one of the stakeholders, called a primary actor.
The primary actor is the user sitting at the computer screen or other computer device. The primary actor initiates an interaction with the system to accomplish some goal. The system responds, hopefully in a way that supports the needs of all stakeholders. Different sequences of behavior, or scenarios, can unfold, depending on the requests made and the conditions surrounding the requests. The use case gathers those different scenarios together.
Use cases look different depending on when, where, for whom, and why you are writing them.
Use cases are fundamentally written in text form, although they can be illustrated using flow charts and sequence charts. Under normal circumstances, they serve as a means of communication from one person to another, often among people with no special training.
A well-written use case is easy to read. It consists of sentences written in only one grammatical form – a simple action step – in which the action achieves a result or passes information to another actor. Learning to read a use case should not take more than a few minutes.
Business analysts (BAs) are an asset to a business because they are trained and experienced at writing use cases for things like behavioral requirements, software systems, business processes in CRM for the desired behavior of the system(s), and the people involved.
Keep these three essential elements in mind in creating use cases:
- Primary actor - the system's user or a group of people interacting with the system. Who owns the goal/objective and will be using the system?
- System workflow - the process steps taken to reach the end goal, including necessary functional requirements and their anticipated behaviors. Does each step have an action defined?
- Goal - the final successful outcome that completes the process. How clear is it on the successful outcome?
Cautions to guard against to have a good use case:
- Too much user interface detail. Limit these details since the final solution and thus the interface may be changed to meet the objective of the use case.
- Too many use cases at low goal levels. The document should show well what the system will contribute to the lives of the end-user of the system.
- Using a use case for non-behavioral information. The use case is only good for describing behavior. Everything that the system must do should really go into a use case, but everything else should really go into some other format. Simply add an appendix to the use case document in the back. Other documentation to leave out: performance requirements, complex business rules, data structures, and product line descriptions.
- Making it too long. Each use case should include from 3 to 9 steps.
- Not completing the goal. Consider all the possible failure conditions or alternative behaviors.
- Writing in sentence fragments. Don’t omit the actor’s name in the action steps since it easily causes confusion.
Advantages of Use Cases:
Use cases give us a semi-formal framework for structuring the stories. The story has to have a purpose/objective – to yield measurable value to an individual actor of the system.
This semi-framework makes it relatively easy for the end-user of a system to read the document with very little training. It must be easily understandable.
Use cases describe the CRM system requirements for the error situations and work to have a working plan on their resolution.
The use case, as a form of writing, can stimulate discussion within a team about an upcoming CRM system. The team might or might not document the actual requirements with use cases. Another team might document the final design with use cases. All of the above might be done for a system as large as an entire company using multiple use cases or as small as a piece of a software application program. It is interesting that the same basic rules of writing apply to all these situations, even though the teams will write with different amounts of rigor and at different levels of technical detail.
Use case definitions:
- Actor: anyone or anything with behavior
- Stakeholder: someone or something with a vested interest in the behavior of the CRM system under discussion.
- Primary Actor: the stakeholder who or which initiates an interaction with the system under discussion to achieve a goal.
- Use case: a contract for the behavior of the system under discussion.
- Scope: identifying the system that we are discussing
- Preconditions and guarantees: what must be true before and after the use case runs
- Main success scenario: a case in which nothing goes wrong. The desired outcome. The desired ‘happy path’ is followed.
- Extensions: what can happen differently during that scenario. Numbers in the extensions refer to step numbers in the main success scenario at which each different situation is detected.
Requirements and use cases:
In writing use cases as CRM system requirements, keep these two points in mind:
- They really are requirements. You shouldn’t have to convert them into some other form of behavioral requirements. Properly written, they accurately detail what the system must do -- what job is to be done and in what way.
- They are not all the requirements. They don’t detail external interfaces, data formats, business rules, and complex formulas. They constitute only a fraction (less than half) of all the requirements you need to collect.
Is the Why Satisfied?
Ask yourself “What do you want this system to do?” As a business analyst, I will ask you to tell me a story about how you are going to use this system. What is the job that needs to be done? Use cases are simply stories about how people (or other things) use a system to perform some tasks.
Check out the business analysis and process management professional services available for your next CRM or to optimize your current CRM.