SRS Template

Robocup: Killer Forwards

Software Requirements Specification

EEL 4884, Spring 2004

Modification history:

Version	Date	Who	Comment
v0.0	8/15/00	G. H. Walton	Template
v1.0	1/27/2004	Kristen Cannava, Rob Pescatore, Kip Carr	Initial information added
v1.1	3/16/2004	Kristen Cannava, Rob Pescatore, Kip Carr	Information for Phase 2 added

Team Name: Killer Forwards

Team Members:

Kristen Cannava Email Kristen's Webpage
Kip Carr Email Kip's Webpage
Robert Pescatore Email Rob's Webpage

Contents of this Document

Introduction

Software to be Produced
Reference Documents
Applicable Standards

Definition, Acronyms, and Abbreviations

Product Overview

Assumptions
Stakeholders
Event Table
Use Case Diagram
Use Case Descriptions

Specific Requirements

Functional Requirements
Interface Requirements
Physical Environment Requirements
Users and Human Factors Requirements
Documentation Requirements
Data Requirements
Resource Requirements
Security Requirements
Quality Assurance Requirements

Supporting Material

SECTION 1: Introduction

Software to be Produced:

The work product or deliverable for this project will be the creation of the forwards for team robocup. This will involve designing and coding the AI to run the forwards to mimic the behavior of an actual group of forwards on a regular soccer team. The coding will be done in C++, using a forwards class. We will use the forwards class as a base, and inherit from it to give the forwards generic characteristics of soccer players, through which we will modify to perform other tasks. The forwards should be able to chase the ball in an organized manner, as they are the attacking or offensive group on the soccer team. Also the forwards should be able to pass, shoot, and intercept. Further modifications could include running plays.

Reference Documents:

Concept of Operations

Applicable Standards:

We are going to use the following standards:
- Coding Standard: C++
- Robocup Communication Standard: To be implemented by Robocup
- Internet Communication Standard: UDP/IP

Definitions, Acronyms, and Abbreviations:

UDP - User Datagram Protocol
IP - Internet Protocol
x86 - Any IBM compatible computer
PC - Personal computer

SECTION 2: Product Overview

Assumptions:

The software will be designed and created on a UNIX/Linux operating system.
Assume Robocup Server will be functioning and monitor will be displaying as specified in the Robocup Manual.
Hardware client software is running on a machine that is sufficient to not lag behind in terms of processing power or memory.
Robocup Server and client will be on a network that has sufficiently low latency as to not produce lag or any other hindering factors.
Other Robocup Team members will behave according to their positions and not interfere with the forwards function.
The Robocup Team will be running a 3/4/3 formation and that we are responsible for three forwards.

Stakeholders:

The members of this team are interested in the success of this particular section of the project, namely the creation of three functioning forwards for the soccer team.
The members of the other teams comprising the rest of the soccer have an interest in our part of the project succeeding, in so much as it does not interefere with their portions and functions on a certain level of satisfaction.
The instructor of this course also would like to see a successful creation of each portion of the team.

Event Table:

This table is an overview of the various commands and responses that our software is expected to handle.

Event Name	External Stimuli	External Responses	Internal data and state
ClientStart	Client software is started by the user and connects to the server.	Client software is started	Client boots up..begins routines
Broadcast	Server sends broadcast message	React to broadcast message accordingly	Parse message, run relevant procedure
SendMsg	Decision is reached by client to perform action, result needs to be sent to server	Sending the UDP message to the server	Create message with respect to UDP protocol and ready it for transport
RecvMsg	Receive UDP message from Server	Send message as coach communication, player communication, etc	Send message to parse routine to be evaluated
ParseMsg	Receive generic message from server	Send message back to server with appropriate decisions	Parse the message
RecvServMsg	Server sends message to client regarding ball and player positions	Issue appropriate command	Parse message, run relavent procedure
RecvCoachMsg	Coach issues or 'yells' command	Issue appropriate command	Parse message, run relavent procedure
RecvPlayMsg	Player shouts to other players	Issue appropriate command	Parse message, run relavent procedure
Kickoff	The game begins	Forwards move to appropriate positions	Begin running forward offensive routines, chase ball, etc.
Goal	A goal is scored by either team, referee announces to players	Forwards will move to positions based on kickoff left or right	Forwards use move command to teleport to their respective positions
OutofField	Ball goes out of field, Referee moves ball to appropriate position	Forwards, depending on field position, will either perform the cornerkick, kickin or goalkick.	Forwards run check routines to decide whether or not they will perform the kick.
Foul	Foul occurs, Referee moves ball to appropriate position	Forwards, depending on field position, will either perform a freekick.	Forwards run check routines to decide whether or not they will perform the kick.
HalfTime	Referee suspends the match	Forwards wait for second kickoff	Forwards don't not run any routines and simply wait for kickoff message from referee
TimeUp	Referee ends the match unless teams are tied	The client will terminate if the game is done, otherwise Forwards will play the extended half as normal until first goal is scored by either team	The client will be terminated in the first case, at which time the Forwards will no longer be on the playing field. Otherwise Forwards may behave as normal during the extended half, or perhaps switch to sudden death mode which would be a more aggresive mode of play

Use Case Diagram:

Use Case Descriptions:

The use cases match the events. Please see Event Table for descriptions.

SECTION 3: Specific Requirements

3.1 Functional Requirements:

No: 101

Statement: The software shall parse information from soccer server.

Source: Messages must be parsed to understand meaning.

Dependency: 201

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Program will respond correctly from parsed message.

Revision History: Team 1/27/2004 Version 1.0

No: 102

Statement: The software shall understand communication from the coach to the players.

Source: Coach is vital resource to players decision making abilities.

Dependency: 101

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Verify player understands commands from coach.

Revision History: Team 1/27/2004 Version 1.0

No: 103

Statement: The software shall understand communication from another player to the current player.

Source: Inter-player communication is vital to decision abilities.

Dependency: 101

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Verify player understands commands from other players.

Revision History: Team 1/27/2004 Version 1.0

No: 104

Statement: The player shall acknowledge kick-off and move to appropriate position.

Source: The game cannot start until kick-off.

Dependency: 101

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player moves to appropriate position after kick-off.

Revision History: Team 1/27/2004 Version 1.0

No: 105

Statement: Player shall move around the field.

Source: Player needs to be able to chase the ball and run plays.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player moves around the field after kick-off.

Revision History: Team 1/27/2004 Version 1.0

No: 106

Statement: Player shall pass the ball to another player.

Source: Player needs to be able to pass the ball to another player.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player passes the ball to another player.

Revision History: Team 3/16/2004 Version 1.1

No: 107

Statement: Player shall verify a clear path before passing or shooting.

Source: Player needs to be able to verify a clear path before passing or shooting.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player only passes or shoots the ball if they have a clear path.

Revision History: Team 3/16/2004 Version 1.1

No: 108

Statement: Player shall lead a target player while passing.

Source: Player needs to be able to lead a target player while passing.

Dependency: 101 and 104 and 106

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player leads a target player while passing.

Revision History: Team 3/16/2004 Version 1.1

No: 109

Statement: Player shall anticipate players stealing the ball.

Source: Player needs to be able to anticipate players stealing the ball.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player anticipates other players stealing the ball.

Revision History: Team 3/16/2004 Version 1.1

No: 110

Statement: Player shall intercept passes and players.

Source: Player needs to be able to intercept passes and players.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player intercepts passes and other players.

Revision History: Team 3/16/2004 Version 1.1

No: 111

Statement: Player shall run to a specific spot on the field.

Source: Player needs to be able to run to a specific spot on the field.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player runs to a specific spot on the field.

Revision History: Team 3/16/2004 Version 1.1

No: 112

Statement: Player shall handle all fouls and game states.

Source: Player needs to be able to handle all fouls and game states.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player handles all fouls and game states.

Revision History: Team 3/16/2004 Version 1.1

No: 113

Statement: Player shall kick the ball towards the goal.

Source: Player needs to be able to kick the ball and make a goal.

Dependency: 101 and 104

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Player kicks the ball towards the goal.

Revision History: Team 1/27/2004 Version 1.0

3.2 Interface Requirements:

No: 201

Statement: Client software shall handle broadcasts from the server.

Source: Client software needs to receive and interpret messages from server.

Dependency: 202 and 203

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: To ensure broadcast messages are received properly.

Revision History: Team 1/27/2004 Version 1.0

No: 202

Statement: Client software shall communicate with server every millisecond.

Source: The server communicates with client software at this rate.

Dependency: None

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Verify communication is received.

Revision History: Team 1/27/2004 Version 1.0

No: 203

Statement: Client software shall be able to communicate asynchronously.

Source: Soccer server communicates asynchronously.

Dependency: None

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: To ensure broadcast messages are received properly.

Revision History: Team 1/27/2004 Version 1.0

3.3 Physical Environment Requirements:

No: 301

Statement: The software shall run on a x86 compatible PC.

Source: Soccer server and soccer monitor utilize the Linux operating system.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the software on x86 PC.

Revision History: Team 1/27/2004 Version 1.0

No: 302

Statement: The program shall run in an environment that is suitable for the operation of a computer.

Source: If the operational conditions aren't met the computer system may malfunction.

Dependency: 301

Conflicts: None

Supporting Materials: None

Evaluation Method: Test the computer in the environment.

Revision History: Team 1/27/2004 Version 1.0

No: 303

Statement: The computer shall be in room 260 of the Engineering building.

Source: Computers are loaded with correct software needed.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: We will be running the software on the computers.

Revision History: Team 1/27/2004 Version 1.0

3.4 Users and Human Factors Requirements:

No: 401

Statement: The system shall accomodate the users.

Source: The team members will operate the client software on the system.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Run the software.

Revision History: Team 1/27/2004 Version 1.0

3.5 Documentation Requirements:

No: 501

Statement: All documentation shall be online and printed for approval by customer.

Source: Customer requires documentation.

Dependency: None

Conflicts: None

Supporting Materials: Customer's webpage

Evaluation Method: None

Revision History: Team 1/27/2004 Version 1.0

No: 502

Statement: Audience shall have knowledge of Robocup and minimal engineering knowledge.

Source: To comprehend the documentation.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Audience can understand documentation.

Revision History: Team 1/27/2004 Version 1.0

3.6 Data Requirements:

No: 601

Statement: Client shall calculate trajectoies and velocities.

Source: Knowledge needed for good plays.

Dependency: 101

Conflicts: None

Supporting Materials: None

Evaluation Method: Plays are performed correctly.

Revision History: Team 1/27/2004 Version 1.0

3.7 Resource Requirements:

No: 701

Statement: There shall be consistent power to the client computers for proper functioning.

Source: For consistent function of the client computers.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Client computers run properly and consistently.

Revision History: Team 1/27/2004 Version 1.0

No: 702

Statement: The client shall require one computer literate person to start the client software.

Source: Client requires human intervention to start.

Dependency: None

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Client software has started properly.

Revision History: Team 1/27/2004 Version 1.0

No: 703

Statement: Client computer shall be equipped with Linux.

Source: Robocup is Linux based.

Dependency: None

Conflicts: None

Supporting Materials: Robocup Manual

Evaluation Method: Compatible with Robocup server.

Revision History: Team 1/27/2004 Version 1.0

3.8 Security Requirements:

No: 801

Statement: Morality of other participating teams shall be required for maintaining integrity of communications.

Source: Proper function of client software and reliable communications.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Client software runs without interference from other participants.

Revision History: Team 1/27/2004 Version 1.0

3.9 Quality Assurance Requirements:

No: 901

Statement: Client software shall run consistently without frequent crashing.

Source: For proper function of client software.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Client software runs crash free.

Revision History: Team 1/27/2004 Version 1.0

No: 902

Statement: Software shall be easily updateable for new features.

Source: Additional functionality may be required.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Program is easy to modify for additional functionality.

Revision History: Team 1/27/2004 Version 1.0

SECTION 4: Supporting Material

Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000

This page last modified by Team (Email) on March 16, 2004