I’ve made no secret over my years of consulting that Use Case Modelling is an effective tool for capturing requirements. For those that have worked with me you’ve probably seen me sell and use this tool, but for other for here’s my 101 on why I find this tool so useful.
What does it look like?
Use Cases utilise three basic graphic elements in describing an ‘as-is’ or ‘to-be’ “system”:
- Actors: people, roles, or possible external entities that engage in the system,
- Use Cases: a description of the activities that take place in the system,
- Relationships: describe the interactions between the Use Cases and the actors.
I have selected the above Use Case diagram for two reasons:
- To (in an effort) demonstrate the three elements working together to describe a basic documentation of a sensor-based application; and
- To show how simple these diagrams are to quickly put together.
What does use case modelling offer?
Too often consultants try to be too clever for their own good, using “over the top” diagramming which does nothing except look pretty (potentially). Normally these tools, while of value to the consultant, ultimately confuse the users they are trying to impress and thus completely miss the point and target audience. With Use Case diagrams such as the above, it should be relatively easy to visualise working this through on a whiteboard by anyone with even childlike drawing skills (myself being a case in point).
Use Case Modelling is fast and interactive and with a very basic set of concepts to learn. A team of people with no experience can get to the job of describing what it is they are trying to describe and/or how they see the future. I find that within the time that it will take to read this blog, I could be getting to the job of diagramming with an enthusiastic group. In fact, the rules around Use Case Modelling are flexible to really allow the facilitator to describe the use cases as they see best.
Step 1: Capture the high level "picture"
Now that you’ve seen a sample use case diagram, let’s get moving and understand how to start your first Use Case Diagram. Grab a white board and a marker and start to draw up the first Actors and Activities that come to mind.
Establishing an agreed language is a key project success factor in my experience, so it is important to allow discussion to get the “language” correct and agreed to by all stakeholders. This will be carried into future modelling activities. However, while focusing on getting the language correct, it is also important to not “labour” unnecessarily.
Use Case Modelling is iterative, so if you find yourself getting stuck, accept the problem, document it and note to come back. This is where a facilitator provides skill in keeping the process moving.
Go into details – prioritised and to an appropriate level.
Step 2: Work down into the detail
Once the high level has been provided, the Use Case methodology then provides the framework to delve deeper into documenting the system. Case-by-case, you can start to work through “so what does configure sensors” involve? Whether each case is broken off for an individual or smaller team to work through or the entire group workshops together, a facilitator can start working through each case in an algorithmic-like language.
Generally, and advisably, this process of adding detail is iterative and fast with each review providing an opportunity to fill in detail. An experienced facilitator and coach will be able to provide the best method of arriving at detail, but generally, it is best to provide a basic flow (“happy path”) before defining exceptions (“alternate paths”), e.g. Let’s assume that the sensor is always collaborated and working before starting to deal with “but what if the sensor is broken”.
|Use case||Register patients||Parent use case|
|Description||The system must provide the facility to register a patient who has arrived.|
|Pre-Condition||A set of unique identifiers must be available
Sufficient information about the patient must be available
|Post-Condition||Patients will be registered
A unique patient identifier will be associated with the patient record
|Use Case (Basic Flow)||Patient Arrives
Provides details required
Registration is complete
Unique ID is generated
|A patient’s record alone may arrive for consultation from an external hospital||The nurse must be able to register such patients as external patients and store their information|
|Business Rules and Validation||A check must be done if the patient’s record exists in the system prior to registering a patient
Date of birth cannot be a future date
|Objects||Patient, Carer, Relationships|
Step 3: Plan to build
After many decades of use, Use Cases have become an integral part of agile delivery of software. Under an agile delivery, the team focuses on a “build what we can and what is priority as quickly as possible” vs “release once everything is 100% complete”. Whether agile is right for your business is outside of the discussion here, but the concept of “build what is priority” means you can, as a group, define those use cases that provide the biggest benefit, flesh out the detail and build those pieces to get business benefits as quickly as possible.
Step 4: Start today
Like most skills, the best way to test it is to use it. Even if you’re not planning to build a system, next time you or a group is struggling to describe an in-place system and it’s interactions, Use Case modelling may just provide the best tool to book a room, grab a whiteboard marker and start defining a common visual model.