Collegiate Sports Paging System

Use Case Specification: Approve Story

Version 2.0

Revision History

Date

Version

Description

Author

October 9, 1999 1.0 Initial version Context Integration
December 1, 1999 2.0 Update with detail from Elaboration Context Integration
Table of Contents

Approve Story Top of page

Brief Description

This Use Case takes place when an editor approves a story for inclusion in the Collegiate Sports Paging System. Some stories will automatically propagate from the existing system, but some stories will require editor intervention (either because their subject is not clear or the categories to which the story belongs are not clear). This flow is also used to approve advertising content being posted.

Flow of Events Top of page

Basic Flow

  1. The system places a story in the editor's "to-do" workflow queue. If more than one editor is defined, a round-robin approach is used to attempt to balance load.   Editors may be marked as unavailable (if, for instance, they are on vacation or sick or out of the office), in which case they will not be included in the round-robin process.
  2. The editor views the story.
  3. The editor categorizes the story by selecting from system-provided categories.   There may be more than one category assigned to the story.  At least one category must be assigned to the story.
  4. The editor then marks the story as approved.
  5. The system includes the story in the list of available content for paging initiation.
  6. The system triggers initiation of paging messages.

Alternate Flows

  1. Reject Content
    1. The editor views the story.
    2. The editor marks the story as rejected and describes the reason for rejection.
    3. The system notifies the originator of the content that the story has been rejected and includes the reason provided by the editor.
    4. The system deletes the story.
  2. Modify Content
    1. Editor selects "Modify Story"
    2. System displays titles of all stories available
    3. Editor selects specific title
    4. System displays characteristics of story
    5. Editor updates characteristics, either deleting some categories, adding other categories, or both.
    6. Editor selects "Save"
    7. System re-posts the story to the list of available content for paging initiation.
    8. The system triggers initiation of paging messages.
  3. Approve Advertising Content
    1. The editor views the advertising content
    2. The editor marks it approved.
    3. The system includes the advertising content in the list of available advertising for display
    4. The system creates a preliminary billing record, using information stored about the advertiser (billing rate indicator, advertiser name and billing address), content identification, date, and total due.
    5. The system marks the preliminary billing record as approved
  4. Reject Advertising Content
    1. The editor views the advertising content
    2. The editor marks it rejected and provides a reason for rejection. This may include account overdue, content inappropriate or not within scope of contract, or duplicate content (advertising content is already on file and being displayed).
    3. The system notifies the advertiser (via email) of the rejection and the reason.
    4. The system deletes the content.
  5. Story not viewable
  6. If the story has been deleted by another editor and is not currently viewable, the use case terminates.

Special Requirements Top of page

None.

Preconditions Top of page

Editor must be logged in.

Postconditions Top of page

When this use case is complete, content is available. For advertising content, the content will be eligible for display immediately. For story content, the paging process can begin immediately.

Extension Points Top of page

None.

Copyright  1987 - 2003 Rational Software Corporation