COMP2110 Software Design in 2004 lecture 4 Requirements Specifications lecture 2 of 3

1
COMP2110 Software Design in 2004 lecture 4
Requirements Specifications lecture 2 of
3

• The Encounter game case study
• introduction to the Problem the Encounter Game
• examples from the specification document
• first hints about the process of discovering
  requirements

2
The Software Requirements Specification SRS

• The product of the Analysis phase isa well
  defined information model
• a set of labelled, organised requirements
  statements
• functional consumer and developer requirements
• system requirements
• performance requirements
• a set of use cases or scenariosthat capture and
  express the relationships between the model and
  the real world of the problem
• other explanatory models
• interfaces, states, decisions

3
A Case Study of Encounter Overview (1)

• An overview of the Specification of the Encounter
  video game
• Specification document comes in 2 parts
• http//cs.anu.edu.au/student/comp2110/resource
  s/ Encounter-SRS/EncounterSRS-1.html
• and ...
• EncounterSRS-1.html
• you need to study this to prepare for tutorials
  this week (2)

4
A Case Study of Encounter Overview (2)

• The Encounter game is
• a computer based role playing game which
  simulates all or part of the lifetime of the
  players character
• includes characters not under players control,
  called foreign chacters
• game characters have a number of qualities
  strength, speed, patience etc
• each quality has a numerical values
• the game is played over a map of areas (rooms)
• characters engage each other when in the same
  area
• the result of an engagement depends on the area
  and the values of the qualities of the two
  characters
• success is measured by living as long as possible
  with accumulated points

5
Sample Encounter Screen
kitchen
COURTYARD
living room
dressing room
Graphics reproduced with permission from Corel.
6
(No Transcript)
7
image
8
Image
The values of the qualities not specifically
chosen remain in the same proportion to each
other. Values less than 1.0 are counted as zero.
E.g., before strength 10.0, endurance
60.0, intelligence 30.0, patience 0.0
(current life points 10.0 60.0 30.0 0
100.0) change strength from 10.0 to 20.0 after
strength 20, endurance 53.33, intelligence
26.66
Graphics reproduced with permission from Corel.
9
2. Player requests a window for setting his
characters qualities.

10
Engage Foreign Character Use Case
Details of use case
player
Actor (agency external to the application)
Name of use case
11
A use case expressed in text

• 2.2.3 "Engage Foreign character" use case
• Actor player of Encounter
• 1. System displays the foreign character into the
  same area as the player
• 2. System exchanges data between the two
  characters
• 3. System displays the results of the engagement
  in a message window.
• 4. Player dismisses window.

12
A use case expressed in improved text

• 2.2.3 "Engage Encounter Foreign character" use
  case
• Actor player of Encounter
• 1. System displays the moves a foreign character
  into the same area as area occupied by the
  playeror Player moves into the area containing a
  foreign character.
• 2. System exchanges data between the two
  characters causes the two characters to engage.
• 3. System displays the results of the engagement
  in a message window.
• 4. Player dismisses window.
• 4. If either the player's character or the
  foreign character has no points, the game
  terminates or else
• 5. System moves the player's character to a
  random area different from that in which the
  encounter took place, and displays it there.

13
A use case expressed in text - and refined

• 2.2.3 "Encounter Foreign character" use case
• Actor player of Encounter
• 1. System moves a foreign character into the
  area occupied by the playeror Player moves into
  the area containing a foreign character.
• 2. System causes the two characters to engage.
• 3. System displays the results of the engagement
• 4. If either the player's character or the
  foreign character has no points, the game
  terminates or else
• 5. System moves the player's character to a
  random area different from that in which the
  encounter took place, and displays it there.

14
Sequence Diagram for Engage Foreign Character Use
Case
1.1 create display
1.2 create
2.1 execute
15
From Sequence diagrams to Domain classes (1)

• these sequence diagrams are figures 13.22, 13.23,
  13.24 in Braude SD (with some changes)
• use cases are a beginning point for requirements
  and analysis
• alternatives include scenarios, event-action
  cases
• no prescribed format but writing the use cases
• drags needs from the client
• drives the analysis of the information modelto
  identify the ingredients - domain classesand
  some of the actions
• drives refinement, organisation, improvement of
  specification

16
From Sequence diagrams to Domain classes (2)

• Classes in the Encounter game
• class object
• from Initialize sequence diagram
• EncounterGame (a single object)
• PlayerCharacter mainPlayerCharacter
• Area dressingRoom
• PlayerQualityWindow (a GUI class for the use
  case only)
• from Encounter foreign character
• ForeignCharacter freddie
• Engagement (a single object)
• Other domain classes can come frombrainstorming
  paring down.

17
Other sources of Domain classes?

• The use cases do not provide all of the useful
  classes for writing and organising the
  specifications
• EncounterGame
• PlayerCharacter
• Area
• PlayerQualityWindow
• ForeignCharacter
• Engagement
• EngagementDisplay
• GameCharacter
• AreaConnection
• ConnectionHyperlink

• Other domain classes can come frombrainstorming
  paring down
• door
• exit
• combat
• passageway
• result
• score
• rule
• quality
• . . . and more see fig 13.41

18
Other sources of Domain classes? (2)

• ... brainstorming paring down
• Game not a domain class, too general
• GameCharacter too general replace by
  PlayerCharacter
• ForeignCharacter OK to keep, acts a bit
  differently from PlayerCharacter so introduce
  EncounterCharacter as common parent
• Quality omit, try to handle as an attribute of
  EncounterCharacter
• Room we already have Area which covers this
  concept, no need to distinguish any difference

19
Why look for the domain classes?

• the domain classes are the key concepts (nouns)
  that should appear in most of our functional
  requirements statements
• we want to easily match requirements with classes
  in the design keeping the domain classes (and
  adding more classes) is a good starting point for
  design

20
Information models finite state model