Where have use cases gone when it comes to documenting software? I’ve been given all kinds of requirements, many from templates with all kinds of things for analysts to complete. However, I haven’t seen a Use Case in years.
A use case is very simple, yet provides some very valuable information. It defines a business process your system must implement. A Use case commonly has the following characteristics:
Actors – One or more individuals or automated systems participating in the activity
Description – A description of the activity being performed.
Explanation – Why the activity is being performed…what is it’s purpose
Steps – What are the sequence of events necessary to being and complete the activity
A good example of a use case may be checking a book out of a library
Actors – Borrower, Librarian or Self Help Terminal
Description – Borrower wants to remove a book from the library facility
Explanation – The borrower wants to read a book, but does not wish to read it on premise. They wish to take the book into their own custody so they may read it on their own time schedule.
Steps;
1) Borrower selects book from library shelve
2) Borrow checks out book
a. Borrower uses a library provided identification
b. Takes book to self help kiosk and electronically checks book out by scanning the bar code on their own identification card, scanning the book bar code, and accepting the receipt provided
or
c. Takes book to librarian who checks book out on borrowers behalf using the borrowers library card for identification. The system prints out receipt with name of book and the date the book is due to be returned. Receipt is provided to the borrower
3) Book is registered in system as being in the possession of the borrower
4) A late record is scheduled in the system for the data following the day the borrower is instructed to return the book
You can see a lot of information in this little story. Here are a few of the things you already know in this shot description without having to dig for them…
1) You already discern that there is a librarian, a computer system, a borrower, and a borrower library identification card having a bar code unique to the borrower.
2) Security requirements are known at a high level. A borrower may log into the check out feature using their own ID. A Librarian may log into the check out feature on behalf of borrowers.
3) You know you have books and have to know what your inventory is in order to determine where what books the library owns, and where they are located.
4) You know that a book has a limited period for being off site, and that the system tracks late items.
5) You can assume that there will be another use case for handling overdue books, because you are tracking when they are due.
Granted, this use case is very simple because it is so familiar to us. The beauty of a use case is that it works for you when you are entering into defining systems that don’t as yet exist, or are not familiar to you. You customer can almost always provide you with the information.
This doesn’t mean there is no value in a flow chart, data flow diagrams, class diagrams, functional specifications, technical specifications and the like. However, a use case gets to the crux of the problem in few words. The other specifications we can dig into at a later time. If you have a use case you can easily confirm your understanding with your customer because it is not a technical document. It simply describes their job. They know how to do that.
From my experience, we need to bring back the Use Case.
Cheers,
Ben