As I have already explained the importance of Use Cases and Usage Scenario in my earlier post of Analyzing information. This post would throw more light on Use case and Usage scenario.
Use cases consists of some elements that are responsible for functionality and behavior of the system. Users always interact with the system to do some activity and get some result. Ideally, Use cases should represent all the processes, including all the events that can occur in all possible situations. Creating Use cases is one of the main step of requirement gathering and analyzing and it should not be ignored. It helps non-technical people to understand the system well because it does not require any technical language. It enables easy communication between End User and Stakeholders and Project team and it bring them to agree on common perception about the system. Use Case diagram is basically developed in Feasibility phase. Use case is based on what to develop concept rather than how to develop the system
A use case diagram documents the following design activities:
· Identifying the system
· Identifying actors
· Defining the interactions between the actor and the system
· Determining the system boundary
Identifying the system When we develop the Use case, we need to identify the single system or subsystems. A system can be a collection of many subsystems. For example, Online Shopping System might have a subsystem that validate and authenticate the credit card for the shopper. A collection of Use cases indicates the relationships among the subsystems that make up the system, in addition to the relationships between systems that interact with each other.Identifying actors
The actor is external entity which interact with the system to be built for the completing an event. In sample language, Actor represents Users who interact with the system for their day to day activities. Also, Actor can be another system or database that might interact with subsystem. The actor is an integral part of the use case. The use case represents the interactions between an actor and the system. An actor can be: For example, In library Management System, some of the actors are Member, Book Entry Clerk, Manager, Cashier etc.
The roles played by actors explain the need and outcome of a use case. By focusing on the actors, the design team can concentrate on how the system will be used instead of how it will be developed or implemented. Focusing on the actors helps the team to refine and further define the boundaries of the system. Defining the actors also helps to identify potential business users that need to be involved in the use case modeling effort.
What is Usage Scenarios?
Usage scenarios describe in detail a particular instance of a use case. It takes many usage scenarios to document a use case completely. Whereas use cases are diagrams, usage scenarios are narratives. Usage scenarios provide additional information about the activities and task sequences that constitute a process. Usage scenarios document the sequence of tasks. Usage scenarios depict objects in a workflow process. Objects are something that are affected by the system, something that affects the system, or something that a system needs to be aware of to function properly. For example, objects in a training center include the customer, the training course, and the sales representative. Objects provide a view of the characteristics and behavior of elements in the problem domain that is addressed by the business challenge. In the conceptual design phase, you create usage scenarios that depict the objects in the problem domain.When you develop usage scenarios, you might identify a task that must be treated as a use case. For example, in the “Register customer for course” use case, you might determine that the task sequence “Process customer payment” is a high-level use case that is part of the workflow process and has several usage scenarios. Consequently, each usage scenario for “Register customer for course” ends with “Entering course number.” Then you create all relevant usage scenarios for the new “Process customer payment” use case. You identify the use cases that correspond to the workflow process and then develop usage scenarios that describe the task sequences for each use case. From the usage scenarios, you can determine the current state requirements.
Need of creating Current State Usage Scenarios?After you identify a use case, you can determine the different usage scenarios that can occur for the use case. You then use the information that you gathered from users to describe the different usage scenarios possible for the use case. Creating a usage scenario helps you determine if you gathered the appropriate level of information. Gathering the required amount of information for describing the current state is part of the iterative aspect of gathering and analyzing information.
You can create scenarios for both the current and the future states of the business environment. The current state scenario depicts how business activities are currently conducted; the future state scenario presents the activities as the business wants them to be. For both states, the scenario emphasizes business processes, information, users, and tasks. In some situations, full scenarios need be developed only for use cases that are known to have many exceptions or dependencies. This allows the project
team to balance costs against the potential benefits. Use cases and scenarios should be developed iteratively, and can be discovered or continued during development work on the initial set of use cases. Although there are various ways to analyze the current business processes, use cases and usage scenario specially effective in modeling the process.
|
Use case title: Customer requests product literature |
| Abbreviated title: Customer requests product literature |
| Use case ID: UC05.1 |
| Requirements ID: 14.1 |
| Description: Customer wants to obtain information for a product. The customer is able to view a copy online, print a copy, or request a hard copy to be delivered by mail. |
| Actors: Customer |
| Preconditions: · Customer has Internet access.· Customer has browsed to the Adventure Works Cycles Web site.· Customer has clicked Browse Product Descriptions.· Product information exists in the database, and the site is working properly. |
| Task sequence |
| Customer scrolls to desired product. |
| Customer selects product by clicking on product graphic or details. |
| Customer views basic product information (name, description, image, in-stock status, price, item number). |
| Customer clicks Need Complete Specification? |
| Customer views full product specification online (UC05.1.3). |
| Customer clicks Mail Me Full Brochure (UC05.1.1). |
| Customer clicks Submit. |
| Customer browses away from product specification. |
| Postconditions: The request to receive the full specification by mail is complete and saved in the database. |
| Unresolved issues: How should saved requests best be queued for fulfillment?If submit process fails three times, what process should be invoked? |
| Authority: Mike Danseglio |
| Modification history: Date: November 6, 2002Author: Heidi SteenDescription: Initial version |
Reference : Analyzing Requirements and Defining MS .Net Solution Architecture exam 70-300 eBook.
