Skip to content

Instantly share code, notes, and snippets.

@sarmis
Last active May 7, 2019 13:28
Show Gist options
  • Save sarmis/a9b0086a36d98f0fd6261c1aaf109d0c to your computer and use it in GitHub Desktop.
Save sarmis/a9b0086a36d98f0fd6261c1aaf109d0c to your computer and use it in GitHub Desktop.
Project Specifications Management

1. Introduction

2. Definitions

EGM : Electronic Gaming Machine

3. Appearance

3.1 Cabinet Appearance

3.2 Game Selection Screen

3.3 Touchpanel

3.4 Console (System Management)

3.5 Generic Game

3.6 Promo Screen

Functionality

EGM States


DISABLED STATE is a recoverable state, where the gaming machine and especially the user-facing gaming functionality is disabled.
LOCK(AFT) STATE
PAUSE STATE is a temporary state where the game does not start new game round (even if in auto) (for displaying something else...)

Power On
    [mrxzwnuf] EGM must start upon turning the main power switch to "On"
    [zdscnyvr] EGM must run integrity tests after every start-up and before making the machine available for gaming
    [jazioxdf] EGM must present an non-recoverable error screen if integrity checks fail
    [safcmhjr] EGM must provide & respect option for starting in DISABLED STATE                
    [phztobxv] EGM must present a recoverable error screen if is in DISABLED STATE
    [orqkzdxc] EGM must present the "Game Selection Screen" after boot if not in DISABLED STATE

Gaming

    Game Selection

        [nlrcmoha] "Game Selection Screen" must offer the UI/UX for selecting one of the readily available games 
        [ilyobpez] If only one game is available, it must be started automatically upon completing the power-on procedure 

    Bet Selection

    Game Round

        Starting a new game round

        Rebetting

    4.2.4 Game Termination

    4.2.5 Game Resume After Power Failure

4.3 Monetery Transactions

4.4 External Events

5. Error Handling

Project Specification Managemt

1. Introduction

Provide a way to manage living project spefications

2. Considerations

Considerations Regarding the suggested solution

2.1. KISS (Keep it stupid-simple)

Simple tools will allow for a more robust

2.1.1. (Almost) plain text editor

VS Code is the preferred editor due to markdown support (esp. folding)

2.1.2. No required compilation steps

Markdown files are readable without compilation

3. Definitions (for specifications management)

3.1. Definitions

Specification : An item descibing a requiremt of the project

Specification Title : A descriptive sentence of the requirement

Specification Id : An immutable, globally unique id, consisting of dot-separated numbers (ie: 2.1.1.5)

Specification Content : Any other information regarding the specification (extended description, examples, etc)

Specifications Group : A container for related specifications of related specifications groups.

Group Title : A descriptive sentence of the group

Group Id : An immutable, globally unique id, consisting of dot-separated numbers (ie: 2.1.1.5)

Group Content : Any other information regarding the specification (extended description, examples, etc)

Group Childs : The groups or requiremets that belong direcly to this group

(Item) Level : The "depth" of an item (specification or group) in the group tree, items that do not belong to a group have level equal to 0.

(Item) Level Indicator : A sequence of '#' equal to the items level + 1 (Usefull for folding in vs code and headers/anchors in html)

(Item) Header : A line consisting of the item's level indicator, item's id and item's title seperated by spaces

4. Specifications

3.2. Specification will be recorded in plain text files (using markdown) inside project directory

In project root a doc folder will contain the specs.md which will be the entry point for the project's spefications, all other files will reside in doc/specs/

3.3. Specifications can be grouped.

3.4. Each item (specification or group) will have a unique id consisting of dot seperated numbers, following the multilevel ordered list convensions

Example
1. first group
1.1. first item of first group
1.1.1. first sub-item of first item of first group
1.2. second item of first group

2. second group
2.1. first item of second group
2.2. second item of second group

3.5. Specifications should should adhere to the format: ##### unique id

3.5.1. Specification level and thus group is denoted by the number of '#' in the beggingin of the line.

3.5.2. Specifications may contain explanative text as plain text below the

3.5. Unique ids should be immutable and not re-used.

3.5.1. Ids of deleted specifications should not be used.

It is acceptable to leave the spec title emty

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment