CASE STUDY

[Note: Using a standard to write the SRS helps one to cover all of the aspects of requirements that readers need to know about, and provides a recognized structure.  Several standards are available, but we will concentrate on the IEEE standard. The complete IEEE 830-1993 standard can be found in [IE]. Most organizations allow modification of the standards to tailor it for their own use. The template used below modifies the standard by omitting some less important sections and by adding sections on concept of operations and use cases. The student can compare the case study headings with the standards shown in figure 3.6 on page ???.]

Software Requirements Specification (SRS) for the Encounter Video Game

part 1 of 2

[Note to the student: the case study portion in this chapter, sections 1 and 2, covers the customer (C-) requirements.  The remainder of the document, sections 3 and 4, containing the specific (D-) requirements, is provided in the case study at the end of the next chapter. Recall that C-requirements are not intended to be detailed enough to develop the design and implementation: this is the purpose of the D-requirements.]  

History of versions of this document. 

x/yy/zzz Hal Furness: Initial draft

x/yy/zzz Karen Peters: Reviewed for technical accuracy; changes made throughout

x/yy/zzz Hal Furness: Entire document reviewed for small improvements

x/yy/zzz Karen Peters: Document reviewed and suggestions made

x/yy/zzz Karen Peters: moved use cases to section 2.2

x/yy/zzz Hal Furness: improved wording throughout. Sense not changed.

6/22/00 Update: Eric Braude and Tom van Court. Reworked to reflect lessons learned by implementing previous version.

Blue text added, red strike-through text deleted from previous revision.

1. Introduction

1.1 Purpose 

[Note to the student: the purpose of this entire document (not the purpose of the application).]

This document provides all of the requirements for the Encounter video game. Parts one and two are intended primarily for customers of the application, but will also be of interest to software engineers building or maintaining the software. Part three is intended primarily for software engineers, but will also be of interest to customers.

1.2 Scope 

[Note to the student: what overall aspects of the application this document is intended to cover.]

This document covers the requirements for release 0.0.1 1.0 of Encounter. Mention will be made throughout this document of selected probable features of future releases. The purpose of this is to guide developers in selecting a design that will be able to accommodate the full-scale application.

1.3 Definitions, acronyms, & abbreviations

Acronym or term	Definition
Alive	A game character is said to be "alive" if it has at least one quality with non-zero value.
C-requirement	Statement of the requirements for the application, expressed in a form clear to the customer.
D-requirement	Statement of the requirements for the application, given in a form detailed enough to be used by the developers for design and implementation. If possible, D-requirements should also be understandable to the customer.
Encounter	Name of this application; also, a meeting between two game characters in an area (but not necessarily an "engagement" -- see below)
Engagement	An interaction between characters of the game, which typically affect the characters
RPG	"Role-playing game"; a game, typically played on a computer, in which the players adopt character roles
Role-playing game	See RPG
Video game	A game played on a computer

Table 3.3 Acronyms 

1.4 References

Software Configuration Management Plan (SCMP) for Encounter version 1.0
Software Design Description  (SDD) for Encounter version 1.2
Software Project Management Plan (SPMP) for Encounter version 1.2

Software Quality Assurance Plan (SQAP) for Encounter version 1.0
Software User Documentation Plan (SUDP) for Encounter version 1.0

Software Test Documentation (STD) for Encounter version 1.0

1.5 Overview

Intentionally omitted.

[Note to the student: the author of this document felt no need for this section, intending to cover its contents in section 2.]

2. Overall Description

[Note to the student: make this general enough that it is unlikely to change much in future versions. Avoid statements that are repeated in later sections.]

Encounter is to be a role-playing game which simulates all or part of the lifetime of the player's main character. It should be of interest to both men and women. The measure of "success" in playing Encounter is up to the player. Typically, success will be measured by the "life points" maximum attained by the player or by the ability of the player to live as long a life as possible.

Some game characters are to be under the control of the player. The rest, called "foreign" characters, are to be under the application's control.   Game characters will have a fixed total number of points allocated among qualities such as strength, stamina, patience etc.  Characters encounter each other when they are in the same area at the same time, and may then engage each other.  The result of the engagement depends on the values of their qualities and on the environment in which the engagement takes place.  Engagements are not necessarily violent or adversarial.  Players have restricted opportunities to reallocate their qualities. One of the player-controlled characters will be referred to as the "main" player character.

In early versions of this game, there will be only one player-controlled character, and one foreign character.

The eventual nature of the characters is to be determined from insights gained from surveys and focus groups.  It is expected that initial releases will not have animation.

Encounter should eventually be highly customizable, so that users can either start with predefined games, substitute pre-designed characters and rules of engagement, or devise their own characters and rules of engagement.

The design should support expansion into a family of games, including Internet-based multiple player versions.

2.1 Product perspective

[Note to the student: In this section, Encounter is compared with other related or competing products. This is a useful way to provide perspective on the application. Subheading 2.1.1. of this section has been changed from the IEEE standard to accommodate "concept of operations".]

Encounter is intended to fulfill the need for gamers to have a greater influence over the contents of video games with and without programming. It is also intended for a somewhat mature clientele. Encounter is intended to appeal to both genders. The design and documentation for Encounter will make it convenient to expand and modify the game. It is anticipated that Encounter will be used as a legacy application for expansion into applications such as office interaction simulations.

2.1.1 Concept of operations

[Note to the student: This section conveys the overall concept of the application by whatever means are most natural for doing so. In the case of Encounter, the requirements developers decided that state/transitions best convey the concept.]

Encounter can be in one of several states, as shown in figure 3.40.

Figure 3.40 Encounter State-Transition Diagram

• Setting up: the state in which the game is being set up by the player
• Reporting: the system is displaying a window showing the status of the player's character(s)
• Setting qualities: equipping the player's character with qualities. This process consumes mandatory amounts of time, and can be performed as long as no foreign character is present.
• Engaging: the state which applies whenever a foreign character and the player's main character are both present in an area at the same time 
• Waiting: The player and the foreign character(s) are not active

This state/transition is tested by integration test <test reference goes here>. 

2.1.2 User interface concepts

[Note to the student: the following figures are preliminary sketches of key user interfaces only, used to provide perspective on the product. All the user interfaces are specified in detail in section 3. We have modified the actual IEEE heading, "user interfaces", to emphasize that these are not the detailed UI's.] 

2.1.2.1 Area user interface concept

The areas in which encounters take place shall have an appearance very roughly like that shown in figure 3.41.

Figure 3.41 Preliminary Encounter Screen Shot

2.1.2.2 User interface concept for setting quality values

When setting the values of game characters under his control, the player will retrieve an interface of the form sketched approximately in figure 3.42. The scroll box is used to identify the quality to be set, and the text box is used for setting the value.

Figure 3.42 Preliminary Sketch of User Interface for Setting Game Character Qualities

2.1.3 Hardware interfaces

None. 16-bit color resolution or better. Future releases will utilize a joystick.

2.1.4 Software interfaces

None. Java virtual machine capable of executing Java 1.1 or higher.

2.1.5 Communications interfaces

None. Future releases will interface with the Internet via a modem.

2.1.6 Memory constraints

Encounter shall require no more than 16 MB of RAM and 20MB of secondary storage. (see test plan <test reference>) 

2.1.7 Operations

[Note to the student: Normal and special operations required by the user]

[Future release] It shall be possible to save and retrieve a game.

2.1.8 Site adaptation requirements

[Note to the student: Requirements for execution on a particular installation; versions in various languages (e.g., French, Japanese, Spanish) etc.]

None 

2.2 Product functions

[Note to the student: Summary of the major functions of the application. More detailed than section 1.5; less detailed than section 3. The writers of this SRS decided that use cases are an appropriate manner in which to specify the major overall functionality.]

This section specifies the required overall functionality of the application, but is not intended to provide the complete specifications. Section 3 provides the requirements in complete detail. 

2.2.1 "Initialize" use case

Actor: player of Encounter

Use case: figure 3.43 gives the text  of the Initialize use case. The use case is shown in context with the Encounter foreign character use case and the Set rules use cases. Initialize is the typical sequence users execute at the beginning of a session.

Figure 3.43 Initialize Use Case for Encounter

This use case corresponds to test <test reference>  in the Software Test Documentation. 

2.2.2 "Travel to adjacent area" use case

Actor: player of Encounter

Use case:

1. Player hits hyperlink connecting displayed area to adjacent area

2. System displays the indicated adjacent area containing player's character

2.2.3 "Encounter foreign character" use case

Actor: player of Encounter

Use case:

1. System moves a foreign game character into the area occupied by the player.

Or Player moves into an area containing a foreign character.

2. System causes the two characters to engage

3. System displays the result of the engagement  

4. If either the player's character or the foreign character has no points, the game terminates, otherwise &

5. System moves the player's character to a random area different from that in which the encounter took place, and displays it there.

2.3 User characteristics

[Note to the student: indicate what kind of person the typical users are likely to be. Examples: novice, software professional, accountant with 5 years of computer usage, etc.]

The user is expected to be approximately 20-35 years of age.

2.4 Constraints

[Note to the student: all conditions that may limit the developer's options. These can originate from many sources.]

Encounter shall operate on PC's running Windows 95 or later at a minimum speed of 100MHz. Java shall be the implementation language.

2.5 Assumptions and dependencies

[Note to the student: any assumptions being made e.g. future hardware]

None

2.6 Apportioning of requirements

[Note to the student: Order in which requirements are to be implemented.] 

The requirements described in sections 1 and 2 of this document, are referred to as "C-requirements"; those in section 3 are referred to as "D-requirements". The primary audience for C-requirements is the customer community, and the secondary audience is the developer community. The reverse is true for the D-requirements.  These two levels of requirements are intended to be consistent. Inconsistencies are to be logged as defects. In the event a requirement is stated within both the C-requirements and the D-requirements, the application shall be built from the D-requirement version, since it is more detailed. 

"Essential" requirements (referred to in section 3) are to be implemented for this version of Encounter. "Desirable" requirements are to be implemented in this release if possible, but are not committed to by the developers. It is anticipated that they will be part of a future release. "Optional" requirements will be implemented at the discretion of the developers.