Concern requirements list using MDSOCRE notation. Here we show how the concrete concerns of our domain are expressed with the MDSOCRE approach. 

<code xml>
<Concern name="Game">
 <Requirement id="1"> A slot machines have 5 reels.</Requirement>
 <Requirement id="2"> Reels spin when play button is pressed.</Requirement>
 <Requirement id="3"> Prizes are awarded according to a pay table. </Requirement>
 <Requirement id="4"> A slot machine has  one or more devices for entering money.</Requirement>
 <Requirement id="5"> As money is inserted credits are "assigned" to the player. </Requirement>
 <Requirement id="6"> A slot machine must provide means for cashing the credits out.
              It could be a ticket printer, a coin hopper.</Requirement>
</Concern>

<Concern name="Meters">
 <Requirement id="1"> Credit meter: shall at all times indicate all credits or cash 
             available for the player to wager or cashout  (GLI 11 4.10.1)  </Requirement>
 <Requirement id="2"> Credit Meter Incrementing: The value of every prize (at
             the end of a game) shall be added to the player's credit meter. The 
             credit meter shall also increment with the value of all valid coins, tokens, 
             bills, Ticket/Vouchers, coupons or other approved notes accepted. (GLI 11 4.10.5) </Requirement>
 <Requirement id="3"> Accounting Meters (GLI 11 4.10.9):  Coin In: a meter that
             accumulates the total value of all wagers [...]. Games-played: accumulates
             the number of games played; since power reset, since door close and 
             since game initialisation. </Requirement>
 <Requirement id="4"> Meters should be updated upon occurrence of any event 
             that must be counted, including: play, cashout, bill in, coin in.  </Requirement>
</Concern>


<Concern name="Game Recall">
 <Requirement id="1"> Information on at least the last ten (10) games is to be 
             always retrievable on the  operation of a suitable external key-switch, 
             or another secure method that is not available to  the player. </Requirement>
 <Requirement id="2"> Last play information shall provide all information 
             required to fully reconstruct the last ten (10) plays. All values shall be 
             displayed; including the initial credits, credits bet, and credits won, 
             payline symbol combinations and credits paid whether the outcome 
             resulted in a win or loss. This information should include the final game
             outcome, including all player choices and  bonus features. </Requirement>
</Concern>

<Concern name="G2S">
 <Requirement id="1"> The  G2S protocol is designed to communicate 
              information between a SM, and one or more host systems. </Requirement>
 <Requirement id="2"> Meters within the G2S protocol: Each device is metered 
             separately. Meters are always available on a device-by-device basis.
              (G2S  1.16) </Requirement>
 <Requirement id="3"> Some G2S meters are: gamesSinceInitCn Number of 
              games since initialisation. WonCnt: Number of primary games won 
              by the player. LostCnt: Number of primary games lost by the player </Requirement> 
 <Requirement id="4"> Important events must be reported in real-time, including: 
             error conditions, tickets inserted, ticket printed.</Requirement>
</Concern>

<Concern name="Proprietary Communication Protocol">
 <Requirement id="1"> The PCP  communicates a SM with a host system. </Requirement>
 <Requirement id="2"> It must report all meters of a SM. </Requirement>
 <Requirement id="3"> Important events must be reported in real-time, including: 
             error conditions, tickets inserted, ticket printed.</Requirement>
</Concern>

<Concern name="Program Resumption">
 <Requirement id="1"> After a program interruption (e.g., processor reset), the 
             software shall be able to recover to the state it was in immediately prior 
             to the interruption occurring.  </Requirement>
 <Requirement id="2"> Restoring Power. If a gaming device is powered down 
             while in an error condition, then upon restoring power, the specific error
             message shall still be displayed and the gaming device shall remain 
             locked-up. </Requirement>
 <Requirement id="3"> A SM must store all meter information in persistent 
             memory. (G2S  1.16) </Requirement>
</Concern>
 
<Concern name="Error Conditions">
 <Requirement id="1"> Gaming devices shall be capable of detecting and 
              displaying error conditions and illuminate the tower light for each
              or sound an audible alarm. </Requirement>
 <Requirement id="2"> Error conditions should cause the gaming device to
             lock up and require attendant intervention. Error conditions shall be 
             cleared either by an attendant or upon initiation of a new play 
             sequence after the error has cleared except for those deemed as
             a critical error.</Requirement>
 <Requirement id="3"> Error conditions are: coin jam, reverse coin in, stacker
             full, bill jam, external doors open. </Requirement>
 <Requirement id="4"> Video based games shall display meaningful text as to 
             the error  conditions. </Requirement>
 <Requirement id="5"> Error conditions shall be communicated to an on-line 
             monitoring and  control system when this is available. </Requirement>
</Concern>

<Concern name=" Demo Mode">
<Requirement id="1"> The Slot Machine must permit a a test, diagnostic or demo
             mode, which permits             gaming device (e.g.,  a hopper test) shall be completed on 
             resumption of normal operation.
<Requirement id="1.1"> If the gaming device is in a test, diagnostic or demo
             mode, any test that incorporates credits entering or leaving the 
             gaming device (e.g.,  a hopper test) shall be completed on 
             resumption of normal operation.</Requirement>
<Requirement id="1.2"> There shall not be any mode other than 
             normal operation (ready for play) that increments any of 
             the electronic meters.</Requirement>
<Requirement id="1.3">  Any credits on the gaming device that
             were accrued during the test, diagnostic or demo mode shall be 
             automatically cleared before the mode is exited. </Requirement>
<Requirement id="1.4"> Specific meters are permissible for these types of 
             modes provided the meters indicate as such (GLI 11 4.17.1). </Requirement>
</Requirement>
<Requirement id="1.5"> The main cabinet door of the gaming device may 
             automatically place the gaming device in a service or test/diagnostic 
             mode. Test/diagnostics mode may also be entered, via an appropriate 
             instruction, from an attendant during an audit mode access. These 
             modes should not be accessible to the player (GLI 11 4.17.2). </Requirement>
<Requirement id="1.6">  When exiting from test-diagnostic mode, the game 
             shall return to the original state it was in when the test mode was 
             entered (GLI 11 4.17.3). </Requirement>
<Requirement id="1.7"> Test Games. If the device is in a game test mode,
             the machine shall clearly indicate that it is in a test mode, not normal 
             play (GLI 11 4.17.4). </Requirement>
</Concern>

</code>




==== Composition rules ====

Composition rules are used to express crosscutting relationships. Here we show the
composition rules, consisting of a Constraint tag that defines how the
base requirements are constrained by aspectual requirements. The Constraint
tag has actions, operators and outcome elements, used to express in detail
how the base is affected.

1. Demo to Game: The demo requirements affect many of the definitions of the original requirements of Game, in order to alter the Game's behaviour for testing purposes.

<code xml>
<Composition>
 <Requirement concern="Demo Mode" id="all">
  <Constraint action="enforce" operator="on"> 
   <Requirement concern="Game" id="all" />  
  </Constraint>
  <Constraint action="exclude" operator="on"> 
   <Requirement concern="Game" id="1" />  
   <Requirement concern="Game" id="2" />  
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>

2. Game Recall to Game: Game Recall requirements affect many aspects of the Game's behaviour, its requirements call for recording pieces of information regarding game play.

<code xml>
<Composition>
 <Requirement concern="Game Recall" id="2">
  <Constraint action="enforce" operator="on"> 
   <Requirement concern="Game" id="2" />  
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>

3.Meters to Game: Meters count activities of many functions defined in  Game's requirements, for instance: game play, bill in, cashout, etc.

and 

10.Dependency of G2S on Meters: Some data reported to the RS  is stored or can be derived from meters. G2S needs the meters to be up to date in order to accomplish its purpose.

<code xml>
<Composition>
 <Requirement concern="Meters" id="4">
  <Constraint action="enforce" operator="on"> 
   <Requirement concern="Game" id="3" /> 
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
 <Requirement concern="Meters" id="3">
  <Constraint action="ensure" operator="with">
   <Requirement concern="G2S" id="2"/> 
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>


4.Program resumption to Game. Program resumption is analogous to persistence. It crosscuts all the places where important data, which needs to be restored,  is changed. 

<code xml>
<Composition>
 <Requirement concern="Program Resumption" id="1">
  <Constraint action="enforce" operator="on"> 
   <Requirement concern="Game" id="2" />  
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>

5.G2S to Game: this concern cut across many Game's requirements, since several events in  Game need to be reported, monitored and communicated to reporting system.

<code xml>
<Composition>
 <Requirement concern="G2S" id="4">
  <Constraint action="enforce" operator="on"> 
   <Requirement concern="Game" id="2" />  
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>

6.Error Conditions to Game:  Requirements in Game that could raise an error condition vary: from a bill inserted to a door opened.

<code xml>
<Composition>
 <Requirement concern="Error Condition " id="3">
  <Constraint action="enforce" operator="on"> 
   <Requirement concern="Game" id="2" />  
  </Constraint>
  <Outcome action="satisfied">
   <Requirement concern=" Error Condition" id="2"/> 
  <Outcome/>
 </Requirement>
</Composition>
</code>

7.Proprietary Protocol to Game: This refers to another protocol used for the same purpose as G2S, that is to monitor the game's behaviour.

<code xml>
<Composition>
 <Requirement concern="Proprietary Communication Protocol" id="1">
  <Constraint action="enforce" operator="on"> 
   <Requirement concern="Game" id="2" />  
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>


11.Mutex between G2S and Proprietary Protocol: There is overlapping functionality defined in the requirements of both protocols and they cannot be active at the same time.

<code xml>
<Composition>
 <Requirement concern="Proprietary Communication Protocol" id="all">
  <Constraint action="XOR" operator="with"> 
   <Requirement concern="G2S" id="all" />  
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>

12.Reinforcement of G2S with Error Conditions: Some parts of the G2S protocol are not mandatory for specific instances. When error conditions are tracked in the game, additional behaviour is made available in G2S, such as real time event reporting.

<code xml>
<Composition>
 <Requirement concern="Error Condition" id="3">
  <Constraint action="provide" operator="for"> 
   <Requirement concern="G2S" id="4"/> 
  </Constraint>
  <Outcome action="fulfilled"/>
 </Requirement>
</Composition>
</code>