Group management system functional requirements

From BZFlagWiki
Revision as of 03:04, 5 December 2016 by Zehra (Talk | contribs) (category link)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
Picture Frame.png 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.


An actor is a representation of a role performed when interacting with the system.

Description of actors of the group management system

Use Case Overview[edit]

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[edit]

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


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.

GMS Architecture

Detailed Design[edit]

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.

GMS Detailed Design