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.
Group management system functional requirements: Difference between revisions
Grans Remedy (talk | contribs) mNo edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
{{ | {{Specification}} | ||
The functional requirements for the Group Management System will be detailed in the following sections with [http://en.wikipedia.org/wiki/Use_case Use Cases] and other [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML] models. | The functional requirements for the Group Management System will be detailed in the following sections with [http://en.wikipedia.org/wiki/Use_case Use Cases] and other [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML] models. | ||
| Line 48: | Line 48: | ||
[[GMS Detailed Design]] | [[GMS Detailed Design]] | ||
[[:Category:Group Manager]] | |||
Revision as of 07:57, 10 February 2013
|
This page contains a specification 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. |
The functional requirements for the Group Management System will be detailed in the following sections with Use Cases and other UML models.
Actors
An actor is a representation of a role performed when interacting with the system.
Use Case Overview
This overview shows the use cases able to be completed by each actor. It describes which types of actors will be able to carry out specific tasks or objectives supported by the system.
Use Cases
Use Cases describe the functional requirements of the system from the end users perspective, where each use case is a goal or purpose the user has in using the system.
1. Register Group Namespace
2. View Groups
3. Join Group
4. Search for Groups
5. Update Membership Request
6. Assign User to Group
7. Remove User from Group
8. Assign Group Manager
9. Remove Group Manager
10. Create Group
11. Change Group
12. Delete Group
13. Assign co-founder
14. Remove co-founder
15. Verify Player
16. Get Player Groups
17. Make System Change
Architecture
The proposed architecture for the Group Management System follows the proven 3-tier model, with the separation of concerns of presentation, application logic and data access.
Detailed Design
The detailed design will be modelled with UML Sequence diagrams for each Use Case, showing a view of participating classes and the messages sent to each class. A class model of the database schema will detail the physical table structure, and show the proposed integration with the BZFlag forum database for user management.
Note: this integration is needed to provide a 'single-sign-on' to the Group Management System, where a registered player will not need a separate set of credentials to use the GMS.