|
|
 |
The first question to be answered is: What is a Use Case? Why such an arcane term to define a very simple process that is essential to the creation of software or any other business system. A standard definition could be: Use Case Model defines the User's view of interactions with (and within) the system. Use Cases show how entities interact, and are usually presented as structured text or diagrammatically. Use Case is simply a method to facilitate information exchange. The commodity being acquired is the business knowledge of the user. This knowledge is transferred to a programmer/architect who then uses their expertise to develop software. In order to create quality software an explanation of how the system is to function must be clearly understood by all involved. Therefore, a use case stands as a mutually understood and accepted representation of how a user, commonly referred to as an actor, interacts with a desired or existing system. This method of information transference has taken on a life of its own. The best form, according to Alistair Cockburn, is to describe a purpose (which are the requirements). The use case contents are written in consistent prose. It may have plurality where several scenarios can be described per use case. The typical use case structure is semi-formal. It is a good idea to employ use cases when developing or changing software; this practice can keep everyone in the same ballpark. Part of the difficulty in software development is making it clear what the “customer” really needs in order to get on with the business of their business. There are so many interpretations of how to structure a use case that it can get confusing. It is best to realize that there is no “right” way only the best way for that particular situation. The job of a use case is to ascertain that best way and maintain focus on the essential business need. At ArchWing Innovations we strive for the best practice of listening and observing the needs of the client and then using the most appropriate tools. Here is an example of a use case to lead the development of changes to an existing system: This customer had allowed a very complex database to grow without an administration function as part of the management of the system. Several primary use cases were created with the input of the system administrator. The use cases were described in a narrative manner. Here is the Use Case for Database Modification: Characteristic Information  Description:There is a need for system administration to make modifications safely in isolation of the production environment to ensure correctness and accuracy of the changes before subsequently applying them to production. Data modification should be traceable, testable, and include a full description that can be repeated if necessary. Requirements:The system administrator (SA) needs to model a non-schema data change, test and verify the change model. The verified data change model then needs to be applied to the production database.
Preconditions:The Administrator needs to make a non-schema data change to the production database. Success End Condition:A verified and traceable change has been made to the production database. Actor(s):
Trigger:
Issues:
Another method to communicate requirements in use case form is through diagrams. Gas Station Model Station - A physical location for dispensing gasoline to vehicles Attendant - A station employee primarily responsible for managing transactions Pump - Dispenses gasoline Gas - The primary product of a convenience station Customer - Generally the driver of a vehicle requiring gasoline Self-Service - The procedure where customers dispense gasoline themselves A convenience gas station is located for easy access by automobile traffic and dispenses gasoline to vehicles. Customers drive vehicles directly to gas pumps and dispense gasoline themselves before then paying the station attendant. The attendant checks the pump for the dollar amount of gas dispensed and collects from the customer. Gas Station Use Case Analysis Two use cases stand out as being essential: A. Dispensing gas - Customers dispense gas from a pump into their vehicle B. Conducting the transaction - Customers pay the service attendent A. Dispensing Gasoline 1) Customer selects options from pump 2) Customer connects pump to vehicle 3) Customer starts pump 4) Pump dispenses gasoline to vehicle
Notes: - The gasoline element did not seem necessary to describe this use case - Use #1 is a candidate for a separate use case to show additional detail - It is observed that this use case describes the “Self-Service” procedure model element B. Conducting the Transaction 1) Customer approaches attendant 2) Attendant receives total from pump 3) Attendant notifies customer of total 4) Customer pays attendant
The use case methodology brings considerable value to a software development process. It is a highly respected method to describe process requirements to a developer who may not have any opportunity to be in the daily business process. This regularly results in fewer dollars spent on software development, accurate creation of the software for the business and overall higher return on your technology investment. |
||||||||||||
  Copyright © ArchWing Innovations, LLC 2001 AWI TechNet Index | AWI Corporate Site
|
