Basic Principles of Use cases

In the last article, I gave an overview of use cases to generically explain the structure of a use case. This time, I would like to elaborate on the basic principles of use cases.

Some basic principles of use cases are

1. Use cases should tell a story: A story is a great way to allow everyone to connect with the big picture while passing knowledge in an easily understandable and digestible format. The use cases capture the goal of the system through stories. The stories explain what needs to be done to achieve the goal and how to handle/solve any potential problems that might be incurred on the way. Instead of capturing the whole system at one go, the requirements are captured on a use case by use case basis. The use case narrative entailing each use case provides the story on each use case. While capturing the requirements in a story format is important, it is equally important that the stories are captured in a testable and actionable manner. The test cases are integral here.
2. It should help you understand the big picture: In order to make critical decisions, it is important to understand the high level requirement of the system. Only if you have the high level understanding of the system, would you be able to make decisions regarding what should be included in the system, left out, what would be more important, etc. This does not require you to capture all requirements upfront. However, this does require you to map the system in some way. This is where a use case model comes in. Use cases provide detailed level requirements for the system while use case model describes the use case stakeholders as the actors and the various use cases as the way the actors interact with the system. This provides a quick high level overview of the use cases without having to perform an in-depth analysis of the system, use case by use case.
3. It should focus on value: Often, teams tends to get bogged down by the long list of features that a system offers. It is more important to understand the value that a system generates which is based on the amount of usage a feature generates. This can be done by generating a list of basic flows which determine the system as is and a list of alternative flows which determine the system's negative route path of alternative strategies if a problem is faced. In some cases, highlighting the alternative paths will provide you avenues to improve the system so as to find the edge over a competitor's products. Sometimes, simple flow is enough to provide all the value required. Figure 1 shows a sample use case narrative structured to provide a quick overview
4. It should help you build the system in slices: Most of the requirements are not visible the first time around. The requirements are dependent on other requirements that need to be built to support latter requirements. Hence, it is always important to build the system in slices, with each slice delivering incremental value to the user. The underlying process of doing this looks simple. Take the most important requirement and slice it into simpler requirements flushing out all the acceptance criteria through the process. Some slices cannot be completed and will have questions attached to them. Find the slice or series of slices that is required throughout the product, estimate it and build it. A use case might not be buildable at one go but a use case slice ca be built within a period of two weeks.
5. It should help deliver the system in increments: Each increment provides a usable version of the system that has an added value in it. Each increment improves the quality of value of what has come before. This is true of any system being built.
6. It should be adapted to meet the team's requirements: Depending on the comfort and availability of team, documentation might need to be heavy or light. The requirements and the way they are presented need to be suited to the team's needs. In cases where the team can interact and questions can be clarified on the go, these can be light, while on the others, they would need to be heavy. Choose what you deem best for your team.

BASIC FLOW FOR A CREDIT CARD APPLICATION
1. Applicant visits the website. 
2. Applicant visits the credit card product page
3. Applicant compares various credit cards offered. 
4. Applicant selects preferred credit card
5. Applicant fills out the application form
6. Applicant uploads required documents
7. Applicant verifies email address
8. Applicant provides further document as requested. 
9. Applicant completes application
10. Applicant received credit card via mail. 

ALTERNATIVE FLOW FOR CREDIT CARD APPLICATION
A1. Applicant's name or unique ID already exists in the system
A2. Applicant leaves the page during any of flow steps. 
A3. Applicant's address or income information does not match as entered in application
A4. Applicant is unable to verify email address or phone number
A5. Applicant does not use card even after 30 days of recieving card.
A6. Applicant is not eligible for the credit card or any other credit cards
A7. Appliant is not eligible for the credit card he applies but is eligible for another credit card

Figure 1 (Sample structure of a use case narrative)

In my next article, I will take you through a few sample use cases and use case slices to give you an overview of what this process entails.