This wiki is archived and useful information is being migrated to the main bzflag.org website

Difference between revisions of "Group management system functional requirements"

From BZFlagWiki
Jump to: navigation, search
(category link)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{DesignDocument}}
+
{{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 17: Line 17:
 
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.
 
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]]
+
1. [[Register Group Namespace]]<br />
 +
2. [[View Groups]]<br />
 +
3. [[Join Group]] <br />
 +
4. [[Search for Groups]] <br />
 +
5. [[Update Membership Request]] <br />
 +
6. [[Assign User to Group]] <br />
 +
7. [[Remove User from Group]] <br />
 +
8. [[Assign Group Manager]] <br />
 +
9. [[Remove Group Manager]] <br />
 +
10. [[Create Group]] <br />
 +
11. [[Change Group]] <br />
 +
12. [[Delete Group]] <br />
 +
13. [[Assign co-founder]] <br />
 +
14. [[Remove co-founder]] <br />
 +
15. [[Verify Player]] <br />
 +
16. [[Get Player Groups]] <br />
 +
17. [[Make System Change]] <br />
 +
 
 +
 
 +
== 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.
 +
 
 +
[[GMS Architecture]]
 +
 
 +
 
 +
== 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.
 +
 
 +
[[GMS Detailed Design]]
 +
 
 +
[[Category:Group Manager]]

Latest revision as of 03:04, 5 December 2016

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.


Actors[edit]

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


Architecture[edit]

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