How do we write a use case ?

Topic: How do you write a Use Case?
By Nabanita Hazra

• What is a Use Case?
Use Cases are a method of defining requirements for the IT solutions. The basic concept of use case has been modified, augmented and adapted by practitioners over the years.
One of the common pillars of all use cases is – it defines the interaction between two or more entities called Actors.
A use case is often presented in plain text and as a diagram to address a communication issue.
Use case diagram represents the interaction between the actors involved, textually with an appropriate amount of detail.
The use case diagram is a visual representation of one or more use cases depicting the actors (stick figure symbol) and straight lines connecting them to the use case (ellipse or an oval symbol with the name of use case in it) . Thus use case is the interaction between the user and the software system.
Below is an example of a Use Case Diagram of a Courseware management system:

• Why would we write a use case?
When a business person wants an IT solution for his business, he approaches an IT company for help. However he explains his requirements in a simple language which is different from the language of the software developers. A use case is probably the best tool which plays as the connection point between the business users and technical users, which helps both the parties to understand the requirements on a same level and provide feedback on them.
A business analyst uses use case as a communication tool to bridge the gap between the business person and technical team, in terms of common language, explaining what the software is supposed to do.
As for a technical person, use case helps him to communicate with the stakeholder to using less text and explain more about what the system does.

• How to write a Use Case?
Use Case is very specific in terms of how the user actually interacts with the software system to achieve the desired goal. (Like Publishing of calendar, manage course details, notifying students. Etc.) . It only explains the tasks that are limited in the scope of the system.
The following is a common way of writing a use case:
1. Naming the use case: the name of an use case should be a verb – noun, i.e.: the name of the use case should describe the action to be done by the user. (E.g.: “Maintain Course Details “– here the user intends maintain the details of the course. )
2. Brief description of the Use Case: The description should contain the scope of the use case being described. This can probably start with “ This use case starts when …. “ and “ This use case ends when …. “ just to be specific with the scope of that particular use case.
3. Mentioning the Actors: Actors are the users who are actually interacting with the system. Thus in a use case diagram, actors play an important role as he is the one who is initiating a work of a use case. Thus, which particular actor is going to interact with the particular use case, needs to be mentioned. (e.g.: Course admin is an actor using use case “maintain course details. “ )
4. Mentioning the pre-conditions: There has to be few situations which need to be true before a use case starts. i.e.: Situations true for the system to initiate the use case. (e.g.: a course admin can only maintain the course details when the system is connected to a database where the information about the course is already available.)
5. Describing the basic flow of the use case: This description starts with how/why the use case is activated.
The Basic flow of a use case contains the flow of positive activities that takes place during the user –system interaction for that particular use case.
Thus we can say use case helps to identify what the system does for the user.
Basic flows help to identify activities of the use case which leads to the successful ending of the use case
6. Mentioning Alternate Flows/exceptional flows: in this section we mention the possibilities that might occur which may lead to unsuccessful ending of the use case. (e.g.: while maintaining the course, the system fails to extract data from database)
7. Mentioning Post-Conditions: these are situations that are true after the use case is over. So if there is any information that needs to be stored or outputs that needs to be generated, can be mentioned here in steps.
8. Special Requirements: These are requirements, which may be added later or be demanded by the clients. These are nothing but assumptions.

As business analyst, we should be clear about the fact that what the system is actually doing for the user. We should be able to describe the observable functionality of the system. Thus we use cases to bring that clarity to the table, helping us to ask smart questions that uncover gaps between thinking and understanding.