Top 10 mistakes in Use Case Modelling
Use case modelling is the most powerful requirements modelling technique to model solution requirements if applied correctly. I have come across many BA teams (including my own) that made lot of common mistakes in use case modelling. By avoiding the top 10 mistakes identified in this paper, BA teams can not only save lot of efforts in use case modelling but also significantly enhance the value delivered and improve the satisfaction of stakeholders.
1. Naming the actors using the job titles
Job titles and actor names are two different things and often cause confusion. This is because two different users, with different job titles and organisational responsibilities, may have to use the system as a same actor; for example, a supervisor can have access to and use the functionality used by his/her subordinate. Actor is a role that is with respect to the system as opposed to a job title which a role with respect to the organisation. Job titles may typically determine user types. Remember, job titles of people may change but the roles they play would remain relatively stable.
2. Creating only the use case diagrams
Use case diagrams only provides summary of the relationship between the actors and the use cases. Can we tell what a system does basis only the use case diagram? No; a system cannot be built just based on the use case diagrams. We need detailed use case descriptions to design and build the system.
3. Not capturing enough details
Too much detail can obscure the flow of the use case and too less can make it really meaningless. “How detailed a use case should be?” In as much detail as possible and in as much detail that is required to make them unambiguous to describe what the system must do. Focus on what is important and continue to add details till all the stakeholders are satisfied.
4. Describing everything a system does in a use case
It is important to identify all the use cases and describe them so that everyone understands who uses the system and what goals they achieve by using it. This is particularly important when the user-system interaction is complex and detailing the system behaviour is essential to develop and test the system. However, if we blindly do this for all the use cases than we are just increasing the documentation and subsequent time required for reviews and sign-off, without delivering any additional value to the project and its stakeholders. So, for cases where the user-system interaction is simple, use cases are not required to be fully described. In such cases, a simple use case description supplemented with declarative requirements and other models may be sufficient to understand what needs to be done.
5. Performing functional decomposition
BA teams typically tend to group functional requirements, or break them in form of functions or menu-items and identify them as use cases. What they don’t understand is, high-level use cases cannot be decomposed into lower-level use cases and also use cases cannot call, communicate, get linked or sequenced with other use cases. This approach is most common of all mistakes made while identifying and describing use cases. Let us try to understand this with an example.
What use cases will you identify for a system say, a car? The adjoining diagram shows the use cases identified using this approach.
Here, all the necessary functions (menu-items!) are available to a ‘Car Driver’ (actor) to drive a ‘Car’. With this approach, are we answering what the ‘Car Driver’ will do to drive (actual goal) the ‘Car’? None of the use case actually describes the way ‘Car Driver’ will interact with (or use) the ‘Car’ to drive it without linking or sequencing them.
The system appears as a large set of disconnected functions. To identify the right use cases, always keep in mind the goal that the actor wants to achieve by using the system. Each use case must be complete to provide value to at least one of its actors.
6. Writing perfect use cases
There is no such thing as perfect use cases. Many BA teams waste their efforts in trying to create perfect use cases. The focus should be on making use cases as good as required for facilitating communication amongst stakeholders to achieve shared understanding of requirements and moving to system design, development and testing.
7. Detailing use cases with the CRUD behaviour
Although it is not technically wrong but detailing uses cases with CRUD (create, retrieve, update, delete) behaviour, for example maintaining information for administrative systems, is a waste as it is mere repetition of declarative form of requirements specifications. Use cases with the CRUD behaviour don’t add much value to ensure that the system is doing right, particularly when information can be added in any sequence without any dependency. Except for data validation rules and specific fields to be entered, the use cases with the CRUD behaviour become repetitive. These efforts can be used for detailing use cases with real flow of events.
8. Using the use case model to design the system
Many times, BA teams also document how a system should handle certain functionality internally as part of use case descriptions. By specifying such functionality we are imposing constraints on the development team to design the system in a specific way. Many would argue that “it is a BA’s job to think for all scenarios and provide a solution” but we forget that the real purpose of a use case is to describe what system does to fulfil the goals of the actor and by mentioning constraints inside a use case we are just making this behaviour difficult to understand. So, anything that must be handled in a certain way should only be described in the use cases and all other things should be left out for the developers to decide. Constraints can be captured in other specifications and traced back to the use cases so that they are not forgotten during the system design. Use case model must never be used to design the system. Use cases describe what the stakeholders want the system to do and not how the system implements the functionality.
9. Describing things outside scope of system
Use case model captures the interactions of actors and the system and describes what the system does to fulfil actor goals. Outside system boundary a stakeholder (identified as an actor) may interact with another stakeholder (who may be identified as another actor); to support the business process. If this interaction (business process) is not supported by the system, it should not be captured in the use case model. Use cases can be used to capture business processes as “business use cases” with actors outside the business boundary. Never mix systems use cases and business use cases.
10. Misusing the use case relationships
BA teams also spend lot of time structuring the use case model, with use case relationships such as include, extend and generalization, assuming that such structure is required in every use case model or required for the system’s architecture. BA teams typically use include relationship to break a use case into smaller use cases by performing functional decomposition of the system. The result is that none of the use cases by themselves provide any real value as it becomes very hard to see what a system does. Using use case relationships without understanding their real purpose just results into a confusing use case model.
[This article was published on Modern Analyst by Trividh Patel, CBAP on Jan 10, 2016]