GNOME Store Use Cases

Version: 0.1

Author: Curtis Hovey

Illustration 1 GNOME store use Cases

Query donor database

Identifier

gs-us-01

Description

The actor queries the donor database to retrieve or update donor information and answer questions about donor activity. This is a base use case included in other use cases.

Actors

Board member, GNOME representative via a service, donor via a service

Assumptions

The database is always available, and the data is updated in an transaction.

Frequency

Many times a day on an ad hoc basis.

Standard Scenario

The member or service

The member or service logs on

The member selects or write a query and runs it

The member sees the results.

Included Use Cases

None.

Extended Use Case

None.

Issues

What users really need direct query access to the donor DB?

Decisions

Board members are assumed to have direct access to the DB and are capable of running queries unrestricted.

Queries that are written may have errors and how the DB responds is outside the use case.

All other actors access the DB through a service that may require authentication. The service is responsible for logging the actor on. The service restricts the queries that the actor can perform.

Add to donor database

Identifier

gs-us-02

Description

The actor adds a donor to the database. It the donor is already in the database, the information us updated

Actors

Donor , Representative.

Assumptions

The service that for adding donors can connect to the database as it needs.

Frequency

Many times a day on an ad hoc basis.

Standard scenario

The agent submitted the donor information.

The donor data is validated.

[Alternate bad data scenario]

Validate the credit card.

[Alternate bad credit card scenario]

Check if the donor is in the database, and decide whether to update or add the new donor information.

[Alternate failed transaction scenario]

A confirm response indicate the donor data is in the database.

Alternate bad data scenario

The donor data contains invalid values.

Each invalid value is flagged to indicate what rule is unfulfilled.

A fail response is returned to indicate revisions are needed.

Alternate bad credit card scenario

The credit card's set of data is invalid or authorization failed.

Match invalid data to donor data is necessary.

Set declined messages if necessary.

A fail response is returned to indicate revisions are needed or that the credit card was declined.

Alternate failed transaction scenario

The donor data was not added to the database.

Set the failed transaction message.

A fail response is returned to indicate why the donor was not added to the database.

Included Use Cases

Query donor database.

Extended Use Case

None.

Issues

None.

Decisions

The service for connecting to the database does so on its own.

Donation

Identifier

gs-us-03

Description

The GNOME Representative adds or updates a donor to the database.

Actors

GNOME Representative

Assumptions

The Web interface to the donor application will permit Representative to login and add donations from any place at any time.

The Representative has the tools (Web browser) needed to access the Web app.

Frequency

Many times a day on an ad hoc basis.

Standard Scenario

The Representative has the donor information.

The Representative logs on.

[Alternate failed authentication scenario].

The Representative enters the donor information.

[Extended use case Add donor to database].

[Alternate correct donor information].

Representative see the confirmation that the data was added.

Alternate failed authentication

The Representative's credentials were rejected

The Representative corrects his credentials.

If the credentials are correct, the Representative aborts.

The Representative submits the revised credentials.

Alternate correct donor information

The donor information is invalid.

The Representative corrects the donor information.

If the information is correct, the Representative aborts.

The Representative submits the revised information.

Included Use Cases

None.

Extended Use Case

Add to Donor Database.

Issues

What should the Representative do when his credentials cannot be authenticated?

What should the Representative do when a donor's information is cannot be validated?

What should the Representative do of the payment information is not authorized?

Decisions

The representative may alter the donor information.

Illustration 2 Donor sequence

Illustration 3 Donor activity

Web Donation

Identifier

gs-us-04

Description

The donor makes a donation to GNOME by providing their personal and payment information. The payment information is sent to the credit card service. The personal information is saved in the donor database.

Actors

Donor

Assumptions

The Donor is using a Web browser to access the Web store.

The Donor has a credit card.

The Donor has a shipping address that gifts/products can be sent to.

Frequency

Many times a day on an ad hoc basis.

Standard Scenario

The Representative has the donor information.

[Include use case FAQ]

The selects the donation level/product and submits the information.

[Include use case FAQ]

The donor enters his personal and payment information.

[Extended use case Add donor to database].

[Alternate correct donor information].

Donor see the confirmation that the data was added.

Alternate correct donor information

The donor information is invalid.

The Representative corrects the donor information.

If the information is correct, the Representative aborts.

The Representative submits the revised information.

Included Use Cases

FAQ.

Extended Use Case

Add to Donor Database.

Issues

What should the Donor do when his credentials cannot be authenticated?

What should the Donor do when a donor's information is cannot be validated?

What should the Donor do of the payment information is not authorized?

What should the Donor do when he does not understand the forms and the FAQs did not help.

Decisions

The donor may only select one gift/product.

Illustration 4 Web donor sequence

Illustration 5 Web donor activity

FAQ

Identifier

gs-us-05

Description

The FAQ is a collection of frequently asked questions regarding the GNOME store. The FAQ use case is included in other use cases where the Donor requires help. The FAQ has sections dedicated security, donations and taxes, payments, shipping.

Actors

Donor

Assumptions

The Donor is using a Web browser to access the Web store.

The donor has loaded a page that links to the GNOME store FAQ.

Frequency

Many times a day on an ad hoc basis.

Standard Scenario

The Donor is on a page that links to the FAQ page.

The Donor activates the link to the FAQ page.

The Donor reads the relevant sections of the FAQ to answer his questions.

The Donor activates a the back button to return to the previous page.

Included Use Cases

None.

Extended Use Case

None.

Issues

What should the Donor do when his questions are not answered? It is common place to provide an email address and phone number.

The store aspect of GNOME may have customer service issues and must deal with them from the users perspective of a store. If the store is successful in drawing new segments of customers, more customer service issues will arise. The store will need to answer questions like:
Where is my product?
Why isn't my credit card accepted?
Why can't the product be shipped to my home?
What is GNOME's privacy policy, promotion lists, selling and renting lists?
Why wont my browser work with the store?

Users frequently access their online accounts. The store's simplicity, separating payments from donor information, does not relieve it from managing donor accounts. Donors may wish to review their account and order information, and they may want to edit some of it. Simply stating in the FAQs that the user doesn't have an account does not address problems for user who will make several donations/purchases.

Decisions

None.

Illustration 6 FAQ sequence

Illustration 7 FAQ activity

Export donor Database

Identifier

gs-us-06

Description

Board members can export the donor data in a portable format for use by other applications for reports and analysis.

Actors

Board member

Assumptions

Only a select group of people need access to export donor data.

The donor data will always be a manageable size for reporting.

A web interface is suitable for remote access the donor data.

Frequency

A few times a week.

Standard Scenario

The Board member has loaded the private donor logon page.

The Board member logs on.

[Alternate failed authentication scenario].

The Board member selects 'Export'.

The Board member selects the export format.

[Use case Query donor database].

[Alternate failed export scenario].

The Browser prompts the Board member to save the data to file.

Alternate failed authentication

The Representative's credentials were rejected

The Board member corrects his credentials.

If the credentials are correct, the Board member aborts.

The Board member submits the revised credentials.

Alternate failed export scenario

The database connection or query fails.

Set the failed export message.

A fail response is returned to indicate why the export failed.

Included Use Cases

Query donor database.

Extended Use Case

None.

Issues

What formats are needed? Gnumeric or a format that Gnumeric can import?

Setting up an OpenOffice data source may be a viable alternative to a Web interface

Decisions

None.

Illustration 8 Export sequence

Illustration 9 Export activity

Report donor Database

Identifier

gs-us-07

Description

Board members can run queries against the donor data to pull matching subsets or to summarize it,

Actors

Board member

Assumptions

Only a select group of people need access to report donor data.

The donor data will always be a manageable size for export.

A web interface is suitable for remote access the donor data.

Frequency

A few times a week both scheduled and on demand.

Standard Scenario

The Board member has loaded the private donor logon page.

The Board member logs on.

[Alternate failed authentication scenario].

The Board member selects 'Reports'.

The Board member selects en existing report or 'New'.

The Board member provides some parameter data to restrict the report to the desired subset, or a whole new query.

[Use case Query donor database].

[Alternate failed query scenario].

The browser displays a table of the donor data.

The donor may choose to save the data in a portable format.

The Browser prompts the Board member to save the data to file.

Alternate failed authentication

The Board member's credentials were rejected

The Board member corrects his credentials.

If the credentials are correct, the Board member aborts.

The Board member submits the revised credentials.

Alternate failed report scenario

The database connection or query fails.

Set the failed report message.

A fail response is returned to indicate why the query failed.

Included Use Cases

Query donor database.

Extended Use Case

None.

Issues

What formats are needed for portability, Tab delimited, some XML grammar?

Setting up an OpenOffice data source may be a viable alternative to a Web interface

Decisions

None.

Illustration 10 Report sequence

Illustration 11 Report activity

2004-01-17T11:53:35