**Collegiate Sports Paging System

Use Case Specification: Approve Story**

Version 2.0

Revision History

Table of Contents

• [Approve Story](#Approve Story)
• [Flow of Events](#Flow of Events)
• [Special Requirements](#Special Requirements)
• Preconditions
• Postconditions
• [Extension Points](#Extension Points)

Approve Story

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 propogate 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

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

2. The editor views the story.

3. The editor marks the story as rejected and describes the reason for rejection.

4. The system notifies the originator of the content that the story has been rejected and includes the reason provided by the editor.

5. The system deletes the story.

6. Modify Content

7. Editor selects “Modify Story”

8. System displays titles of all stories available

9. Editor selects specific title

10. System displays characteristics of story

11. Editor updates characteristics, either deleting some categories, adding other categories, or both.

12. Editor selects “Save”

13. System re-posts the story to the list of available content for paging initiation.

14. The system triggers initiation of paging messages.

15. Approve Advertising Content

16. The editor views the advertising content

17. The editor marks it approved.

18. The system includes the advertising content in the list of available advertising for display

19. 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.

20. The system marks the preliminary billing record as approved

21. Reject Advertising Content

22. The editor views the advertising content

23. 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).

24. The system notifies the advertiser (via email) of the rejection and the reason.

25. The system deletes the content.

26. Story not viewable

If the story has been deleted by another editor and is not currently viewable, the use case terminates.

Special Requirements

None.

Preconditions

Editor must be logged in.

Postconditions

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

None.