Requirement elicitation is commonly mentioned among business analysts, but where do these requirements originally come from? It is quite complicated to understand and start collecting the required functionality as the product stakeholders" explanations are often ambiguous, diverse and lacking of technical terminology. But how do you manage to identify and write down all the functionalities required by the stakeholders, the user roles and their actions? The answer is pretty simple - you have to perform a use case analysis in order to capture the contracts between the system and its users and then refine the system"s use cases and obtain an organized and more complete view.
Writing effective use-cases is one of the most important responsibilities of a business analyst as it provides the elicited functional requirements with enhanced objectivity and reliability, allowing for a proper representation of the functional and behavioral requirements of a software product. As opposed to the textual-only representation, use case modelling allows for a stepwise description of the independent or interconnected sets of actions, which are performed by the designated actors.
Once written, use cases become deliverables of wide use, being beneficial for several participants in the project delivery lifecycle, namely: stakeholders, BAs, development and testing teams, technical writers, UI/UX designers, software architects and even the product"s management teams.
In order to have a solid starting point in collecting the correct requirements of a system, a BA should first question about who will use it, who will gain business value by interacting with that system or who will achieve a business goal by means of that interaction. The answer is - the ACTORS - namely persons or software components that make use of the system under discussion. It is recommended to give a name and a short description for each actor, in order to avoid confusions, role overlapping and/or ambiguity. The actors are outside of the system and they can be of several types, for example the main actors of a use case, the supporting actors of use cases, sub-systems or components of the system under design.
After shedding light on all the actors, the BA must identify the activities or sets of activities performed by each of them. These are called use cases - and represent the way in which the actors interact with the system, in order to obtain business value and achieve their goals. These actions must be independent, having names and short descriptions as well. The BA must also be aware that among these activities some are happy day scenarios, some are alternatives and there can also be error scenarios and only a deep understanding of the business will make them able to accurately determine and classify them. Also, in order to obtain accurate use cases, attention has to be paid to the pre and post conditions of each use case.
So, the use cases are the core of a software product, as they describe its behavior and way of use, from the viewpoint of each actor. Use cases are a very powerful requirements modelling technique. The complete set of actors and use cases is known as the system"s use case model. This model can be represented as a written document or as a diagram, commonly both, since each provide a different level of detail of the use case, with actors represented as people, use cases as ellipses and their relationship by arrows, oriented from the actor towards the corresponding use case performed.
Let"s say we have a customer whose business is hosting events, such as conferences, in their building.
The customer"s building has 3 conference rooms each able to accommodate 100, 150 and 200 people, respectively. The customer provides a complete service for their customers that include:
At the moment, our customer maintains all this data using spreadsheets and wants us to build a web-based, IT solution that helps them manage and administer his services.
So, how should a BA proceed in understanding the actual requirements for the IT solution?
A little "domain knowledge" in hosting events would help, since it would highlight the fact that, usually, rooms can be split by means of fake walls and thus the number of rooms is actually variable, depending on context. For simplicity, let"s assume that this time it is not the case.
Also, a first look at the customer"s description would highlight the fact that the rooms are actually not the same size, so perhaps they might have different pricings.
Furthermore, "domain knowledge" helps us again in that it makes us ask about overbooking policies.
In any case, we should never make assumptions but rather ask the customer about all of these topics as soon as we think about them!
So, in our simple scenario, we"ve asked the customer all these questions and have concluded that the room number is fixed (there is no possibility to dynamically split the rooms), there are no overbooking policies and, indeed, rooms have different prices that the customer wants to be able to change, and voila, a hidden requirement: management of the room prices!
Now, to the actors! Who are they? Some of them are obvious: the people reserving, confirming and cancelling reservations and our customer"s customers that need to be able to rent rooms.
But is this so? Let"s ask our customer and see! Upon asking the customer, what do you know? - it appears that it actually isn"t! Customers of our customer never actually use the system when booking rooms since our customer does not have the means for e-payment, so it is someone from their staff that actually assigns one or many rooms to one of their customers.
So, the actual actors are the people attending (via reservations) to the event and our customer"s staff.
It is very important to name these actors using domain specific names! We wouldn"t want to call the person attending an event the Chef - that might be an appropriate name for a restaurant application rather than our conference room booking application. So, asking the customer, as always, we find out that they actually refer to these people as Attenders - so one actor would be the Attendee.
Alright, so what should we call the staff member that assigns rooms to their customer?
Our customer says that they call these staff members precisely that, staff members - so one actor would be Staff Member.
Putting it all together let"s try a simple, high-level, use-case diagram to describe these facts:
Well, the first thing we spot is that we"re missing parity! We have an "Assign rooms to customer" use case but it appears that we"re missing the "Un-assign rooms from customer" use case.
But, what a surprise, when we ask our customer about this they say they don"t have a clue about what we"re talking about with un-assigning rooms!
This is a breakthrough for us since it means that we are about to deepen our understanding of the domain! After asking the customer about how they actually manage room assignment for their paying customers they say that they actually don"t do it like we assumed!
What they do, is they create an Event, with a customer, a name and a description and they actually assign rooms to that Event. They never un-assign anything, they simple go and delete the Event from their spreadsheets once the Event took place!
That is interesting, and we immediately guessed that the Event must also have a date and that it wouldn"t make sense to allow people to make reservations to an Event that has already happened!
Our customer immediately confirmed that it is so!
Another try at the use case diagram renders this result from Fig 2.
We are still not happy with our previous parity problem. We are experienced business analysts and we know one thing: Users make mistakes! So, whilst using spreadsheets, our customer wasn"t aware about the fact that there is indeed a hidden "Un-assign rooms from event" use case that takes place by simply overwriting or deleting a row in the spreadsheet. However, since we"re building a dedicated IT solution the use case must exist explicitly if users are to be able to correct erroneous room assignments.
So, we insist and the customer accepts. Therefore:
Of course, we didn"t want to go into it until now since it is a generic and thus not domain specific topic, but there is the aspect of defining staff members that the system will authorize! It is a rather generic topic but there usually tends to be an Administrator who is able to assign roles to people.
So, while it is simple enough to plot the Administrator actor in there with the power of assigning the Staff Member and Administrator roles to people, the question emerges: How are Attendees created? This, like many others so far, is a question that only the customer can answer (but they won"t do it by themselves, it is our BA job to ask them!)!
Surely enough, the customer answers and tells us that everybody should be allowed to attend!
So, the Administrator would not be in charge of granting the Attendee role - anyone has it by default!
Looking at the use case diagram, we"re trying to run scenarios based on the initial customer provided description to see whether we"ve covered everything. Something is missing: Nonattendances!
Our customer wanted to know if someone has made a reservation but hasn"t actually showed up without cancelling the reservation. If only there was a way of distinguishing the people who actually do show up from those that don"t!
Hmm, and this is when we realize that the Confirm reservation use case is a non-sense. What does it actually mean to confirm a reservation? Is it confirmed by the system in that your seat is booked for you and you won"t lose it? Is it confirmed that you actually showed up?
The customer clarifies that the intent would be to specify that somebody actually shows up. Well, in that case it should be entitled "Confirm attendance" rather than "Confirm reservation" and it should belong to the Staff Member, not the Attendee. Confirming a reservation makes no sense since reserving a seat would either fail, since no seats are available, either succeed, because there are no overbooking policies that might cancel a reservation!
So, can we now support all the requirements that the customer originally issued?
What"s still missing is the ability for someone, presumably, the staff member to see a nonattendance report showing the people that did not attend whilst not having canceled their reservations.
We ask the customer about this and they confirm! So we need a use case for that as well!
Also, what about deleting an event? Do we actually delete an event or do we just mark it as having taken place so that no reservations can be made for it? It matters because not deleting an event allows us to mark the completion of the event whilst still providing us the chance to run reports (such as the nonattendance once the customer just confirmed).
As always, upon asking the customer, they confirmed that they want the event to remain in the history of the system and that the action should be called "Close" the event. While closed, no reservation can be made for that event. Also, once closed, the event can never be opened again since the action should only be done after the event actually took place! Considering that, we ask whether closing an event shouldn"t actually be an automatic action employed by the system at the proper date (remember that we previously discovered that apart from customer, name and description, an event also had a date).
The customer happily approves our idea! Therefore:
Finally, it appears that we now have the complete use case diagram that supports all the customer requested scenarios and it enhances them with automations and administrative capabilities!
Let"s not forget our hidden requirement: Managing room prices!
Asking the client, they say that the room prices rarely modify and, for the moment, they don"t want the implementation of this use case!
We run the diagram by our customer and they"re very happy!
Use case advantages
Use case limitations
In conclusion, use case analysis is extremely important in and off itself, regardless of the deliverables, which are of course extremely valuable. Why deliverables are valuable is obvious, since they represent the core of the system"s functionality and behavior and are used by a very diverse set of people from business analyst, architects, users and so forth for everything from describing the system to validating the architecture using many use case based scenarios. But why is the mere act of performing a use case analysis important? Because it allows us to methodically decompose the high-level requirements to an ever detailed and profound domain understanding that helps us uncover the real requirements! Only by performing a thorough use case analysis can we hope to uncover the underpinning domain model and develop an IT system truly aligned to the actual business requirements.
by Larisa Goța
by Ambrus Oszk
by Alpar Torok
