Senior Design Project
Software Requirements Specification Version 1.0
Senior Design I and II - Spring / Summer 2001
Modification history:
Version | Date | Who | Comment |
Version 0.0 | August 15, 2000 | G. Walton | Artifact Template |
Version 1.0 | April 10, 2001 | Jeff Goodman | Initial Version |
Version 1.1 | April 10, 2001 | Jeff Miller | Added 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:
- Operating System: Our software will run on any UNIX based machine.
- Programming Language: We will be programming in C++
Definitions, Acronyms,
and Abbreviations:
- API: Application Programmer Interface
- SRS: Software Requirements Specifications
- SAF: Semi-Automated Forces
- CGF: Computer Generated Forces
- OTB: OneSAF TestBed
- IST: Institute for Simulation and Training
- STRICOM: Simulation, Training, and Instrumentation Command
- SEECS: School of Electrical Engineering and Computer Science
- DISAF: Dismounted Infantry Semi-Automated Forces
- COTS: Commercial off the shelf
SECTION 2: Product Overview
Assumptions:
- Assumption 1: The network for the surrogate API connection will be a peer to peer network.
- Assumption 2: The computers involved will either have an IP address
or a domain name for connection purposes.
- Assumption 3: There is no system like this currently in use
- Assumption 4: People in industry will want to use a product like this
- Assumption 5: We will have sufficient access in the computer environment that we need
- Assumption 6: We will be able to finish this project by the end of the summer semester
- Assumption 7: We will have an actual robot to do our demonstration with
Stakeholders:
- Stakeholder Client: IST/STRICOM/Dr. R. Franceschini
- Clients interests: Product will be to specifications
and be produced by the end of the summer semester
- Clients Concerns: This product will not damage any very expensive robots while testing.
- Stakeholder Self: Senior Design Group 3
- Self interests: To design a functional project which allows us to practice the knowledge
we have obtained over our educational career
- Self concerns: If we do not finish the project than we will not graduate
Event Table:
Event Name | External Stimuli | External
Responses | Internal 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
- Notes taken during meeting
This page last modified by Jeff Miller (j_miller68@hotmail.com) on April 10, 2001