NG Design Document/Use Cases
From Rex community wiki
Use Case
A use case is a scenario-based way of capturing a system's behavior when driven by events from outside the system. Most often the primary outside actor is the user of the system.
The purpose of a use case is to help collect requirements for a system in an intuitive manner, stories or scenarios, that capture the essence of what is expected of the system from an outside perspective.
Having the cases in story form allows us to focus the discussion about requirements to real-world situations that provide examples that can tested against.
Targeted Classes of Users
While our software is multi-use, that doesn't mean we aren't aiming
for certain classes of uses.
Professional Game Engine
- First-person style action or role-playing games
- Vehicle driving games
- Single-player or Online games
- Massively Multiplayer Online games
Educational Games
- Physical puzzles
- Simple simulations
- Social engineering games
- Language learning
Scientific Education
- Low-end simulation of physical processes
- Visualization of scientific data
Industrial Prototyping
- Importing industrial designs
- Intuitive visualization of and interaction with virtual prototypes
Business
- Virtual meetings
- Document sharing and collaboration
Telecommunications
- Virtual meetings
- Hosting and Service
- Providing value-add applications to drive network usage
Nomenclature
For the purpose of these Use Cases, we will refer the Client Viewer Agent, as User Agent, or just Agent.
Template Format
Use Case Template
| Use case name
| A simple way of identifying the use case in a short verb-noun phrase
|
| Goal
| Without a goal a use case is useless.
|
| Summary
| A summary section is used to capture the essence of a use case before the main body is complete.
|
| Actors
| An actor is someone or something outside the system that either acts on the system – a primary actor – or is acted on by the system – a secondary actor.
|
| Preconditions
| A preconditions section defines all the conditions that must be true (i.e., describes the state of the system) for the trigger (see below) to meaningfully cause the initiation of the use case.
|
| Triggers
| A 'triggers' section describes the event that causes the use case to be initiated. This event can be external, temporal or internal.
|
| Basic path
|
- The main basic course of events is often conveyed as a set of usually numbered steps.
- Usually the "best case" scenario.
|
| Alternative paths
| Use cases may contain secondary paths or alternative scenarios, which are variations on the main theme.
|
| Exceptional paths
| Scenarios where the "worst case" has occurred and must be handled.
|
| Postconditions
| The post-conditions section describes what the change in state of the system will be after the use case completes.
|
|
