Skip to Content
0 Votes

Functional and Nonfunctional Requirements Specifications

Last modified by Doug McCord on 2023/06/18 11:01

Introduction

  1. Statement of Purpose

The goal of the Role-Playing Game Consent Application is to provide players of role-playing games an anonymous way to submit their consent, potential discomfort or opposition to a gamemaster in real-time, during gameplay (see definitions below).

This application should make use of mobile technology to be available as a downloadable app, and also be available as a webpage. It should be open source, simple to use and provide anonymous communication to a Consent Group Manager from a group of Participants in the form of a stoplight metaphor with three color options: green, yellow and red.

  1. Definitions and Abbreviations

 

Term

Definition

 

Consent Group

 

The Consent Group refers to those users of the Role-Playing Game Consent Application who are all accessing the application using the same Consent Group Code, to either send consent status notifications (for Participants, or PCs) or receive consent status notifications (for the Consent Manager, or CM). In the context of a role-playing game, this might be a single game session’s gamemaster and all of its players, for example.

 

 

Consent Group Code

 

A unique code that allows a Participants (PC) to join a Consent Group with a single Consent Manager (CM) and other Participants (PCs). These codes are generated and distributed by the Consent Manager (CM).

 

 

Consent Manger (CM)

 

The Consent Manager (or CM) refers to the one user per Consent Group that receives all consent notifications (anonymously) from that Consent Group’s Participants (or PCs). While a CM may or may not also be a role-playing game’s gamemaster (or GM), there may only be one CM per Consent Group. Note that this role also generates Consent Group Codes and is responsible for distributing them to invited Participants (PCs).

 

 

Gamemaster (GM)

 

Here used to refer to a role-playing game participant that serves as the game organizer and primary facilitator, often relaying and controlling aspects of the game world which don’t include the players themselves and their actions. Often compared to a storyteller, in the game Dungeons & Dragons this role is called a “Dungeon Master” (or DM), for example.

 

Open Source

 

Used here to refer to code, or text written in a programming language, that is made freely available for others to utilize and/or modify.

 

 

Participant with Consent (PC)

 

In this context, the abbreviation ‘PC’ refers to application users in the role of Participant with Consent. While these may or may not also be a role-playing game’s players (which may also be known as ‘PC’ or player character in gaming), in the application, members with this role join a Consent Group with a provided Consent Group Code and may only see their own consent status. Defaulting to green, this status may be changed to yellow or red to notify a Consent Manger (or CM) in the Consent Group that the PC is uncomfortable or opposed to game activities.

 

 

Player

 

Here used to refer to role-playing game participants who control single or multiple characters within a game, but not the game world or storyline otherwise. Typically, role-playing games consist of a single gamemaster and multiple players. Note that this is sometimes also known as a player character.

 

 

Role-Playing Game

 

A game wherein players take on the roles of separate characters within a fictionalized game world. Note that these games may take many forms, such as with tabletop games (such as with pencils, paper and dice), video or electronic games (such as on a gaming console or computer) or live-action gaming involving movement in the world and costumes.

 

  1. Expected Users

The Role-Playing Consent Application will be free and open source, with expected users being players and gamemasters of role-playing games of all kinds, as well as potentially other gamers (such as video gamers or for other tabletop game types), or members of any organization who wish to share consent anonymously in real time from team members to a single organizer or team manager.

  1. Scope Limitations and Preconditions

This application will be developed and tested to run on the following currently active web browsers only: Firefox, Chrome, Safari and Edge. The application will be developed and tested to run on IOS and Android mobile devices available at the time of release. While simple help documentation may be provided in-app, the application itself will not educate users fully on its use and end goals.

The Consent Manager is responsible for distributing Consent Group Codes to potential users. The application does not provide a means of automatically distributing these codes or searching out potential users.

  1. Workflow

{Diagram/s here}

Functional Requirements

  1. Business Requirements

  1. The application must have two user modes: Consent Manager (CM) Mode and Participant with Consent (PC) Mode. (F1)

    1. The CM Mode must:
      1. Allow for the generation of unique Consent Group Codes as part of creating a new Consent Group. Each group will have its own, unique code. (F2)
      2. Allow for up to five different Consent Groups to exist concurrently for a single CM. (F3)
      3. Allow for the deletion or removal of an existing Consent Group. This requires an additional step of verification from the CM, to prevent accidental removals. (F4)
      4. Allow for the entry to and exit from each Consent Group individually in the interface. The status indicators should not be visible outside of the Consent Group. (F5)
      5. Within each Consent Group in CM Mode, the application must:
        1. Display the number of users currently registered to this Consent Group. (F6)
        2. Display the consent status indicator for the Consent Group consisting of three possible options: red, yellow or green. (F7)
        3. Allow the CM to set the Consent Group status back to green. (F8)
        4. Allow the CM to set a text name for each Consent group. This name is for display purposes only and is shared with a Consent Group’s PCs. (F9)
    2. The PC mode of the application must:
      1. Allow users to join an existing Consent Group by entering a Consent Group Code. (F9)
      2. Allow for up to five different Consent Groups to exist concurrently as PC. (F10)
      3. Allow entry to and exit from each joined Consent Group individually, one at a time. (F11)
      4. Provide a message for any Consent Group that the PC was a member of that’s been deleted by the CM. (F12)
      5. Within each Consent Group in PC Mode, the application must:
        1. Display the Consent Group name as set by the CM. (F13)
        2. Display the PC’s current status as one of three possible color options: red, yellow or green. (F14)
        3. Allow the PC to change their current status by choosing one of the other two status options. (F15)
        4. Provide the PC visual feedback for any status change that has reached the CM. (F16)
        5. Provide the PC visual feedback when the CM resets the Consent Group status color back to green if this PC submitted a changed status level. (F17)
        6. Allow for the quitting from an existing Consent Group, with a verification provided prior to final submission. (F18)

Nonfunctional Requirements

  1. Access Requirements

    1. The Role-Playing Game Consent Application must support the following accessibility options:
      1. Single key/input selection option (touch alternative). (N1)
      2. High contrast color scheme. (N2)
      3. Text zoom. (N3)
    2. Only users who have entered a unique Consent Group Code may be allowed to send a consent status update to that group’s CM. It must not be possible for other outsider users to see these indicator updates or the Consent Group status code without first joining a Consent Group with a Consent Group Code. (N4)

     

  2. Performance Requirements

    1. The Role-Playing Game Consent Application must be able to run on currently available IOS and Android mobile phones as downloaded from the Apple App Store and the Google Play app store. (N5)
    2. The Role-Playing Game Consent Application must be able to run on currently available IOS and Android tablets as downloaded from an app store. (N6)
    3. The Role-Playing Game Consent Application must be able to run on the following available web browsers in their release versions dating from January 2021 to the time of release: Firefox, Chrome, Safari and Edge. (N7)
    4. The application must load on all of the above formats with minimal wait times. (N8)
    5. Status updates within a Consent Group must move from PC to CM, with visual feedback sent back to PC within ten seconds where a viable internet connection exists. (N9)

  1. Support Requirements

    1. The Role-Playing Game Consent Application must offer simple, built-in help text. (N10)
    2. The Role-Playing Game Consent Application must be able to refer users to link to online resources, such as FAQ or help sites. (N11)

  1. Miscellaneous Application Requirements

    None.

Use Cases (TBD)

  1. User Use Cases

    1.  

    Use Case 1:


      1.  

    Name:


      1.  

    Overview:


      1.  

    Actors:


      1.  

    Preconditions:


      1.  

    Postconditions:


      1.  

    Flow of Events:



        1.  

     

  1. Support Use Cases