Taken and slightly adapted from the book:

Braude, E., “Software Engineering - An Object Oriented Perspective”, John Wiley and sons, 2001

Software Requirements Specification (SRS) for the Encounter Video Game

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.

22. July 2000 Update: Eric Braude and Tom van Court. Reworked to reflect lessons learned by implementing previous version.

25. July 2004 Update: Živana Komlenov (Novi Sad) analysed the document and removed remarks for students and other comments. Furthermore comments on deviation from IEEE Std 830-1998 (Revision of IEEE Std 830-1993) were added as endnotes in the text.

1. Introduction

1.1 Purpose

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

This document covers the requirements for release 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 affects 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
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[1]

Intentionally omitted. Covered in section 2.

2. Overall Description[2]

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

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[3]

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

2.1.2 User interface concepts[4]

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

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

2.1.4 Software interfaces

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.

2.1.7 Operations

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

2.1.8 Site adaptation requirements

None 

2.2 Product functions

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

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

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

2.4 Constraints

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

None

2.6 Apportioning of requirements

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.

3. Specific Requirements[5]

3.1 External interface requirements

3.1.1 User interfaces

Encounter takes place in areas. Figure 4.54 shows a typical screen shot of the courtyard area, with a player-controlled character, and the results of an engagement.

Figure 4.54 Encounter Courtyard Image, Including Game Characters and Status Window

Note that each part of this figure is specified separately in section 3. This interface takes up the entire window. Areas have connections to adjacent areas, labeled by hyperlinks. Clicking on one of these hyperlinks moves the player's character into the corresponding area.

The entire set of interfaces is as follows:

a. One image for each area, specified in section 3.2AR below.

b. A user interface for setting the quality values of the player's character, specified in section 3.2.PQ.

c. A user interface for displaying the results of an engagement, specified in section 3.2.ED. The same user interface is used to show the status of the player's character.

d. A window announcing the start of an engagement.

An interface of type a above will always be present on the monitor. When called for by these requirements, interfaces of type b or c will be superimposed.

3.1.2 Hardware interfaces

none

[Future release: Encounter shall be controllable by a joystick.]

3.1.3 Software interfaces  

Java virtual machine for Java 1.1 or higher.

[Future release: Encounter shall be playable from Intergalactic Internet Gaming Site]

3.1.4 Communication interfaces 

none

[Future release: Encounter shall interface with the Internet via a modem with at least 56 Kb/s]  

3.2 Specific requirements[6]

3.2.1 Sequence diagrams

3.2.1.1 Initialize use case

The sequence diagram for the Initialize use caseis shown in figure 4.55.

Figure 4.55 Sequence Diagram for Initialize Use Case

This use case requires classes EncounterGame (of which there is only one instance), PlayerCharacter (with instance main player character), PlayerQualityWindow (of which there is only one instance), and Area (with instance dressing room).

3.2.1.2 Travel to adjacent area use case

The sequence diagram for the Travel to adjacent area use case is shown in figure 4.56.

Figure 4.56 Sequence Diagram for Travel to Adjacent Area Use Case

This use case requires classes ConnectionHyperlink, AreaConnection, Area, and PlayerCharacter.

3.2.1.3 Engage foreign character use case

The sequence diagram for the Engage foreign character use case is shown in the figure 4.57.

Figure 4.57 Sequence Diagram for Encounter Foreign Character Use Case

This use case requires classes EncounterGame (of which there is only one instance), ForeignCharacter (with instance freddie), Engagement, PlayerCharacter, PlayerQualityWindow, and EngagementDisplay.

3.2.2 Classes for classification of specific requirements

The classes for the Encounter video game sufficient for expressing the requirements are Area, EncounterCharacter, EncounterGame, Engagement, EngagementDisplay, ForeignCharacter, PlayerCharacter, PlayerQualityWindow, and ThumbnailMap. These are shown in the object model of figure 4.58.

Figure 4.58 Classes for Encounter Video Game, Showing Only Inheritance Relationship

3.2.AR Areas

An area is a place viewable on the monitor. All activities of Encounter (including engagements) take place in areas. Rooms, gardens and courtyards are examples of areas.

3.2.AR.1 Attributes of areas

3.2. AR.1.1 Area name

[essential; implemented] Every area shall have a unique case-insensitive name consisting of 1 to 15 characters. Acceptable characters shall consist of any digits and characters as specified by the ISO Unicode standard.

3.2. AR.1.2 Area image

[essential; implemented] There shall be an image to display each Area object on the part of the window not occupied by the required buttons or the thumbnail map.

3.2.AR.1.3 Area-specific qualities

[essential; implemented] Only some game character qualities shall be applicable in each area. The specific qualities required for each area are specified in section 3.2.AR.2.

3.2.AR.2 Area entities

3.2.AR.2.1 Courtyard area

[essential; implemented] There shall be an Area object with name "courtyard", requiring qualities stamina, and strength. The courtyard image is shown in figure 4.59.

Figure 4.59 Encounter Courtyard Image

3.2.AR.2.2 Dressing room area

[essential; implemented] There shall be an area with name "dressing room", requiring no qualities. The image is shown in the figure 4.60.

Figure 4.60 Encounter Dressing Room Image

3.2.AR.2.3 Dungeon area

[essential; implemented] There shall be an area with name "dungeon", requiring qualities stamina, and patience. Its image is shown in figure 4.61.

Figure 4.61 Encounter Dungeon Image

3.2.AR.2.4 Kitchen area

[essential; implemented] There shall be an area with name "kitchen", requiring the quality concentration. The kitchen image is shown in figure 4.62.

Figure 4.62 Encounter Kitchen Image

3.2.AR.2.5 Living room area

[essential; implemented] There shall be an area with name "living room", requiring qualities concentration, and stamina. Its image is shown in figure 4.63.

Figure 4.63 Encounter Living Room Image

3.2.AR.2.6 Study area

[essential; implemented] There shall be an area with name "study", requiring quality concentration. Its image is shown in figure 4.64.

Figure 4.64 Encounter Study Image

3.2.AR.3 Area functionality

none

3.2.AR.4 Events pertaining to areas

3.2.AR.4.1 Display on entry of player character

[essential; implemented] Whenever the player's main character enters an area, that area and the characters in it shall be displayed on the monitor, filling the monitor.

3.2.AR.4.2 Handling engagements

[essential; implemented] When a foreign game character enters an area containing the player's main character, or vice versa, they engage each other.

3.2.AR.4.7 Display on entry of foreign character

[essential; implemented] Whenever the foreign character enters the area in which the player is present, that area and the characters in it shall be displayed.

3.2.CH Connection hyperlinks between areas

Connection hyperlinks are hyperlinks placed at each area exit, showing the area to which it is connected.

3.2.CH.1 Attributes of connections hyperlinks

3.2.CH.1.1 Connection

[essential; implemented] Each connection hyperlink corresponds to an area connection.

3.2.CH.2 Connection hyperlink entities

[essential; implemented] There are two connection hyperlinks corresponding to each area connection, one in each area of the connection.

3.2.CH.3 Functionality of connection hyperlinks

none

3.2.CH.4 Events pertaining to connection hyperlinks

3.2.CH.3.1 User clicks on a connection hyperlink

The effect of clicking a connection hyperlink is that the player's character is displayed in the area on the other side of the area connection.

3.2.CO Connections between areas

Characters travel from area to adjacent area by means of connections. Each of these connects two areas. Figure 4.65 shows the required connections among the areas.

Figure 4.65 Encounter Area Configuration (Desirable Requirement)

3.2.CO.1 Attributes of connections between areas

3.2.CO.1.1 First and second areas

[essential; implemented] Each connection will connect a pair of areas, which we will call the "first" and "second".

3.2.CO.2 Connections entities

3.2.CO.2.1 Dressing room - courtyard

[essential; implemented] There will be a connection between the dressing room and the courtyard.

3.2.CO.2.2 Dungeon - study

[essential; implemented] There will be a connection between the dungeon and the courtyard.

3.2.CO.2.3 Study - living room

[essential; implemented] There will be a connection between the dungeon and the living room.

3.2.CO.2.4 Courtyard - living room

[essential; implemented] There will be a connection between the living room and the courtyard. 

3.2.CO.2.5 Dressing room - dungeon

[essential; implemented] There will be a connection between the dressing room and the dungeon.

3.2.CO.2.6 Courtyard - kitchen

[essential; implemented] There will be a connection between the kitchen and the courtyard.

3.2.CO.3 Functionality of area connections

none

3.2.CO.4 Events pertaining to area connections

3.2.CO.4.1 Moving a character through a connection

[essential; implemented] Connections are displayed as hyperlinks at the borders of areas whenever the player's character is in the area. When the user clicks such a hyperlink, the linked area is displayed, with the character in this area.

3.2.EC Encounter characters

3.2.EC.1 Attributes of Encounter characters

3.2.EC.1.1 Name of Encounter characters

[essential; implemented] Every game character in the Encounter video game shall have a unique name. The specifications for names shall be the same as those for Area names, specified in 3.2.AR.1

3.2.EC.1.2 Qualities of Encounter characters

[essential; implemented] Every game character has the same set of qualities. Each quality shall be a non-negative floating point number with at least one decimal of precision. These are all initialized equally so that the sum of their values is 100. The value of a quality cannot be both greater than zero and less than 0.5.

For the first release the qualities shall be concentration, intelligence, patience, stamina, and strength.

3.2.EC.1.3 Image of Encounter characters

[essential; implemented] Every game character shall have an image.

3.2.EC.2 Encounter character entities

The characters of the game are described among the types of Encounter characters.

3.2.EC.3 Functionality of Encounter characters

3.2.EC.3.1 Living points

[essential; implemented] The Encounter game shall be able to produce the sum of the values of any character's qualities, called its living points.

3.2.EC.3.2 Configurability of Encounter character quality values

[essential; implemented] Whenever an Encounter character is alone in an area, the value of any of its qualities may be set. The value chosen must be less than or equal to the sum of the quality values. The values of the remaining qualities are automatically adjusted so as to maintain their mutual proportions, except for resulting quantities less than one, which are replaced by zero quality values. 

3.2.ED Engagement displays

[essential; implemented] There shall be a window displaying the result of engagements. The format is shown in figure 4.66.

Figure 4.66 User Interface for Showing Status

3.2.ED.4 Engagement display events

3.2.ED.4.1 Dismissing the display

[essential; implemented] When the user hits OK, the display disappears.

3.2.EG The Encounter game

The requirements in this section pertain to the game as a whole.

3.2.EG.1 Attributes of the Encounter game

3.2.EG.1.1 Duration

[implemented] A record will be kept of the duration of each game, timed from when the player begins the game.

3.2.EG.1.2 Action buttons

Every game window shall show a "Get status" button, a "Set qualities" button and an "End game" button in the lower left corner.  

3.2.EG.2 Entities of the Encounter game

3.2.EG.2.1 Single game

[essential; implemented] There shall be a single game. [Future releases will allow several versions of the game to run at the same time.]

3.2.EG.4 Events the Encounter game

3.2.EG.4.4 Pressing the Set qualities button

When the user presses the set qualities button, and provided that there is no foreign character in the area, a window for setting the values of qualities appears, superimposed on the area. See 3.2.PQ for the specifications of this window.

3.2. EG.4.5 Pressing the End game button

[optional; not yet implemented] When the user presses the end game button, the game terminates. No additional screens appear.

3.2. EG.4.6 Pressing the Get status button

[optional; not yet implemented] When the user presses the get status button, an engagement display window appears showing the status of the player's character before and after the last engagement.

3.2.EN Engagements

An engagement is the interaction between a game character controlled by the player and a foreign character. 

3.2.EN.1 Attributes of engagements

none

3.2.EN.2 Engagement entities

There are no permanent engagement entities.

3.2.EN.3 Functionality of engagements

3.2.EN.3.1 Engaging a foreign character

[essential; implemented] When an engagement takes place, the "stronger" of the two characters, is the one whose values of area-specific qualities sum to the greater amount. The system transfers to the stronger, half the values of each area-specific quality of the weaker. No transfer of points takes place if no character is stronger.

After the value re-allocations are made, if either character has no points, the game ends. If the game does not end, the player's character is moved to a random area, and the results of the engagement are displayed.

As an example of the value re-allocations, suppose that the player engages a foreign character in an area preferring stamina and concentration. If p_s is the value of the player's stamina etc., and assuming p_s + p_c > f_s + f_{c ,} we would have p_s' = p_s + f_s/2, p_c' = p_c + f_c/2, f_s' = f_s/2, and f_c' = f_c/2 where x' is the value of x after the transaction.

To take a numerical example of an engagement in this area: if the player's stamina value is 7, and concentration value is 19, and Freddie the foreigner's stamina is 11 and concentration 0.6, then the player is stronger. The result of the engagement would be:

Player: stamina 7 + 11/2 = 12.5; concentration 19 + (0.6)/2 = 19.3

Freddie: stamina 11/2 = 5.5; concentration 0 because (0.6)/2 is less than 0.5

3.2.EN.4 Events on engagements

3.2.EN.4.1 Interrupting engagements

[implemented] Players are able to interrupt engagements on a random basis. On average, the player can stop one of every ten engagements, by executing the procedure to set qualities. The user tries to interrupt an engagement by attempting to set the player's qualities. If the game does not allow this, no indication is given: the game proceeds as if the attempt had not been made.  

3.2.FC Foreign characters

A foreign character is an Encounter character not under the player's control.

3.2.FC.1 Attributes of foreign characters

See Encounter character requirements. These are initialized to be equal.

3.2.FC.2 Foreign character entities

3.2.FC.2.1 Freddie foreign character

[essential; implemented] There shall be a foreign character named "Freddie", whose image is shown in figure 4.67. This character shall initially have a total of 100 points, distributed equally among its qualities.

Figure 4.67 Image for Freddie Foreign Character

3.2.FC.3 Functionality of foreign characters

3.2.FC.3.1 Foreign character movement

[essential; implemented] As long as it is alive, a foreign character should move from area to adjacent area at random intervals averaging two seconds. After being present in an area for a random amount of time averaging one second, all of the player's life points are divided among the qualities relevant to the area, such that the value of these qualities are as close to equal as possible.

3.2.PC Player characters

These are Encounter characters under the control of the player.

3.2.PC.1 Attributes of player characters

See Encounter character attributes. Player character images can be selected from one of the images in figure 4.68.

Figure 4.68

3.2.PC.2 Player character entities

3.2.PC.2.1 Player's main character

The player shall have control over a particular game character called the "main" character. The nature of this control is subject to the restrictions specified in the remaining requirements. This character shall initially have a total of 100 points, distributed equally among its qualities.

3.2.PC.2.2 Additional characters under the control of the player

[optional; not yet implemented] The player shall be able to introduce characters he controls other than the main player. Details are to be decided.

3.2.PC.3 Player character functionality

3.2.PC.3.1 Configurability of the player character quality values

[essential; implemented] Whenever all foreign players are absent from the area containing the player's main character, the player may set the value of any quality of the character using the PlayerQualityWindow shown in figure 4.69. The value chosen must be less than or equal to the sum of the quality values. The values of the remaining qualities are automatically adjusted so as to maintain their mutual proportions, except for resulting quantities less than 0.5, which are replaced by zero quality values.

3.2.PC.3.1 Configurability of the player character images

[desirable; not yet implemented] The player shall have the option to choose the image representing his or her main character from at least two images. These options are shown in the figure.

3.2.PC.3.2 Aging of the player character images

[optional; not yet implemented] ("Player aging") The main player character shall automatically increase each quality by a percentage for the first half of his or her life, then decrease them by the same percentage for the second half. Details are to be decided.

3.2.PQ The player quality window

This is a window from which the player may allocate the values of his or her characters.

3.2.PQ.1 Attributes of the player quality window

The window for setting the qualities of a player character in Encounter is shown by means of a typical example in figure 4.69.

Figure 4.69 User Interface for Setting Values

The game character icon appears in the center and its name at the left top. The character's life points appear in the right top corner. On the left center is a list box of the qualities displaying four of them at a time. Clicking on one of these allows the player to select a value for it in the text box on the right. An explanation of how the arithmetic is performed is shown in a pale yellow box at lower center. Color backgrounds for the name, life points and value boxes are to be pale turquoise.

The method for performing quality value computations is described in section 3.2 below.

3.2.PQ.2 Player quality window entity

3.2.PQ.2.1 Window for allocating qualities

[essential; implemented] A window shall be available under the conditions described above to allocate the values of the player character. The window shall have the appearance of the GUI shown in section 3.1.1.2 of this specification.

3.2.PQ.3 Player quality functionality

3.2.PQ.3.1 Initiating the display

[essential; implemented] The player quality menu shall be able to display itself.

3.2.PQ.4 Player quality window events

3.2.PQ.4.1 Displaying the value of a quality

[essential; implemented] When the player clicks on a quality in the list box on the left, the value of that quality shall be displayed in the text box on the right.

3.2.PQ.4.2 Setting the value of a quality

[essential; implemented] When the user enters a legitimate value for a quality, and hits the "enter" button, the value of that quality may be set to the amount entered, subject to requirement 3.2.PQ.4.3. If the value is invalid, and error message shall appear.

3.2.PQ.4.3 Dismissing the window

[essential; implemented] When the user hits the OK button, a time of four seconds elapses, after which the window disappears. At the end of this time period (i.e., if there are no interruptions), the value allocations made.

3.2.PQ.4.4 Interruption

[essential; implemented] On interruption of the quality value window being displayed, the window vanishes.

Note that interruptions will be caused by a foreign character entering the area. Note also that the quality values are not changed, and an engagement takes place.

3.2.TH Thumbnail sketch of playing areas

This is a figure showing the relationship among the areas in the immediate environment of the player.

3.2.TH.1 Attributes of the thumbnail sketch

3.2.TH.1.1 Thumbnail image

[essential] The thumbnail image shall be as shown below.

3.3 Performance requirements

The application shall load and display the initial image in less than a minute.

Engagements should execute in less than one second.

3.4 Design constraints

Encounter shall be designed using UML and object-oriented design. It shall be implemented in Java. The software will run as a Java application on Windows 95. It shall be designed in a way that makes it relatively easy to change the rules under which the game operates so that others can customize the game.

3.5 Software system attributes

3.5.1 Reliability

Encounter shall fail not more than once in 1000 encounters.

3.5.2 Availability

Encounter shall be available for play on any PC running Windows 95 only (i.e., no other applications simultaneously).

3.5.3 Security

[Future releases will allow access to saved games only with a password.] 

3.5.4 Maintainability

3.5.4.1 Changing characters and areas

[essential] It shall be relatively straightforward to change characters and areas.

3.5.4.2 Globally altering styles

[desirable] It shall be straightforward to globally alter the style of the areas and connections. (Style changes reflect different levels of game play in the same environment.)

3.5.4.3 Altering rules of engagement

[optional] Rules of engagement should be relatively easy to change.

3.6 Other requirements

none

4. Supporting information

none 

4.1 Table of contents and index[7]

To be supplied

4.2 Appendices[8]

To be supplied

---

[1] Section 1.5 Overview was intentionally omitted. It should give an overview of the software, present its main goals, tasks and users. The author of Encounter SRS felt no need for this section, intending to cover its contents in section 2.

[2] Section 2. Overall Description was partly changed. First of all in subsection 2.1 Product perspective. Encounter is here compared with other related or competing products, which is a useful way to provide perspective on the application.

[3] According to the standard, there should be subheading 2.1.1 System interfaces. This should list each system interface and identify the functionality of the software to accomplish the system requirement and the interface description to match the system. It has been changed, though, from the IEEE standard to 2.1.1 Concept of operations in order to accommodate "concept of operations". In the case of Encounter, the requirements developers decided that state/transitions best convey the overall concept of the application.

[4] Subheading 2.1.2 User interfaces concepts is modified actual IEEE heading, User interfaces, to emphasize that it does not represent the detailed UI's. It explains some figures as preliminary sketches and/or principles of key user interfaces only, used to provide perspective on the product. All the user interfaces are specified in detail in section 3.

[5] Section 3. Specific Requirements was partly changed. Generally the standard allows this section to take different structure depending on chosen style. Encounter SRS uses “object-oriented” style.

[6] The biggest difference compared to the standard in this part of the document is in section 3.2 Classes/Objects (this is the correct headline according to the standard). OO style of Encounter SRS expects that detailed requirements are classified by classes. This section should list classes pertaining to the domain of the application and, which are adequate for organising all of the requirements. These classes are not all of the classes that will be used by the application. Every function/class should be marked as 'essential', 'desirable', or 'optional'.

Our section is titled 3.2 Specific requirements. It takes some liberties with the IEEE standards in order to account for use cases. First it describes sequence diagrams required to express use cases of section 2.2 of the SRS (section 3.2.1 Sequence diagrams – the IEEE SRS standard does not have a section called “sequence diagrams”; it has been tailored to accommodate this concept). Classes required to express these use cases are then used to classify detailed requirements (section 3.2.2 Classes for classification of specific requirements).

[7] Section 4.1 Table of contents and index has to be supplied if Encounter SRS tends to be complete.

[8] The same situation is with possible 4.2 Appendixes. They have not been supplied yet. Appendices may include: sample I/O formats, descriptions of cost analysis studies, or results of user surveys; supporting or background information that can help the readers of the SRS; a description of the problem to be solved by the software; special packaging instructions for the code and the media to meet security, export, initial loading, or other requirements. It should be explicitly stated whether or not each appendix is to be part of the SRS.