Detailing Use Cases

The following sections illustrate the results of applying information architecture to use cases. Among the available use cases, we have chosen to elaborate a cross-section of use cases for illustrating how information architecture can be used to refine the use cases. The scenarios depicted in the following detailed use cases contain more UI-specific information than found in the use case summary. We now have the ability to predict the sequencing of pages (or screens) and the associated navigation semantics, and specify this order in the use cases. In detailed use cases, the system's interactions with actors are more refined, and we are able to discern, to some degree, the flow of information between interacting subsystems. We have provided notes with the following use cases to annotate certain aspects for improved readability.

The format used in the upcoming section "GreaterCause Detailed Use Case Description" for detailing use cases is specified in Appendix A. This format is suggestive, and you may modify it according to the needs of your organization and project. Appendix B contains the wire frames essential for expressing the information architecture for the GreaterCause system. Appendix C contains the site flow and provides the navigation semantics for wire frames in Appendix B. Refer to Figure 2-1 for an abridged version of the site flow. The figure is distilled from Appendix C and is relevant for the discussion in the section.

Figure 2-1: GreaterCause abridged site flow

GreaterCause Detailed Use Case Description

The following sections present the detailed use cases for the GreaterCause system. The use case description for each use case encompasses various aspects of information architecture, workflow transaction semantics, and system interactions. Where appropriate, an activity diagram is used for explaining a complex flow.

Create Campaign Use Case

This use case provides portal administrators and site administrators the ability to create campaigns for featuring selected non-profits on their respective portals.

Actors

• Search NPO

• Portal administrator

• Site administrator (as a stand-in for the portal administrator)

Note

Notice that in the preceding list of actors, the Search NPO package is an actor that represents an external subsystem. In most cases, the package classification usually translates into a separate subsystem or part of another subsystem implying that the functionality of the Create Campaigns use case will always be in a different subsystem than that of the Search NPO.

Precondition(s)

• An administrator is logged in as a portal administrator or a site administrator.

Postcondition(s)

• A new campaign is created and saved by the system.

User Interface The following illustrates the user interface for Create Campaign use case.

Note

The granularity chosen for this use case is pretty coarse. This has resulted in a situation where several UI interactions are being addressed by a single use case. The advantage of a coarse-grained use case in this instance is that we are able to explain the flow of events as a related set of actions.

Create Campaign Main Flow of Events

1. The use case is instantiated when an administrator or site administrator selects Create New Campaign on the Administrator Services page.

2. If the administrator is a site administrator,

   1. The system displays the Enter Portal ID page.

   2. The site administrator provides the portal ID for which he or she wants to perform administration functions.

   3. The system validates the portal ID; if the validation is successful, the system allows further processing, else the site administrator is requested to re-enter the portal ID.

3. The Create Campaign use case invokes the services of the Search NPO use case for searching and selecting an NPO. The Search NPO function delivers the selected NPO to the Enter Campaign Details page.

4. The administrator furnishes the start date, the end date, and the region code.

5. The administrator requests the creation of a new campaign.

6. The system validates the campaign attributes supplied by the administrator and on successful validation stores the campaign in the system.

7. The system acknowledges the creation of a new campaign, and the use case ends.

Note

Comparing the preceding flow of events with the flow of events in the use case summary, it is apparent that the information architecture and the resulting wire frames have enabled us to visualize, to a much greater degree, the interactions between the user and the system. The details added to the use case description as a result of the information architecture will make it possible to use it as a contract between the stakeholders and implementation team. This level of detail also serves as a starting point for generating test cases. We can freeze requirements at this juncture and start design and development.

Activity Diagram The following illustrates the activity diagram for the Create Campaign use case.

Note

Activity diagrams, although at a coarser grain than the textual flow of events, provide a comprehensive view into the use case by depicting all possible main and alternate flows.

Update Campaigns Use Case

This use case provides portal administrators and site administrators the ability to update existing campaigns for a given portal-domain.

Actors

• Portal administrator

• Site administrator (as a stand-in for the portal administrator)

Precondition(s)

• An administrator is logged in as a portal administrator or a site administrator.

Postcondition(s)

• Changes to campaigns are saved by the system.

User Interface The following illustrates the user interface for the Update Campaigns use case.

Update Campaigns Main Flow of Events

1. The use case is instantiated when a portal administrator selects Update Campaigns on the Administrator Services page.

2. If the administrator is a site administrator,

   1. The system displays the Enter Region Code page, which requires the administrator to provide a portal ID and the region code.

   2. The site administrator provides the portal ID for which he or she wants to perform administration functions. The administrator submits the region code for which campaigns are to be updated or leaves the field blank for updating global campaigns.

   3. The system validates the portal ID; if the validation is successful, the system allows further processing, else the site administrator is requested to reenter the portal ID.

3. If the administrator is a portal administrator,

   1. The system requests a region code.

   2. The administrator submits the region code for which campaigns are to be updated or leaves the field blank for updating global campaigns.

4. The system displays active campaigns in the Update Campaigns page. Active campaigns are those whose end dates have not expired.

5. The administrator modifies the campaigns and submits the changes to the system.

6. The system validates the campaign attributes supplied by the administrator, and on successful validation stores the changes in the system.

7. The system acknowledges the changes, and the use case ends.

Activity Diagram The following illustrates the activity diagram for the Update Campaigns use case.

Manage Donation Cart Use Case

This use case handles the process of displaying, adding, removing, and modifying donations in the donation envelope.

Note

This use case was selected for elaboration to depict the usage of nested "includes." The Manage Donation Cart use case is extended by the Register Donor use case, which in turn includes the Manage Donor Preferences use case. The Manage Donation Cart use case interacts with an external subsystem Portal Pass-through.

Actors

• Donor

• Portal Pass-through

Precondition(s)

• Portal-domain of the donor is registered with GreaterCause.

Postcondition(s)

• Donation Cart is updated according to the action taken by the actor.

• Unregistered donors are registered by the system.

Include/Extend Use Cases

• Register Donor

• Manage Donor Preferences

User Interface The following illustrates the user interface for the Manage Donation Cart use case.

Manage Donation Cart Main Flow of Events

1. The use case is instantiated when a donor either selects to donate to a non-profit from the search results page, or donates to a featured-NPO from the portal-domain's portlet. The system adds the selected NPO to the Donation Cart.

2. (set unregistered).

3. The system displays the Donation Cart.

   Note

   (set unregistered) is a label used for the extension point where the use case Register Donor will conditionally inject itself in the Manage Donation Cart use case if the donor is not a registered donor. The label "unregistered" may appear in the flow of the Manage Donation Cart, which is the base use case.

4. The donor provides the donation amount and the preferred cause.

5. The donor requests Proceed To Checkout.

6. The use case ends.

Note

Exceptional flow of events infer most of the action-sequence from the main flow, therefore terseness is acceptable.

Exceptional Flow of Events

• Donor selects Update Cart After editing the Donation Cart, the donor could select Update Cart instead of Proceed To Checkout.

• Donor selects Continue Donating After editing the Donation Cart, the donor could select Continue Donating instead of Proceed To Checkout.

• Donor removes NPOs from Donation Cart While editing the cart, the donor could select certain non-profits for removal.

Register Donor Use Case

This use case creates a new donor identity in the system. The identity is provided by the portal-domain with which the donor has affiliation. This is a one-time process for donors. The donor need only log in once to the portal, and access to GreaterCause does not require another login.

Actors

• Donor

Precondition(s)

• Prospective donor wants to make his or her first donation.

Postcondition(s)

• Donor is registered, and donor preferences are created in the system.

• Donor is taken to the Donation Cart page.

Include Use Cases

• Manage Donor Preferences

User Interface

The following illustrates the user interface for Register Donor use case.

Main Flow of Events

1. The use case is instantiated by the Manage Donation Cart use case, when an unregistered user attempts to make a donation.

2. The system verifies the authentication token presented by the donor.

3. The donor is presented with a Registration page. The registration page is pre-populated with attributes that were provided by the portal-domain.

4. The donor provides the missing information and submits the registration information.

5. The system will validate and store the registration information. The system will also create a Donor Preferences record and initialize it with a registration ID.

6. Include (Manage Donor Preferences).

7. The use case ends.

Manage Donor Preferences Use Case

This use case enables donors to create personal preferences for customizing their donation process.

Actors

• Donor

Precondition(s)

• Donor is already registered into the system.

Postcondition(s)

• Modified preferences are stored in the system.

User Interface The following illustrates the user interface for the Manage Donor Preferences use case.

Main Flow of Events

1. This use case is instantiated either by the donor registration process or when the donors select to modify their personal preferences.

2. The donor is presented with the Donor Preferences page.

3. The donor makes the required changes to the attributes and submits the information.

4. On successful validation, the system stores the donor preferences.

5. The system acknowledges the changes, and the use case ends.

Note

Now that we have elaborated selected use cases, compare it with summary-level use cases of Chapter 1. It is apparent that with the help of the detailed use cases, we are able to discern the invocation order of each use case for realizing a specific process flow, and the associated transaction semantics, from the point of view of the system user.