Use case diagrams can be refined and translated into actual use cases. These get us closer to writing the actual nitty gritty parts of your software requirements document. And they make sure also that we think of alternatives, priorities, and overall, why we're doing what we're doing. Think about, are we making good decisions? These can serve as a big first step into analysis. Each use case has a unique identifier and a name stating the clear and concise user task. These names should be made up of a verb and an object. Things like accept payment, give access, return book. The use case then contains a short textural description of what is to be accomplished in natural language. I'll show you an example of this in a second. Next, you have your preconditions. Preconditions are things that must be satisfied before the use case can begin. For example, in a chemical system, if we're trying to request an order, the system can't accept a chemical order until it knows that the chemical order is in stock. Also, you list post conditions. Post conditions state the state of the system after the use case is successfully completed. For example, after the chemical is successfully ordered, then we will find the information about the order in the database it will be stored. Finally, in the use case, you show the sequence of dialog steps or interactions between the agent and the systems that lead from the preconditions to the post conditions. These can be described in prose, but flowcharts or UML activity diagrams are frequently a more useful way to represent the logic flow. In this case here, we see an example use case for the goal of request a chemical. Note that we have the ID, the name, the management pieces. Then, in that next section down, we have the actors who are involved in the description. The description here says that in the case of requesting a chemical the requestor specifies the desired chemical by entering its name, or a chemical ID number, or by importing its structure from a chemical drawing tool. The system satisfies the request by either offering the requestor a new or used container of the proper chemical, where that chemical should be coming from, the chemical stock room. Or they should let the requestor create a request to order from some kind of outside vendor. In the preconditions, before requesting, the user must be authenticated, they must be allowed to request chemicals, and the database needs to be there, needs to be online, and it needs to be accessible. In order to complete the goal, the request will be stored in the tracking system. And the request will then be emailed to either the stockroom or the buyer. Those are post conditions and what we expect to happen. Next, we write out a detailed description of each use case, using references to alternative courses or to exceptions. You can see that yourself here in this example. This is a very limited example, but note that it does have that alternative course for if they want to get it from somewhere else. Full use cases also include priority, frequency of use, business rules, and other special requirements. Should also mention any assumptions you've mentioned along the way. Plus notes or issues regarding accomplishment of the goal. Well, that was an abbreviated standard for a use-case. You can also present the dialogue in just a little two column table. Put actors on the left, system responses on the right. Numbers show the order of the actions. So in this example, see on the left hand side that the actor first specifies the chemical, then, other side, system verifies that it is valid. Then the system goes through and shows that there is a list of containers within inventory, then it pops back to the actor side, the requestor. The requestor asks to view the history or maybe more information. Then the requestor selects a container, which means that they are basically done with the goals actions, or as the alternative, they ask to place a vendor order. The alternative would be covered in another use-case. This setup is more casual than the table-based use-case described before. It really only works if we are working on our clarified view of a software requirement. And by clarified view of a software requirement, I mean that only one actor is interacting with the system. Otherwise, you probably want to move to the full use-case. Use-cases may be casual, or they can be fully dressed. Casual use-cases are often used in extreme programming in Agile techniques. They're quick, they're easy to write, and very easy to understand for both the customer and the developer. Fully dressed requirements are beneficial if you don't get to talk to the user representatives that often. If the application has complex and has high risks, you want to write use case descriptions especially in that kind of scenario, where all the developers will understand what you meant. Also, you may have testers who are already trying to start to write test cases for the system, either for acceptance level testing or for their own testing later. Many functional requirements are easy to see from the dialogue steps, because of the actor in the system. But remember that there may be many that aren't described or aren't described in a high enough level. The requirements analyst needs to translate between the user's view of the requirements to the developer tool. In viewing a use case diagram, we only see the actors and those goal components. We fail to see many of the functional requirements until we get to a full use case description. From the use case description, then we can also add in non functional requirements, identify areas of missing functional requirements, see if we've missed alternatives, or not mentioned priorities. And overall, these make it easier for the developer
