Senior Design Project

Software Requirements Specification Version 1.0

Senior Design I and II - Spring / Summer 2001

Modification history:

VersionDateWhoComment
Version 0.0August 15, 2000G. WaltonArtifact Template
Version 1.0April 10, 2001Jeff GoodmanInitial Version
Version 1.1April 10, 2001Jeff MillerAdded more requirements/Changed into html

Team Members:


Contents of this Document

Introduction

Definition, Acronyms, and Abbreviations

Product Overview

Specific Requirements

Supporting Material


SECTION 1: Introduction

Software to be Produced:

The software that we will produce is an interface for a simulation to implement control of a robot. We will also create a surrogate system that will mimic the activities of a robot for testing purposes. We will be producing an API that will talk with the user interface and the SAF. The API will also track the position of the robot at all times. The robot should also send regular updates on its status back to the API The interface that we are creating will be an XWindows GUI which will be able to have an instance of the API built in. The interface will accept controls from the arrow keys on a standard keyboard, and will display the current position of the robot. The robot surrogate that we are producing will communicate with the API over a network, and minic the actions of an actual robot.

Reference Documents:

Applicable Standards:

Definitions, Acronyms, and Abbreviations:


SECTION 2: Product Overview

Assumptions:

Stakeholders:

Event Table:

Event Name

External Stimuli

External ResponsesInternal data and state

Use Case Diagram:

Use Case Descriptions:

Use case name
Participating Actors
Entry condition
Flow of events
Exit condition
Specail requirment


SECTION 3: Specific Requirements

3.1 Functional Requirements:

No: 1
Statement: The system shall control a robot
Source: Discussion with Dr. R. Franceschini
Dependency: Requirement 2
Conflicts: None
Supporting Materials:
Evaluation Method: Functionality
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001


No: 2
Statement: The surrogate system shall act as a robot
Source: Discussion with Dr. R. Franceschini
Dependency: Requirement 1
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001


No: 3
Statement: The API must communicate with the surrogate using a standard network protocol
Source: Discussion with Dr. R. Franceschini
Dependency: Requirement 1 Requirement 2
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


No: 4
Statement: The GUI must display the current motion and position of the robot.
Source: Discussion with Dr. R. Franceschini
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


No: 5
Statement: The API must contain commands for move forward, turn left, turn right, move backwards, increase speed, decrease speed, stop.
Source: Discussion with Dr. R. Franceschini
Dependency:Requirement 1 Requirement 2
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


3.2 Interface Requirements


No: 6
Statement: The GUI and the OTB will communicate with the API using the same interface
Source: Discussion with Dr. R. Franceschini
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Code Review to make sure we are following through on this
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


No: 7
Statement: The human interface or the OTB shall input the action for the robot to take.
Source: Discussion with Dr. R. Franceschini
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001


3.3 Physical Environment Requirements

No: 8
Statement: There should be room for the robot to move around if a robot is being used
Source: Experience with robots
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001


No: 9
Statement: There either a wireless network, or long network connection if a robot is being used.
Source: Experience with robots
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


3.4 Users and Human Factors Requirements

No: 10
Statement: Users must familar with how to control a game like interface with a standard keyboard
Source: Experience with game like interfaces
Dependency:All Functional Requirements
Conflicts: None
Supporting Materials: None
Evaluation Method: Test how comfortable people are with the interface we build
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


3.5 Documentation Requirements

No: 11
Statement: Code Must be well documented approximately 1 comment for every 4 lines of code, this must is a requirement because this project will be expanded upon by future programmers
Source: Experience debugging
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Readability of Code
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


No: 12
Statement: All documents must be printed to hand in and put on the Senior Design Team 3 website
Source: Senior Design Handout
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Print Documents
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001


3.6 Data Requirements

No: 13
Statement: The system must be accurate enough that if the user tries to turn the robot so it does not hit a wall, the robot turns immediately.
Source: Discussion with Dr. R. Franceschini
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001


No: 14
Statement: Commands for the API must be easy to edit, preferably at lookup table or something with similar functionality
Source: Discussion with Dr. R. Franceschini
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.1, Jeff Miller, April 10, 2001


3.7 Resource Requirements

No: 15
Statement: The person maintaining the system must understand C++
Source: Discussion with Dr. R. Franceschini
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Functionality
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001


3.8 Security Requirements
None

3.9 Quality Assurance Requirements

No: 16
Statement: The system should be reliable due to testing all possible cases to ensure correctness of the software
Source: Discussion between team members
Dependency:None
Conflicts: None
Supporting Materials: None
Evaluation Method: Testing Time
Revision History: Revision 1.0, Jeff Goodman, April 10, 2001

SECTION 4: Supporting Material


This page last modified by Jeff Miller (j_miller68@hotmail.com) on April 10, 2001