Multi-Agents Search Game
Software Requirements Specification
Version 0.5: April 24, 2007
SEAN NGO (TL) MAHBUBUR RAHMAN HAQUE
Dr. Rym Z. Mili CS 6354 – Advanced Software Engineering University of Texas at Dallas Spring 2007
1
Table of Contents
1. INTRODUCTION 1.1 1.2 1.3 1.4 1.5 PURPOSE SCOPE DEFINITIONS, ACRONYMS AND ABBREVIATIONS REFERENCES OVERVIEW 3 3 3 3 4 4 5 5 5 5 5 5 6 8 9 9 10 10 10 10 10 11 12 12 12
2. OVERALL DESCRIPTION 2.1 2.2 2.3 2.4 2.5 PRODUCT PERSPECTIVE PRODUCT FUNCTIONS USER CHARACTERISTICS CONSTRAINTS ASSUMPTIONS AND DEPENDENCIES
3. FUNCTIONAL REQUIREMENTS 3.1 USE CASE DIAGRAM 3.2 USE CASE 1: INITIALIZE 3.3 USE CASE 2: PLAY GAME 3.4 EXTERNAL INTERFACE REQUIREMENTS 3.5.1 USER INTERFACES 3.5.2 HARDWARE INTERFACES 3.5.3 SOFTWARE INTERFACES 3.5.4 COMMUNICATION INTERFACES 4. NON FUNCTIONAL REQUIREMENTS 4.1 PRODUCT NON FUNCTIONAL REQUIREMENTS 4.2 PROCESS NON FUNCTIONAL REQUIREMENTS 4.3 EXTERNAL NON FUNCTIONAL REQUIREMENTS
2
1. Introduction
1.1 Purpose
This document is intended to specify the functional, non-functional requirements of a web based multi-agent search game. The main purpose of this document is to list down requirements and get them approved by the customer. This document would also be considered as the basis for the design and test specification document for our product.
1.2 Scope
The document is all about functional and non-functional requirements for the multi-agent based search game. This document also provides an overall description for the product. However, it doesn’t discuss any design or implementation issue related to the agent based search game.
1.3 Definitions, Acronyms and Abbreviations
The following table includes the list of definition, acronyms and abbreviations related to our project.
Term Agent
Definition In this document, the word agent refers “intelligent agent”. An intelligent agent is a participant of a situation that carries out an action. The agent has ability to acquire knowledge from the environment and then use that knowledge to change its behavior at various kinds of situations. A multi-agent system (MAS) is a system composed of several agents, collectively capable of reaching goals that are difficult to achieve by an individual agent. 2D visualization refers to the 2D view of an environment. In our case, it basically refers to the 2D visualization of the search environment.
Multi – Agent System 2D Visualization
3
1.4 References
1. Project Description version 1.0 provided by Dr. Mili. 2. An outline of the Software Requirement Specification provided by Dr. Mili. 3. IEEE standard 830-1993 for Requirements Documents.
1.5 Overview
This document is the official source for all requirements related to our project. It lists down formal functional and non-functional requirements provided by the stakeholders. This document will be subject to constant updates and revisions due to official changes in requirements from stakeholders. This document keeps track of any changes in the requirements and their sources throughout the lifecycle of the product under development. It basically describes all the needs of our clients in an organized and structured manner.
4
2. Overall Description
2.1 Product Perspective
The main perspective of the product is to allow the students of Advanced Software Engineering course to experience a complete software lifecycle to develop a multi-agent based search game.
2.2 Product Functions
The product allows two main functionalities to be performed: “initialize game” and “play game”. These two basic functionalities are explained below. The application should allow the search game to be initialized. It would allow an administrator of the game to setup all the parameters necessary to make the game run. The application should allow a search game to be held between two players. The two teams will have a set of agents which will compete between them in order to locate and assemble the items of interest.
2.3 User Characteristics
The intended users for this project are computer literate persons who are experienced in using computers. Users may or may not have experience in using client-server based application. User interaction with the game will be very limited because agents are autonomous.
2.4 Constraints
The followings are constraints for our project: 1. The project shall be delivered by 24th April, 2007. 2. It shall also meet ongoing changes by the customers (Professor and TA) in the project requirements. 3. It is also expected to have changes in project team.
2.5 Assumptions and Dependencies
None.
5
3. Functional Requirements
Below is the list of functional requirements that we could identify for our product up to now: Req. ID FR-1 Description The system shall represent railway stations in the search environment as nodes and railways as edges of a graph. A team of agents shall consist of 1 to 4 agents. Source Project description v 0.1, (additional req. #1) Project description v 0.1, (additional req. #2) Project description v 0.1 (additional req. #3), modified later on by customer Jim Whitaker Project description v 0.1 (additional req. #4) Project description v 0.1 (additional req. #4), modified later on by customer Dr. Rym Mili Project description v 0.1 (additional req. #5) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Project description v 0.1 (additional req. #7) Project description v 0.1 (additional req. #7) Added by customer Dr. Rym Mili (Dated: 02.20.2007)
FR-2
FR-3
The system shall allow two groups of agents to compete against each other in locating, recombining and returning the stolen jewelry.
FR-4
The system shall give each agent 1000 Euros when it is created. The system shall give each agent an additional payment of 200 Euros at any city where an ATM is available only at the first visit.
FR-5
FR-6
When an agent is confronted by an opposing agent, the agent with larger cash-on-hand shall prevail within the system. In case of confrontation of more than 2 agents, the team having more cash-on-hand wins the confrontation. Agents having a cash-on-hand balance of zero are forever dead.
FR-7
FR-8
FR-9
The system shall remove agents having a cash-on-hand balance of zero from map. If an agent having no items-of-interest confront an opposing agent having more cash-on-hand it loses 50 Euros to that opposing agent.
FR-10
6
FR-11
When two agents having same amount of cash-on-hand nothing happens. The system shall provide a static search environment (i.e., Once the search environment is created and setup is done, no changes can be made) The system shall provide full view of the environment to each agent. The system shall allow communication among agents irrespective to their locations in the map. The system shall allow each agent to carry only one item. The system shall end the game once agents in a team meet together and combine the items and announce the player of that team as the winner. The system shall allow admin user to put searchable objects at any node (i.e. city) in the environment. An agent shall be able to see other agents in the environment. The system shall have its own environment.
Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.20.2007) Project description v 0.1, (additional req. #8) Project description v 0.1, (additional req. #9) Project description v 0.1, (additional req. #10) Added by customer Dr. Rym Mili (Dated: 02.20.2007)
FR- 12
FR- 13
FR -14
FR- 15
FR- 16
FR- 17
FR- 18
FR- 19
FR- 20
Agent teams shall be represented by team colors.
FR- 21
Individual agents shall wear a large number on their shirts for easy identification in the visualization. The system shall provide a 2D visualization for the game display. All units shall be calculated in Kilometers (km)
FR- 22
FR- 23
7
3.1 Use Case Diagram
Intelligent Agent Based Search Game
Initialize Game
<< Uses >> Admin
Play Game
Player
Fig 3.1-1: Use Case Diagram
8
3.2 Use Case 1: Initialize
Primary Actor: Admin Stakeholders and Interests: - Player: Wants to take part in the game with a team of intelligent agents. - Admin: Sets up the game rules. Places the search-items, places ATM, places agents and runs the game. Preconditions: Players are logged in and agent setup for each team is complete. Players are identified and authenticated. Success Guarantee: Once the game setup is done, items are search-items and agents are placed in the environment. Also, the admin places the ATMs randomly. Main Success Scenario (Basic Flow): 1. The Administrator sets the game parameters. 2. The Administrator puts the search-items in the environment. 3. The Administrator puts agents in the environment (at most 4 from each of two teams). 4. The Administrator places the ATMs in the environment. Extensions (Alternative Flows): 1. (a) The system crashes during the game.
3.3 Use Case 2: Play Game
Primary Actor: Player Stakeholders and Interests: - Player: Wants to take part in the search game. Preconditions: There is no game running into the system and the players are logged in. Also, the admin already have setup the game. Success Guarantee: Once the game is started, the agents from each side perform automatically and the game ends when the items are combined. Main Success Scenario (Basic Flow): 1. The agents start acting automatically. 2. One of the teams win as the agents in that group combines the search-items.
9
Extensions (Alternative Flows): 1. (a) The system crashes during the game.
3.4 External Interface Requirements
3.5.1 User Interfaces
There shall be a Graphical User Interface for the system. The interface would allow the users (admin and players) to get connected. The GUI would also allow admin user to setup the game and players to start and view the game.
3.5.2 Hardware Interfaces
Not applicable.
3.5.3 Software Interfaces
Not applicable.
3.5.4 Communication Interfaces
The game is client-server based. Users shall connect to the server via TCP/IP interface to retrieve any data or information necessary to setup, start or view the game.
10
4. Non Functional Requirements
Below is the list of non functional requirements that we could identify for our project up to now: Req. ID NFR- 1 Description Unified Process shall be used as the project lifecycle. Source Added by customer Dr. Rym Mili (Dated: 02.20.2007) Added by customer Dr. Rym Mili (Dated: 02.13.2007) Added by customer Jim Whitaker(Dated: 03.29.2007) Added by customer Jim Whitaker(Dated: 03.29.2007) Added by customer Jim Whitaker(Dated: 03.29.2007) Added by customer Jim Whitaker(Dated: 03.29.2007) Added by customer Jim Whitaker(Dated: 03.29.2007) Added by customer Jim Whitaker(Dated: 03.29.2007) Added by customer Jim Whitaker(Dated: 03.29.2007)
NFR- 2
The search game application is required to be implemented in Java language technology.
NFR- 3
The system shall have a fast response time.
NFR- 4
The system shall use the network optimally and give the user seamless experience.
NFR- 5
The code should be reusable.
NFR- 6
The system must be safe to use.
NFR- 7
The system shall be secured and restrict improper access.
NFR- 8
The system shall provide sufficient data privacy and prevent unauthorized disclosure of information.
NFR- 9
The product should have a user-friendly interface.
11
4.1 Product Non Functional Requirements
An incremental approach must be followed to develop the product. UML notations must be used wherever needed to illustrate ideas.
4.2 Process Non Functional Requirements
Rational Unified Process will be used during the various phases of development. Java programming language is required for implementation.
4.3 External Non Functional Requirements
The system must operate within the law and should not produce any violations with other external systems.
12