IS 401 Use Case Description Flashcards
use case description
a textual model that lists and describes the processing details for a use case
scenarios or use case instances
unique sets of internal activities within use cases
Brief Use Case Descriptions
A brief description can be used for very simple use cases, especially when the system to be developed is a small, well-understood application. A simple use case would normally have a single scenario and very few—if any—exception conditions. An example would be Add product comment or Send message.
A use case such as Fill shopping cart is complex enough that a fully developed description is also written.
Fully Developed Use Case Descriptions
The fully developed description is the most formal method for documenting a use case.
use case name and scenario
The first and second compartments are used to identify the use cases and the scenarios within the use cases (if needed) that are being documented. In larger or more formal projects, a unique identifier can also be added for the use case, with an extension identifying the particular scenario. Sometimes, the name of the system developer who produced the form is added.
triggering event
The third compartment identifies the event that triggers the use case.
brief description
The fourth compartment is a brief description of the use case or scenario.
actors
The fifth compartment identifies the actor or actors.
related used cases
The sixth compartment identifies other use cases and the way they are related to this use case. These cross references to other use cases help document all aspects of the users’requirements.
stakeholders
The seventh compartment identifies stakeholders who are interested parties other than specific actors. They might be users who don’t actually invoke the use case but who have an interest in results produced from the use case. For example, in Figure 5-2, the accounting department is interested in accurately capturing billing and credit card information. Although no one in the marketing department actually creates new customer accounts, they do perform statistical analysis of the new customers and create marketing promotions. Thus, marketers have an interest in the data that are captured and stored from the Create customer account use case. The sales department is interested in having an easy-to-use and attractive user interface to assure sales aren’t lost because of poor user experience. Considering all the stakeholders is important for system developers to ensure that they have understood all requirements.
Pre/Post conditions
The eighth and ninth compartments—preconditions and postconditions—provide critical information about the state of the system before and after the
use case executes.
Preconditions
identify what the state of the system must be
for the use case to begin, including what objects must already exist, what information must be available, and even the condition of the actor prior to beginning
the use case.
Postconditions
identify what must be true upon completion of the use
case. Most importantly, they indicate what new objects are created or updated by the use case and how objects need to be associated.
The postconditions are important for two reasons. First, they form the basis for stating the expected results for test cases that will be used for testing the use case after it is implemented. For example, in the Create customer account use case, it is important to test that a customer record, address record, and account record were successfully added to the database. Second, the objects in postconditions indicate which objects involved in the use case are important for design.
flow of activities/ exception conditions
The tenth compartment in the template describes the detailed flow of activities of the use case. In this instance, we have shown a two-column version, identifying the steps performed by the actor and the responses required by the system. The item numbers help identify the sequence of the steps. Alternative activities and exception conditions are described in the eleventh compartment.
