Midfield Lab 2 SRS

RoboCup Midfield Lab 2

Software Requirements Specification

EEL 4884 Engineering Software Design, Spring 2004

Modification history:

Version	Date	Who	Comment
v0.0	8/15/00	G. H. Walton	Template
v1.0	January 30, 2004	Group	Baseline
v2.0	March 15, 2004	Group	Phase 2 Revisions Added

Team Name: Midfield Lab 2

Team Members:

Marshal Blessing ma187622@pegasus.cc.ucf.edu http://pegasus.cc.ucf.edu/~ma187622
Jesse Rome je458125@pegasus.cc.ucf.edu http://pegasus.cc.ucf.edu/~je458125
Jimmy Secretan secretj@cfl.rr.com http://pegasus.cc.ucf.edu/~jsecreta

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 software to be produced through this project will create a virtual midfield soccer player that will compete as part of a team in RoboCup soccer matches(see RoboCup website). As stated in the Concept of Operations, this player will act as a client to the RoboCup server (see Concept of Opperations). The player will function without input from any user, it will follow all the RoboCup soccer rules, and it will be subject to other constraints placed on RoboCup players, such as vision distance etc. Additionally, it will employ basic soccer strategy consistent with a midfield player.

Reference Documents:

Concept of Operations <include link here>

Robocup Simulated League

Robocup Soccer Server manual (PDF)

Applicable Standards:

C++ Standards

UDP/IP

Robocup Server Commands

Definitions, Acronyms, and Abbreviations:

AI - Artificial Intelligence. Describes methodologies and techniques by which a computer system can simulate intelligent behavior.

UDP/IP - User Datagram Protocol (over) Internet Protocol. A widely used network protocol to send datagram packets. Delivery of the packets is not confirmed as in TCP/IP, reducing the relability but increasing the performance of this network protocol.

SECTION 2: Product Overview

Assumptions:

It is assumed that a functioning server will be provided.

It is assumed that the player's communication code will be provided.

It is assumed that other player clients on the team will exist and function properly.

It is assumed that the hardware used to run the player program will be sufficient to properly execute the program (128MB RAM, 500 Mhz processor, etc.).

Stakeholders:

Marshal Blessing, Jesse Rome, Jimmy Secretan - responsible for midfielder's performance, required to make it function properly
Programmers of Other Team Members - want all players on the team to be compitent and effective soccer players
Gil Barrett - customer, requiring the player's production

Event Table:

Event Name	External Stimuli	External Responses	Internal data and state
corner kick	A player on the midfielder’s team causes the ball to leave the field across the goal line.	Midfielder assumes defensive corner kick position.	State = repositioning
free kick	The server halts the game and awards one team a free kick.	Midfielder assumes a free kick position.	State = repositioning
goal	The ball enters a goal, a goal is scored by one of the teams.	Midfielder returns to default field position.	State = repositioning
goal kick	A player on the opposing team causes the ball to leave the field across the goal line.	Midfielder assumes a goal kick position.	State = repositioning
halftime	The time allotted to the first half of the game elapses.	The midfielder switches sides of the field and returns to default postion.	State = repositioning
kick in	The ball exits the field across one of its sides.	Midfielder assumes kick in position.	State = repositioning
kick off	Play is initiated.	Midfielder tracks the ball’s location.	State = tracking
network failure	Connection to the server is lost.	Midfielder becomes dormant and tries to reestablish a connection to the server.	State = waiting
penalty kick	The server halts the game and award one team a penalty kick.	Midfielder assumes a penalty kick position.	State = repositioning
receives communication from player	The midfielder receives information from another player.	Midfielder continues play.
receives communication from coach	The midfielder receives information from another coach.	Midfielder continues play.
time up	The time allotted to the match elapses.	Midfielder becomes dormant.	State = waiting

Statement: Client should be able to determine its own position on the field.

Use Case Diagram:

Use Case Descriptions:

USERS - the programmers or other external human parties. Usually their interactions are limited to times when the game is not actively being played, such as kickoff.
- Initialize shows that the user has the ability to position their player(s) on the field before gameplay begins. This can be done manually (Manual Position) or using an automatic, predefined positions (Set Position).
- Start indicates the user can give permission to begin gameplay once they have finished positioning players. This also suggests they can with hold permission if they are not finished.
- End means the user has the capability to end the game prematurely (as far as their player(s) are concerned) by disconnecting their clients from the server (Disconnect). This interaction can take place during gameplay.
SERVER
- Broadcast means the server can transmit data to the player client including information about gamestate or communication from other clients.
AI - the program of the player client
- Receive Message shows the player client can receive the information broadcast by the server.
- Send Messageindicates that the player client can transmit information to the server.
- Parse Data means the player client can parse the information it receives from the server.
- Decide shows that the player can use its internal data and the information it receives from the server to choose what its next action should be. This includes the exceptional case where an error has occured and data is missing. It also includes the case of the player client plotting an course to intercept another player or the ball (Plot Course)
- Act indicates the player client can implement the action it selected with decide. This might be done by communicating with the server or waiting for an event. It includes several usecases:
OTHER PLAYERS - other players on the field
- Pass to denotes that other players can pass the ball to the midfielder player client, intentionally or unintentionally.
- Shout to indicates that the other players on the field can communicate to the midfielder player client through the "say" command.
COACH
- Shout to shows that the team's coach can also communicate to the midfielder player client by means of the "say" command.

RCS Server Interface - communication will mainly be performed through a UDPIP communication package

Rule Compliance Verification takes data passed from the AI
- player state data and spoken communication commands pass directly to the command formatter
- action commands that adhere to Robocup soccer rules pass to the command formatter
- action commands that do not adhere to Robocup soccer rules return an error report to the AI
Command Formatter constructs a string in the proper format and passes the data to the RCS Server
Parser receives strings from RCS Server and parses them, then it passes the parsed data to the Interpreter
Interpreter determines the meaning of the data from the RCS Server and passes it to the appropriate AI method

User Interface - communication performed through command prompt

Data on initial position of client, starting, and terminating the game is passed to the AI

SECTION 3: Specific Requirements

3.1 Functional Requirements:

No: 3.1.1

Statement: Client should be able to establish a connection with the server.

Source: Nature of Client/Server relationships.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if player appears on the field.

Revision History: Group; January 30 2004; Baseline

No: 3.1.2

Statement: Client should able to establish a position on the field.

Source: Nature of Client/Server relationships.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if player is in the correct position on the field.

Revision History: Group; January 30 2004; Baseline

No: 3.1.3

Statement: Client should be able to move about on the field by utilizing the dash.

Source: Nature of Client/Server relationships.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if player responds to the test move commands properly.

Revision History: Group; January 30 2004; Baseline

No: 3.1.4

Statement: Client should be able to turn about on the field by utilizing the turn command.

Source: Nature of Client/Server relationships.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if player changes the direction it is facing based on test commands.

Revision History: Group; January 30 2004; Baseline

No: 3.1.5

Statement: Client should be able to see objects on the playing field that are in its field of vision.

Source: Need to be able to see in order to play.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if player changes the direction it is facing based on test commands.

Revision History: Group; January 30 2004; Baseline

No: 3.1.6

Statement: Client should be able to determine its own position on the field.

Source: Need to know own position in order to play.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if player changes the direction it is facing based on test commands.

Revision History: Group; January 30 2004; Baseline

No: 3.1.7

Statement: Client should be able to kick the ball by executing the kick command.

Source: Must be able to move the ball.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if ball is effected by player.

Revision History: Group; January 30 2004; Baseline

No: 3.1.8

Statement: Client should be able to distinguish opposing players from own team.

Source: Need to be able to know who to intercept and who to pass to.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; January 30 2004; Baseline

No: 3.1.9

Statement: Client should be able to verify that there is a clear path to the target of a kick.

Source: Need to be able to know when to kick.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.10

Statement: Client should be able to anticipate steals when kicking.

Source: Need to be able to know when to kick.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.11

Statement: Client should be able to scan for the ball if it is not in view.

Source: Need to be able to find the ball.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to see if player searches for ball.

Revision History: Group; January 30 2004; Baseline

No: 3.1.12

Statement: Client should be able to determine the correct power and angle to accurately kick the ball towards moving targets.

Source: Need to be able to know how to kick correctly.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.13

Statement: Client should be able to pass the ball correctly.

Source: Need to be able to participate in team play.

Dependency: 3.1.9, 3.1.10, 3.1.23, 3.1.12

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.14

Statement: Client should confirm that actions and commands comply with Robocup rules.

Source: Legal Play Requirements.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor to watch for rule violations.

Revision History: Group; January 30 2004; Baseline

No: 3.1.15

Statement: Client should be able to receive data from server.

Source: Necessity for game awareness.

Dependency: 3.1.1

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize data aquisition acknowledgement in test scenarios.

Revision History: Group; January 30 2004; Baseline

No: 3.1.16

Statement: Client must parse data from server.

Source: Necessity to use information from server.

Dependency: 3.1.15

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize data parsing acknowledgement in test scenarios.font>

Revision History: Group; January 30 2004; Baseline

No: 3.1.17

Statement: Client must interpret data parsed from server.

Source: Other modules' need for the data.

Dependency: 3.1.15, 3.1.16

Conflicts: None

Supporting Materials: None

Evaluation Method: Examine interpretation of data.

Revision History: Group; January 30 2004; Baseline

No: 3.1.18

Statement: Client should construct messages in an appropriate format for the server.

Source: Communication needs.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Examine formatted messages.

Revision History: Group; January 30 2004; Baseline

No: 3.1.19

Statement: Client should be able to send preprocessed messages to server.

Source: Communication needs.

Dependency: 3.1.18

Conflicts: None

Supporting Materials: None

Evaluation Method: Examine message sending capabilites in test scenarios.

Revision History: Group; January 30 2004; Baseline

No: 3.1.20

Statement: Client must recognize messages from other players.

Source: Descrimination of incoming audible messages.

Dependency: 3.1.17

Conflicts: None

Supporting Materials: None

Evaluation Method: Examine source recognition in test scenarios.

Revision History: Group; January 30 2004; Baseline

No: 3.1.21

Statement: Client should recognize when an error has occured.

Source: Project specifications.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Observe client actions in test error condition.

Revision History: Group; January 30 2004; Baseline

No: 3.1.22

Statement: Client should act appropriately in the event of an error condition.

Source: Game coherency.

Dependency: 3.1.21

Conflicts: None

Supporting Materials: None

Evaluation Method: Observe client actions in test error condition.

Revision History: Group; January 30 2004; Baseline

No: 3.1.23

Statement: Client should be able to determine the correct power and angle to accurately kick the ball towards stationary targets.

Source: Need to be able to know how to kick correctly.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.24

Statement: Client should manifest determined courses of actions through appropriate control commands.

Source: Need to be able to see to play.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor observe player actions.

Revision History: Group; January 30 2004; Baseline

No: 3.1.25

Statement: Client should be able to shoot the ball at the opposing team's goal.

Source: Need to be able to score points.

Dependency: 3.1.9, 3.1.10, 3.1.23

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.26

Statement: Client should be able to determine an angle to run at, based on target course and avilable stamina.

Source: Need to be able to move efficiently.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.27

Statement: Client should be able to intercept passes.

Source: Need to be able to steal ball from opponent or receive ball from teammates.

Dependency: 3.1.26

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.28

Statement: Client should be able to intercept players.

Source: Need to be able to steal ball from opponent.

Dependency: 3.1.26

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.29

Statement: Client should be able to identify absolute locations on the field.

Source: Need to know absolute locations to reposition self for different game states.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.30

Statement: Client should be able to identify relative locations on the field.

Source: Need to know relative locations to implement formations.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

No: 3.1.31

Statement: Client should be able to run to a specific spot on the field, based on relative or absolute position.

Source: Need to be able to move about correctly.

Dependency: 3.1.29, 3.1.30

Conflicts: None

Supporting Materials: None

Evaluation Method: Utilize the Robocup monitor inspect player's action.

Revision History: Group; March 15, 2004; Phase 2

3.2 Interface Requirements:

No: 3.2.1

Statement: All interfacing to other clients will be done through the Robocup server. The clients will not communicate in any other way.

Source: Robocup rules and regulations.

Dependency: None

Conflicts: None

Supporting Materials: Official Robocup Manual

Evaluation Method: N/A

Revision History: Group; February 2 2004; Baseline

No: 3.2.2

Statement: All of the client's decisions for each game cycle must take fewer than 100ms, as that is the length of the game cycle.

Source: Robocup Manual, seciton 4.8.1.

Dependency: None

Conflicts: None

Supporting Materials: Official Robocup Manual

Evaluation Method: Embed C/C++ standard timing functions in the client program.

Revision History: Group; February 2 2004; Baseline

No: 3.2.3

Statement: All communication with the server will be in the form of Robocup approved control commands.

Source: Robocup Manual, seciton 6.1.

Dependency: None

Conflicts: None

Supporting Materials: Official Robocup Manual

Evaluation Method: Check for server error messages, indicating non-standard messages sent.

Revision History: Group; February 2 2004; Baseline

No: 3.2.4

Statement: Instances of client will be able to communicate through server "hear" and "say" commands.

Source: Coordination Needs.

Dependency: 3.2.1, 3.2.3

Conflicts: None

Supporting Materials: None

Evaluation Method: Use debugging output, that indicates messages have been received from other instances through "hear."

Revision History: Group; February 2 2004; Baseline

No: 3.2.5

Statement: Messages from other instances of the client will be labeled as such and contain coordination information.

Source: Coordination Needs.

Dependency: 3.2.1, 3.2.3, 3.2.4

Conflicts: None

Supporting Materials: None

Evaluation Method: Debugging output to indicate when such messages are received and acted upon.

Revision History: Group; February 2 2004; Baseline

3.3Physical Environment Requirements:

No: 3.3.1

Statement: All of the necessary clients must run easily on a single machine, equivalent to or better than the one on which it was developed: Celeron 800Mhz, 512 Meg of RAM and Linux kernel > 2.4.18.

Source: Customer constraints.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Testing by using “top” to check CPU consumption and by seeing if there is any noticeable latency in communicating with the server.

Revision History: Group; February 2 2004; Baseline

No: 3.3.1

Statement: The machine running the clients must have a reliable UDP connection to the server.

Source: Reliability requirements.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Using a “flood” ping to the server before starting the involved robocup programs. Acceptable packet loss will indicate that the network is sufficient.

Revision History: Group; February 2 2004; Baseline

3.4 Users and Human Factors Requirements:

No: 3.4.1

Statement: The primary user of the system is a Robocup Team owner, who will run as many instances of the program as he needs Midfielders on his team.

Source: Customer specifications, and exemplified by Robocup Client Software.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Starting several instances of the client, running the game.

Revision History: Group; February 2 2004; Baseline

No: 3.4.2

Statement: The system will prevent misuse through restrictions on the user’s actions. This will be relatively simple, as most of the client’s actions are automatic, and the user is left to simply initialize the player’s position.

Source: Robocup Rules of fair and honorable play.

Dependency: None

Conflicts: None

Supporting Materials: None

Evaluation Method: Running client, trying to misuse it and feed it bad information.

Revision History: Group; February 2 2004; Baseline

3.5 Documentation Requirements:

No: 3.5.1

Statement: The Robocup manual should be online.

Source: Need to check server/client specifications and Robocup rules.

Dependency: None

Conflicts: None

Supporting Materials: Official Robocup Manual

Evaluation Method: Verify that the Robocup Sourceforge website is fully-functional.

Revision History: Group; January 27 2004; Baseline

No: 3.5.2

Statement: All of the group templates should be online.

Source: Need to check status of team as a whole; Need to have templates graded by the instructor.

Dependency: The ability to comprehend the templates which describe various aspects of the project require those reading the templates to have some knowledge of Robocup and C++.

Conflicts: None

Supporting Materials: Official Robocup Manual

Evaluation Method: Verify that team website is fully functional through a third-party.

Revision History: Group; January 27 2004; Baseline

3.6 Data Requirements:

No: 3.6.1

Statement: The midfielders should be able to calculate the speed and heading of various objects on the field.

Source: Need to be able to determine course and speed to intercept the ball or opposing players.

Dependency: None

Conflicts: None

Supporting Materials: None(find equations?)

Evaluation Method: Test if the players can properly intercept the ball and opposing players.

Revision History: Group; January 28 2004; Baseline

3.7 Resource Requirements:

No: 3.7.1

Statement: All of the group members should be at least somewhat familiar in the rules of soccer.

Source: Need to have midfielders play properly.

Dependency: The knowledge group members already have, and that which is available as reference material.

Conflicts: None

Supporting Materials: Official Robocup Manual , Rules of the game

Evaluation Method: Run the software and observe if the midfielders play the game properly.

Revision History: Group; January 27 2004; Baseline

No: 3.7.2

Statement: The group should have access to a system with sufficient hardware, and set up to properly run the Robocup client V 9.2.4.

Source: Need to be able to connect the client to the server and have all of the basic functionality for a game to take place.

Dependency: The ENG260 lab staff.

Conflicts: None

Supporting Materials: Official Robocup Manual

Evaluation Method: Test the Robocup server, monitor, and client to see if they are functioning properly and at an acceptable level of speed.

Revision History: Group; January 27 2004; Baseline

No: 3.7.3

Statement: The group members should have adequate experience in C++ programming to complete the project.

Source: Need to complete project.

Dependency: Individual group member experience.

Conflicts: None

Supporting Materials: Common Sense.

Evaluation Method: Test if all functions/classes operate as they should.

Revision History: Group; January 28 2004; Baseline

No: 3.7.4

Statement: The group should have adequate experience in AI programming to complete the project.

Source: Need to complete project.

Dependency: Individual group member experience.

Conflicts: None

Supporting Materials: Common sense.

Evaluation Method: Test if players act like they should on the field.

Revision History: Group; January 28 2004; Baseline

3.8 Security Requirements:

No: 3.8.1

Statement: Only the midfielder programers (Marshal Blessing, Jesse Rome, Jimmy Secretan) shall have access to change the program's source code.

Source: general security needs

Dependency: none

Conflicts: none

Supporting Materials: none

Evaluation Method: inspection

Revision History: Group; January 27 2004; Baseline

No: 3.8.2

Statement: The program's source code shall be backed up in hard copy format.

Source: general security needs

Dependency: none

Conflicts: none

Supporting Materials: none

Evaluation Method: inspection of hard copy

Revision History: Group; January 27 2004; Baseline

3.9 Quality Assurance Requirements:

No: 3.9.1

Statement: The player program shall function without error upon execution.

Source: general functionality needs

Dependency: none

Conflicts: none

Supporting Materials: none

Evaluation Method: inspection of multiple executions

Revision History: Group; January 27 2004; Baseline

No: 3.9.2

Statement: The player program shall function properly for the full duration of a standard soccer match.

Source: general functionality needs

Dependency: none

Conflicts: none

Supporting Materials: RoboCup manuel (pdf)

Evaluation Method: inspection of multiple executions

Revision History: Group; January 27 2004; Baseline

SECTION 4: Supporting Material

Robocup Soccer Server manual (PDF)

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

This page last modified by Jesse Rome (je458125@pegasus.cc.ucf.edu) on 3/15/04