In previous posts, we are familiar with Stakeholder requirements, including some common diagrams such as Entity Relationship diagram, Workflow, State Transition diagram, Use Case diagram and Sitemap. This week, let’s cater for Functional Requirement.
Depending on the requirement approach (predictive or adaptive), Functional requirement can be written in different ways. Normally, if the project uses Waterfall methodology, the requirement approach chosen is mostly predictive. In this case, Functional requirement will be split into Use Cases. On the other hand, if the project uses Agile methodology, the adaptive requirement approach is normally selected. In this case, Functional requirement comprises of many User Stories.
In this post, we will only focus on Use Case.
The first question arises: what is the relationship between Use Case and Use Case diagram which is previously described in Stakeholder requirement?
According to IIBA in BABOK ver 3, Use Case diagram is a part of Use Case, while they are quite separate in UML Distilled of Martin Fowler. From my point of view, Use Case diagram is really a part of all Use Cases as a whole, but certainly cannot be a part of any Use Case on its own. Use Case diagram depicts list of all Use Cases of a solution – just like table of content of a book. Hence, normally I put Use Case diagram under Stakeholder requirement section – but even when we put it under Functional requirement, it’s still good.
Rather than concerning about Use Case diagram, let’s focus on Use Case description. According to IIBA in BABOK ver 3, each Use Case includes below components:
- Name: name of a Use Case should follow naming convention of Verb + Object e.g. Create Request. It must be exactly the same as UC name in UC diagram or Permission Matrix under Stakeholder requirement.
- Goal: the objective of a Use Case must be described clearly and accurately here, so that reader have the context of why this UC is needed and how to verify if the UC design meets the need. For this description, I would recommend using user-friendly wording style instead of technical writing as most part of the document.
- Actors: list of actors who can cary out a UC must be listed under this part. The actor name must be exactly the same as actor of Stakeholder requirement. There are 2 kinds of actor: primary actor who starts UC and secondary actor who participates in the UC as supporting role.
- Preconditions: list of constraints for the UC to be able to be started must be listed here. If the pre-condition is not satisfied, UC can’t be started. Some UCs have Precondition while the others might not have.
- Trigger: is an event which initiates the flow of events for a UC. It can be an action taken by an actor, or a temporal event such as time (in case of Scheduled Job).
- Flow of Events: The flow of events is the set of steps performed by the actor and the solution during the execution of the use case. Most use case descriptions separate out a basic, primary, or main success flow that represents the shortest or simplest successful path that accomplishes the goal of the actor. Use cases may also include alternative and exception flows – they are known as Extension in UML language. Alternative flows describe other paths that may be followed to allow the actor to successfully achieve the goal of the use case. Exception flows describe the desired response by the solution when the goal is unachievable and the use case cannot be successfully completed.
If there are not too many alternative flows and exception flows, I would recommend drawing this flow of events using Activity Flow modelling technique. A picture worths thousand words, as always. Otherwise, we can use a table with 2 columns for Actor & System with each row corresponding to an action/event. With this approach, the flow is not visualised thus maybe difficult for reader to imagine. However, it will save much effort in case of revision. In case a UC includes another UC, this approach shows its significant advantage when linking them quite easy.
I will come back to this Flow of Events in the next post to entails both approaches.
- Post-condition or Guarantee: A post-condition is any fact that must be true when the use case is complete.
In some documents, Business Rules are also added to a UC description. However, Business Rules are not a part of UC content. We have a lot of ways to manage Business Rules: we can manage them in a separate document, or in the same document but treated as appendices, or just under each UC. There must be a reference to each Business Rule in action/steps calling them. We can get to know them better in other post.
Thanks for reading!
- IIBA. 2015. BABOK. Version 3.0.
- Martin Fowler. 2003. UML Distilled. 3rd ed.