This wiki was in read-only mode for many years, but can now be edited again. A lot of information will need to be updated.
Join Group: Difference between revisions
Grans Remedy (talk | contribs) |
Grans Remedy (talk | contribs) mNo edit summary |
||
| Line 7: | Line 7: | ||
The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype). | The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype). | ||
== Pre-conditions == | == Pre-conditions == | ||
| Line 14: | Line 15: | ||
== Post conditions == | == Post conditions == | ||
The actor has joined a player group or requested membership in a group. | The actor has joined a player group or requested membership in a group. | ||
== Included use cases == | |||
[[Search for Groups]] | |||
== Extension use cases == | |||
[[Request Membership]] | |||
== Requirements and rules realized == | == Requirements and rules realized == | ||
| Line 36: | Line 46: | ||
* ''BR7 Alert managers of membership requests'' | * ''BR7 Alert managers of membership requests'' | ||
The system shall notify group managers of a membership request for a group they manage. | The system shall notify group managers of a membership request for a group they manage. | ||
== Flow of events == | == Flow of events == | ||
| Line 41: | Line 52: | ||
[[Image:Activity_Join_Group.png|Activity diagram showing flow of events]] | [[Image:Activity_Join_Group.png|Activity diagram showing flow of events]] | ||
== Messages == | == Messages == | ||
Revision as of 08:37, 18 April 2011
|
This page contains the design document for an enhancement or feature. It is a work of collaborative development, and may not represent the final design. If you are not part of the development or design group, please post comments and suggestions on the talk page and not in the middle of the design. |
Introduction
This use case describes the process a player will use to join a group. Some groups permit anyone to join them, others require that a request be approved by one of the groups managers (or founders).
The diagram shows the requirements and rules the use case is responsible for (via the <<requirement>> stereotype).
Pre-conditions
None
Post conditions
The actor has joined a player group or requested membership in a group.
Included use cases
Extension use cases
Requirements and rules realized
- RQ10 Private groups are always closed
The system shall prevent the actor from joining a private group.
- RQ8 Groups have a membership policy
A groups membership policy determines whether a player can join the group or not.
- BR4 Open groups
The system shall enable any player to join a public group with an open membership policy.
- BR5 By Request groups
The system shall enable any player to request membership of a public group with a by-request membership policy.
- BR6 Closed groups
The system shall prevent any player from joining, or requesting to join, a public group with a closed membership policy.
- RQ11 Track the status of membership requests
The system shall store and track the status of membership requests.
- BR7 Alert managers of membership requests
The system shall notify group managers of a membership request for a group they manage.
Flow of events
The flow of events describes the main actor actions and system responses in the execution of the use case.
Messages
<properties> Step:= EX-1 Condition:= No group found Message Number:= Err 1 Message Text:= No group with that name was found. </properties>
<properties> Step:= BF-9 Condition:= Player added to group Message Number:= Msg 4 Message Text:= You were successfully added to the group <<group name>>. </properties>