RULE 1: Use Cases Aren’t Silver Bullets
There are a couple of popular misconceptions around use cases:
Misconception 1: The use cases are the requirements of the system
Contrary to what many engineers believe (and many authors have written) the complete set of use cases do NOT constitute its full set of requirements for the system.
A use case model is an analysis tool. They are a mechanism for organising the functional behaviour of the system and reflecting it back to the stakeholders. This is sometimes referred to as ‘Problem Reframing’. By re-framing the requirements to are aiming to achieve three things:
- Demonstrate you have understood the problem, as the customer perceives it.
- Capture information exchange and sequencing requirements.
- Identify any missing behaviours
In order to achieve this effectively you need to generalise and abstract the customer requirements into something more manageable. Thus the use cases ‘reflect’ the system requirements without actually being the system requirements.
In embedded systems design the functional behaviour is but a small part of the requirements of the system. System developers must comply with a vast number of other requirements, including performance, reliability, security, environmental, useability, etc. Many of these are system qualities – that is, they apply to the system as a whole, not just the software. Use Cases are simply not an effective tool for capturing this information, despite attempts by several authors to incorporate them.
Misconception 2: You must always build a use case model
Engineering problems can be classified into four basic categories:
In a data-oriented problem it is the information, and its relationship to other information, that is important.
Modal problems are characterised by having separate, distinct behaviours at different times. Trigger events from the environment will cause the system to change its behaviour.
Transactional problems tend to be event-driven: A behaviour is (externally) invoked, which either produces a result or a change in the environment.
Problems tend to be control-oriented: data/materiel moves from ‘sources’ to ‘sinks’. Algorithms and rules control how the information is moved and transformed.
While it’s perfectly correct to say that almost all systems have all these elements to some extent, in most cases one of the categories tends to dominate the requirements of the system.
Use cases are most effective when used to describe Transactional problems. Using Use Case analysis on other types of system often yields less-useful information about the system. In some cases Use Cases actually obfuscate the problem by attempting to re-frame one type of problem into a Transactional problem. For example, attempting to describe a flow-of-materials problem with use cases tends to yield trivial Use Cases and obscures the fundamental nature of the problem by trying to re-frame ‘flows’ as descrete ‘events’.
Use cases are a very powerful analysis tool – when used in the right way and under the right circumstances. But they aren’t a silver bullet. Use cases don’t solve every requirements analysis problem and they don’t necessarily suit every type of problem.
In order to use Use Cases effectively you must understand what type of problem you are trying to solve and whether use cases are the right tool for the job.