Intro
Today I will be talking about use cases. This article is not about programming, but rather about planning software projects.
A use case documents a feature that a user should have with the program. In a professional project, there are hundreds of use cases, one for every way the user can interact with the program. These use cases are developed with the client and the developers. It is a critical step, because it sets the basis for a lot of the subsequent work for the developers. Ultimately use cases create a list of things your program should be able to do.
Developers can then follow this list and deliver software that accomplishes everything that the user wants. I see them as a godsend in project planning. You can group related cases together and their placement will almost directly relate to their placement in code. With an explicit list in front of you, it becomes much easier to see all the features your development team must finish. This become a lot more important as the size of the project increases.
Although use cases are usually used by professional software development firms, I would recommend that programmers use them for their personal project. They can really simplify the problem and they stress breaking the problem down. It's really a great tool and I encourage all programmers to use them, if the project is large enough to warrant it.
Formating use cases.
Formating use cases is really subjective to style. Some are very detailed, while others are generalized. With that said, you should try different styles and levels of details for yourself and see which ones help you the most and give your the best ROI. One that I personally use would look something like this:
----------------------------------------------
<Title of use case>
<Summary>
<Stakeholders> //This list the people and systems that this feature will interact with.
<Prerequisites> //Things that need to be true for this feature to be available.
<Scenario> //A non-technical description of the steps to accomplish this task.
-----------------------------------------------
Here is an example for use case for something for a game of poker.
Making a bet
Summary: The game player is prompted to make a bet every time another card is dealt.
Stakeholders: The player
Prerequisites:
-The player must have enough money to bet.
-The player's best cannot exceed the computer's cash level.
Scenario:
- The player selects an amount to bet
- The bet is validated based on the prerequisites above
- If the bet is valid, subtract the funds from the players level.
- Else print out a message and stop the bet process.
- Add the bet to the overall pot.
----------------------------------------------------
This is a very simple example, but as you can see, this use case tells us exactly which feature we need, how it will work and how. Having an array of use cases for all the features of your programming project can really make the build process very smooth. Of course, clients may want features added and removed throughout the project, and this can be easily expressed with use cases.
That's the basis of using use cases. If I missed something critical, let me know.
