COMP2110 Software Design in 2003
lecture 5 Requirements Specifications
lecture 3 of 3
The Encounter game case study
1.
introduction to the Problem – the Encounter Game
2.
examples from the specification document
ANU comp2110 Software Design lecture 5
The Software Requirements Specification
SRS
The product of the Analysis phase is
a 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 scenarios
that capture and express the relationships between
the model and the real world of the problem
other explanatory models:
• interfaces, states, decisions
ANU comp2110 Software Design lecture 5
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/resources/
Encounter-SRS/EncounterSRS-1.html
and ...
EncounterSRS-1.html
you need to study this to prepare for tutorial in week 3
ANU comp2110 Software Design lecture 5
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 player’s character
• includes characters not under player’s 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
ANU comp2110 Software Design lecture 5
Sample Encounter Screen
kitchen
COURTYARD
living
room
dressing
room
Get status
Set qualities
Graphics reproduced with permission from Corel.
End game
comp2110
Software
Design
lecture
5 J. Braude (Wiley 2001), with permission.
AdaptedANU
from Software
Engineering:
An Object-Oriented
Perspective
by Eric
ANU comp2110 Software Design lecture 5
User Interface for Setting Quality Values
Shawn
Current life points: 100.0
Choose the quality
you wish to set
Choose the value of
the quality selected
16.3
image
comp2110
Software
Design
lecture
5 J. Braude (Wiley 2001), with permission.
AdaptedANU
from Software
Engineering:
An Object-Oriented
Perspective
by Eric
Shawn
Current life points: 100.0
Choose the quality
you wish to set
Image
User Interface for
Setting Quality
Values
Choose the value of
the quality selected
16.3
Explanation
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
OK
ANU comp2110 Software Design lecture 5
Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Graphics reproduced with permission from Corel.
2. Player requests a window
for setting his character’s
qualities.
ANU comp2110 Software Design lecture 5
Engage Foreign Character Use Case
Details of use case
Encounter
Initialize
player
Actor
(agency
external to
the
application)
Engage
foreign
character
Name of use case
....
1. System displays the
foreign character in the
same area as the
player’s.
2. System exchanges
data between the two
characters.
3. System displays the
results of the
engagement in a
message window.
4. Player dismisses
window.
comp2110
Software
Design
lecture
5 J. Braude (Wiley 2001), with permission.
AdaptedANU
from Software
Engineering:
An Object-Oriented
Perspective
by Eric
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.
ANU comp2110 Software Design lecture 5
A use case expressed in 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 player
or 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
5. System moves the player's character to a random area different
from that in which the encounter took place, and displays it there.
ANU comp2110 Software Design lecture 5
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
player
or 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
5. System moves the player's character to a random area different
from that in which the encounter took place, and displays it there.
ANU comp2110 Software Design lecture 5
Sequence Diagram for Engage Foreign Character Use Case
:Encounter
Game
freddie:
Foreign
Character
:Engagement
:Engagement
Display
:Player
Character
1.1 create; display
1.2 create
2.1 execute
2.2 change quality values
3 create and show
ANU
comp2110
lecture
5 (Wiley 2001), with permission.
Adapted from
Software
Engineering: AnSoftware
Object-OrientedDesign
Perspective by
Eric J. Braude
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 model
to identify the “ingredients” - domain classes
and some of the actions
drives refinement, organisation, improvement of
specification
ANU comp2110 Software Design lecture 5
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
Engagement
freddie
(a single object)
Other domain classes can come from
brainstorming & paring down.
ANU comp2110 Software Design lecture 5
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
ANU comp2110 Software Design lecture 5
Other domain classes can come
from
brainstorming & paring down
• door
• exit
• combat
• passageway
• result
• score
• rule
• quality
• . . . and more see fig 13.41
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
ANU comp2110 Software Design lecture 5
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
ANU comp2110 Software Design lecture 5
Information models – finite state model
ANU comp2110 Software Design lecture 5