Software Requirements Specification

For
<Your Project Title>
Submitted by
Team 13

Instructor Tom Horton

Team ID 13
Team Members Hunter Leake, Robert Brady, Johnson Hu, Patrick Tsui
Date Submitted February 27, 2008

Document Template copyright (c) 2005, Gregory W. Hislop. Modified by Thomas B. Horton in 2008 for use in CS340 at the
University of Virginia. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free
Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
 Table of Contents
1Introduction........................................................................................................................3
1.1Purpose........................................................................................................................3
1.2Scope...........................................................................................................................3
1.3Definitions, Acronyms, and Abbreviations.................................................................3
1.4References...................................................................................................................3
1.5Overview.....................................................................................................................4
2Overall Description............................................................................................................5
2.1Product Perspective.....................................................................................................5
2.2Product Functions.......................................................................................................5
2.3User Characteristics....................................................................................................5
2.4Constraints..................................................................................................................6
2.5Assumptions and Dependencies.................................................................................6
3Specific Requirements.......................................................................................................7
3.1External Interfaces......................................................................................................7
3.1.1Data Interface.......................................................................................................7
3.1.2User Interface.......................................................................................................7
3.2Functions.....................................................................................................................8
3.2.1Administrator Client............................................................................................8
3.3Performance Requirements.......................................................................................10
3.4Logical Database Requirements...............................................................................10
3.5Design Constraints....................................................................................................10
3.6Standards Compliance..............................................................................................10
3.7Software System Attributes.......................................................................................10
 Table of Contributions
The table below identifies contributors to various sections of this document.

Section Writing Editing

Entire Document
1 Introduction
1.1 Purpose All
1.2 Scope All
1.3 Definitions All
1.4 References All
1.5 Overview All
2 Overall Description
2.1 Product Perspective Hunter
2.2 Product Functions Hunter
2.3 User Characteristics Hunter
2.4 Constraints Johnson
2.5 Assumptions and Dependencies Johnson
3 Specific Requirements
3.1 External Interfaces Rob
3.1.1 Data Interface Rob
3.1.2 User Interface Rob
3.2 Functions Hunter
3.3 Performance Requirements Patrick
3.4 Logical Database Requirements Patrick
3.5 Design Constraints Johnson
3.6 Standards Compliance Patrick
3.7 Software System Attributes Patrick

2
1 Introduction
1.1 Purpose
This document provides a complete description of the behavior of the SMUVE v1.0
admin client to be developed. This document will include a set of functional and non-
functional requirements of the client. The customer whom this software is being
developed for will review this document.

1.2 Scope
The entire SMUVE v1.0 system can be simply divided into three subsystems: a server
client, an admin-client, and a player client. SMUVE v1.0 will use a server to store a
database or player and world information and manage interactions between players,
admins, and the SUMVE world. The admin-client will set up and manage the server
before and during game play. The player-client will allow players to interact with the
SMUVE world over one or more servers. Functionality does not overlap between
administrator and player clients; however overlap does occur between the server and each
client. This document describes the specific requirements of the admin-client which will
interact with the server client and therefore indirectly with player clients.

1.3 Definitions, Acronyms, and Abbreviations

administrator (admin) – An user who utilizes an admin-client to modify/run the server.
admin-client – An administrator program that manages rooms within the server, controls
room inventories, and determines the spawn location of the player’s character.
character – A computerized persona, avatar, or incarnation.
player – An user who utilizes a player-client to access the server.
player-client – A client program that controls movements of the player’s character within
the world and also controls its inventory.
MUD – Multi-User Dungeon, Domain or Dimension which a type of multiplayer online
computer program involving the control of user’s avatar and exploration of the world.
room – A computerized enclosed area within the world (server) where unpicked objects
resides in.
object – A computerized item that can be found in a room or an inventory of a character.
server – A database representation of the world (i.e. information about rooms, objects).
SMUVE – Simple Multi-User Virtual Environment which is a text-based multiplayer
online computer program, a simple version of MUD.

1.4 References
<TBD>

3
1.5 Overview
Section 2 covers the overall description of SMUVE v1.0. This section provides the
background for functional and non-functional requirements, which will be discussed in
Section 3. This section includes the product perspective, which describes its involvement
with the overall system. In addition, this section will describe all major functions that
this software will perform in the general sense. Furthermore, this section will describe
general characteristics of users of the admin-client including educational level,
experience, and technical expertise.
Section 3 details all of specific requirements of the SMUVE v1.0 admin client. This
section includes a detailed description of all inputs into and outputs from the SMUVE
system. In addition, all functional requirements will be covered in this section.
Furthermore, the logical requirements are discussed. Finally, this section will cover all
aspects that have not been identified yet.

4
2 Overall Description
2.1 Product Perspective
SMUVE v1.0 will be a self contained software system. Within the SMUVE system, users
will interact with one or more servers, which will be developed as part of SMUVE v1.0.
The figure shown below encapsulates the idea of SMUVE v1.0.

The bidirectional arrow represents the interaction between clients and servers. Stacked
boxes represent a number of player or admin clients that are connected to the server. The
encapsulation of this image is SMUVE v1.0.

2.2 Product Functions

SMUVE v1.0 will maintain a virtual world of rooms, players, and objects on a server.
Multiple instances of the SMUVE v1.0 will be able to communicate with one another to
create a larger world spread across multiple servers.
Rooms will provide the structure of this world. Each room will be connected to one or
more rooms, possibly on other servers. One or more rooms must exist on each server.
Each room may contain any number of users and/or objects. The admin will be able to
modify any of these characteristics through the client
Objects may be locked or unlocked. The locked state of the object depends upon the
world data but may be changed by the administrator.
The administrator will run a client that connects to the server but does not support a
character in the world. The administrator will be able to monitor and edit the world
including the existence and adjacency of rooms as well as the existence, location, and
lock-status of objects.

2.3 User Characteristics

There are two types of users of SMUVE v1.0; the first is players and the second is
administrators. These two types of users are disjoint and therefore share no common

5
functionality. Neither user group shall require any educational background or technical
expertise beyond basic computing skills.
Of these two types of SMUVE users the admin-client will be used by administrators. This
document focuses on the development of the admin-client for the users of the SMUVE
v1.0. Administrators are people connecting the server whose purpose is to monitor and
edit the SMUVE world without existing in it as a player. Administrators will have the
ability to see all rooms, adjacent rooms, users, and objects in the world as well as the
location of users and objects. The administrator will have the ability to create and delete
empty rooms, create and delete adjacent rooms, lock and unlock objects, and delete
objects not currently held by any user.

2.4 Constraints
No constraints have been determined for this project, therefore TBD.

2.5 Assumptions and Dependencies

<TBD>

6
3 Specific Requirements
3.1 External Interfaces
3.1.1 Data Interface
The server of SMUVE v1.0 stores data and constantly needs to update its interface due to
continual changes made by admins and players. When an admin logs into the server,
world data should be readily given by the server to update the display for the admin. The
data should be easily transferred to the admin-client from the server while the server is
active. The admin-clients must be able to access the necessary information from the
server that allows them to monitor and modify the world and the players in it.

3.1.2 User Interface

The user interface for the admin-client must contain at least the following components
displayed in a manner suitable for the administrator using the program:
 A listing of rooms on the server and a way to add/delete them
 A listing of links from each room to other rooms/servers and a way to add/remove
them
 A listing of objects in each room and a way to add/remove them

7
3.2 Functions
3.2.1 Administrator Client
A1 – Create a Room
Input A name of a room
Action The server shall create a new room in the world.

A2 – Delete a Room
Input A name of a room
Action The server shall delete a room with the given name and any objects in the
room’s inventory so long as this room is currently free of players at the request
of the admin-client. If this room contains one or more players or no room of
given name is found then the server will send an error message to the admin.

A3 – Create an Adjacent Room on same server

Input A name of an adjacent room
Action The server shall create an adjacent room between two rooms so long as one
does not currently exist at the request of the admin-client. If either room name
is invalid then the server will produce an error message.

A4 – Delete Adjacency
Input A name of an adjacent room
Action The server shall delete an adjacent room between the two rooms so long as
there is one at the request of the admin-client. If either room name is invalid
or there is no adjacent room then the server will produce an error message.

A5 – Create Object
Input A name of an object, a name of a room
Action The server shall create a new object of the given name in the given room at the
request of the admin. If there is no room of the given name then the server
will produce an error message.

A6 – Delete Object
Input A name of an object
Action The server shall delete an object of the given name so long as this object is not
currently held by a player. If there is no object of the given name, or this
object is held by a player then the server will produce an error message.

A7 – Lock Object
Input A name of an object
Action The server shall lock an object of the given name so it cannot be picked up by
users, so long as this object is not currently held by a player. If there is no
object of the given name or this object is held by player then the server will

8
 produce an error message.

A8 – Unlock Object
Input A name of an object
Action The server shall unlock an object of the given name so it can be picked up by
users. If no object of the given name exists then the server will produce an
error message.

A9 – Move Object
Input A name of an object, a name of room
Action The server shall move a named object from an inventory of a current room to
an inventory of the named room. If either room name is invalid then the server
will produce an error message.

A10 – Move Entry Point

Input A name of a room
Action The server shall move an entry point of a world to a room specified. If the
room name is invalid then the server will produce an error message.

A11 – Get World Data

Input No input, Triggered by message from server that world info has changed
Action The server shall request the current world information from the server and
subsequently handle the data transfer of the world information to the local
machine.

A12 – Create New Server

Input Server Name, Server Address
Action The server shall be able to create a new server at the given address. The admin
would then be able to disconnect from the current server and connect to the
new server to edit it.

A13 – Exit
Input Exit command from GUI
Action The client will disconnect from the server leaving the world playable to user
clients.

A14 – Log on
Input None
Action The client will connect to the server and get current world data.

9
A15 – Create Adjacent room on another Server
Input Name of Room on current server, Name of room on other server, Address of
server
Action The server shall create an adjacent room between two rooms so long as one
does not currently exist at the request of the admin-client. If either room name
is invalid then the server will send an error message to the admin-client.

3.3 Performance Requirements

No particular performance requirements have been identified.

3.4 Logical Database Requirements

The server of SMUVE v1.0 should save data on the default world, the objects, and the
characters in it. The admin-client will access the corresponding data file on the server for
their modification purposes.
• The server should save data on all the characters online to be accessed by the admin-
client:
o The admin-client will access this data file to fill the admin-client’s
window that shows the admin who is online, where they are (i.e. the room
and the server), and what objects they are holding. (i.e. GUI refresh)
 This will also be accessed by the server to send error messages to
the admin-client if he tries to delete rooms or objects that players
are interacting with
• The server should save data on the default world that will be loaded on start-up.
o The server should save a list of default rooms and their connections
 The server should have one of the default rooms picked as the
default start room for players to start in
o The server should save a list of all objects, their descriptions, and the
amount of each in the world
 Both the lists above will be accessed by the admin client for
reading and overwriting (i.e. modification and viewing)

3.5 Design Constraints

No particular design constraint requirements have been identified.

3.6 Standards Compliance

No particular standards compliance requirements have been identified.

3.7 Software System Attributes

No particular software system attribute requirements have been identified.

10