This week, let’s continue with another type of Stakeholder requirement – Use Case diagram. In previous posts, Use Case diagram is introduced as to depict which actor can perform which actions (or so-call use cases) and the relationships between those actions. According to UML standard notion of Use Case diagram, the best way to think of a it is that it’s a graphical table of contents for the use case set. Hence, it depicts the scope of the solution, with all actors, functions and their relationships reflected.
Use Case diagram belongs to Activity Flow modelling category, and is drawn using Use Case and Scenario technique. However, as Scenario – a sequence of steps describing an interaction between a user and a system – is a bit too detailed, it’s described in Functional Requirement. Only the diagram is kept in Stakeholder Requirement. Nevertheless, it’s recommended by many experts that the focus should be on Use Case content textual, not the diagram. The reason is because the diagram is sometimes useful, most of the time it does not contribute much to stakeholder, and even mislead them due to its complexity. On the other hand, the Use Case diagram is optional, and it should be kept as much simple as possible.
Let’s start with one example of Use Case diagram:
(Martin Fowler. 2003. UML Distilled. [Image])
Clearly, below elements can be found easily in the diagram:
- Actor: actor can be user or non-user. The concept of Actor is explained once in my previous post of Permission Matrix, thus, will not be described here. Each actor is represented by a “human” image as the image above, so don’t be misled as if it mentions to users only.
- System boundary: is represented by a rectangle. This system boundary includes functionalities inside, but all the actors will be excluded.
- Use Case: each use case is represented by an eclipse within the system boundary. The naming convention should be V + O (verb following by an object name) – e.g. Set Limits in the image above.
- Relationship: there are 3 types of relationship:
- Relationship between Actor and Use Case – or Association: it’s represented by a solid line and indicates that the Actor has access to the corresponding functionality represented by the Use Case. It does not represent input, output, time or dependency. This association is mandatory in the diagram.
- Relationship between Actor and Actor: it’s also known as Actor Inheritance. If an Actor (supposed Actor 1) is inherited from the other Actor (Actor 2 for example), Actor 1 can access every functionality that Actor 2 can. This relationship is represented by an arrow with the starting point at Actor 1 and the end point at Actor 2. This relationship is optional.
- Relationship between Use Case and Use Case: there are 2 commonly used relationships between Use Cases:
- Include: allows for the use case to make use of functionality present in another use case. A complicated step in a use case can be another use case. In UML terms, we say that the first use case includes the second. The included use case does not need to be a complete use case in its own right if it is not directly triggered by an actor. This relationship is most often used either when some shared functionality is required by several use cases or to abstract out a complex piece of logic.
- Extend: allows for the insertion of additional behavior into a use case. The use case that is being extended must be completely functional in its own right and must not depend on the extending use case for its successful execution. This relationship may be used to show that an alternate flow has been added to an existing use case (representing new requirements). Example for this relationship might be Approve and Reject function – the main objective is always “Approve”, thus, “Reject” can be considered as extended Use Case.
Similarly, these relationships are also denoted as dashed line arrows with the “Include” or “Extend” text at the mids. They are also optional in the diagram.
Thanks for reading 🙂
- IIBA. 2015. BABOK. Version 3.0.
- Martin Fowler. 2003. UML Distilled. 3rd ed.