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 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 are the people, roles, or possible external entities, that engage in the system;
Use Cases being a description of the activities that take place in the system and;
Relationships that 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 basic documentation of a sensor-based application; and
To show how simple these diagrams are two quickly put together.
What does it 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 that I can 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"
So now you've see a sample use case diagram, let's get moving and understand how to start your first Use Case Diagram. Grab a whiteboard 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 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.
Move into the detail… 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 to in an algorithmic like language work through each case.
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 providing 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”.
Step 3: Plan to build
After many decades of use, Use Cases have become an integral part of the agile delivery of software. Under an agile delivery, the team focuses on a “build what we can and what is a 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 benefit 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, the next time you find you or a group struggling to describe an in-place system and its 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.
Comments