Alex looks at another issue with Use Cases and how they only add value when used in the right circumstances. This post was inspired by a discussion on the Model Driven Software Network.
One of the criticisms levelled at use case modelling as a technique is that it duplicates information that already exists in the textual specification. This can be true if you create use cases for their own sake.When performing any kind of systems or software modelling it is important to understand that the model should add value.
Use cases serve as a means to communicate from one person to another without any special training. Their purpose is to allow clarification and understanding of stakeholder needs by capturing the primary capabilities of a system.
In an age where customers are becoming more driven by filling capability gaps and less likely to provide detailed requirements, use cases are an extremely effective means of developing a requirement set where none exists.
Even where there is some form of contractual requirements document use cases can still be employed to validate those requirements. Never in the field of system development has there ever been a set of consistent, unambiguous and complete requirements delivered at the beginning of the project.
Use cases add value when:
- They allow developers to see what the system needs to do.
- They help to elicit system requirements.
- They help to validate the system context.
- They help to identify conflicting stakeholder needs.
Even though it might sometimes seem that developing use cases is a duplication of effort, experience shows that validating the requirements saves considerable time, effort, money and frustration later in the development lifecycle.
If we don't get the requirements right we may still build the system right but we have little chance of building the right system
