Usage Scenarios

Usage scenarios capture the system's requirements in the users' business context, using a narrative or story format. They also describe necessary tasks and serve to document the series of steps required to complete a business function. Usage scenarios and the use cases from which they are derived should describe an application's expected behavior in multiple business processes. Gathering this information requires sitting down with users and determining every possible scenario for a specific function. Documenting usage scenarios might seem tedious and not as much fun as drawing stick figures, but it is helpful in finding possible missing conditions.

The project team can use the usage scenarios to keep its focus on the real problem to be solved. Usage scenarios should also provide a conceptual description of what the application must do and provide the basis for the logical design of components in the application. Also, even if some previously undiscovered interaction is identified later, new use cases can be incorporated into the design.

To see how a usage scenario works, take the simple process of a customer logging on to the Billington Web site (see Figure 3.5) and walk through what a usage scenario might look like:

Usage scenario: A customer logs on to the Billington.com Web site to order medicine.

When the logon page is displayed, the customer is asked to enter his or her username and password, and the authentication process begins.

If the customer leaves the username blank, an error message is returned explaining that the username must be filled in, and the logon page is displayed again.

If the customer leaves the password field blank, an error message is returned explaining that the password must be filled in, and the logon page is displayed again.

If the customer enters an invalid username, an error message is displayed indicating that the username is invalid, and the logon page is displayed again.

If the customer enters a valid username but an invalid password, an error message is displayed indicating that the password is invalid, and the logon page is displayed again.

If the customer selects the Forgot Password check box, a window is displayed with the option of entering the username and sending the password in an e-mail.

If the customer enters a valid username and password, the initial product order entry window is displayed.

Figure 3.5. The logon function.

graphics/03fig05.gif


Finally, it is important to remember that the scope of use cases is not created while defining the system requirements and then forgotten. Use cases come into play throughout the development life cycle, from the requirements phase to system testing, through the analysis, design, implementation, and documentation stages. Besides, a good stick figure is a terrible thing to waste.



Analyzing Requirements and Defining. Net Solution Architectures (Exam 70-300)
MCSD Self-Paced Training Kit: Analyzing Requirements and Defining Microsoft .NET Solution Architectures, Exam 70-300: Analyzing Requirements and ... Exam 70-300 (Pro-Certification)
ISBN: 0735618941
EAN: 2147483647
Year: 2006
Pages: 175

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net