Informal Science Education II
Software Requirement Specifications
EEL 5881 - Software Engineering, Fall 2000
Modification history:
| Version | Date | Who | Comment |
| Version 0.0 | August 15, 2000 | G. H. Walton | Template |
| Version 1.0 | Jeffrey Miller | October 18, 2000 | Initial version |
| Version 2.0 | Michael Wales | November 20, 2000 | More specific requirements |
| Version 3.0 | Michael Wales | December 10, 2000 | Final version |
Team Name: Miles Computer Engineering
Team Members:
Contents of this Document
Definition, Acronyms, and Abbreviations
Definitions, Acronyms, and Abbreviations:
SECTION 2: Product Overview
| Event Name | External Stimuli | External Responses | Internal data and state |
| User starts CA Simulator | User has either executed a .bat file or typed in: java CASim. | Application starts execution and the editor window is displayed. | Program loads all default data structures, initializes the GUI, and displays editor. |
| User loads a previous simulation setup | User goes to file menu, selects open from menu. | Editor clears window and displays the data loaded from the simulation file. | Program opens the file selection dialog, and gets the file to load. The program dereferences all the old data (so the garbage collector will deallocate it from memory), the new data is loaded, and the GUI is updated. |
| User edits the simulation transition properties | User selects Edit simulation transitions from transitions menu and a new window pops up to edit the transitions in. The user then can specify which states have priorities over other states, and modify up to five different types of transitions. We will include some basic types of transitions, and these can later be recoded to more complex transitions. | The program will respond to the user by displaying the transition editing window. Here the user can alter all the transition variables, and click OK to go back to the main simulation window. | The program opens a new GUI window with many different components to change the transition settings. Each class will have a set of text strings that will display and a few text fields that can be edited by the user. When the user clicks OK, the program goes back to the main editor window. |
| User saves simulation state | User selects Save simulation state... and then specifies the filename and path. | After the user clicks Save simulation state... the file selection dialog box appears for the user to specify the save location. | The program displays the file selection dialog box for the user to specify the save location. The program then saves all simulation parameters to disk before going back to the editing window. |
| User edits the source code of the transitions to create a more complex transition condition | The user would look up the included documentation on how the transition class is to set up. The user can then set up the algorithm, recompile the class, and then run the CASim program and use the new conditions. | The program really doesn't have a response for this condition. The coding documentation will be included with the CASim program. | Again, the program really isn't doing much in the case of this event. |
Use Case: Loading Past Simulations
Use Case: Saving current simulation
Use Case: Edit transition properties
Use Case: Simulation
Use Case: Reprogram Transition Algorithm
SECTION 3: Specific Requirements
| Requirement No: 1 |
| Statement: CA tool will have a graphical environment for changing the initial conditions of the simulation. Should have a look and feel similar to a graphics editting program like MS Paint. |
| Source: Meeting #1 |
| Dependency: None |
| Conflicts: None |
| Supporting Materials: None |
| Evaluation method: Functionality |
| Revision History: Version 2.0 |
| Status: Requirement has been met. The editor also has the ability to set large areas of cells to a certain state by dragging a rectangular area with the mouse. |
| Requirement No: 2 |
| Statement: Simulator will have 5 different edittable transition rules. Each rule will have two user inputs that they can vary during experiments. |
| Source: Email |
| Dependency: None |
| Conflicts: None |
| Supporting Materials: None |
| Evaluation method: Functionality |
| Revision History: Version 2.0 |
| Status: Requirement has been met |
| Requirement No: 3 |
| Statement: The CA tool must have a simulation mode that can be reconfigured through the transition parameters. The simulator must also have a mode that the simulation will save the state at a specified interval so that a researcher can start the simulation, leave, and then come back and view the results of the simulation very quickly. |
| Source: Meeting #2 |
| Dependency: Requirement #1 |
| Conflicts: None |
| Supporting Materials: None |
| Evaluation method: Functionality |
| Revision History: Version 1.0 |
| Status: Requirement partially met. The simulation's typically don't last more than a few minutes. The requirement to specify the simulation time were therefore not put into the product. The customer accepted the product in this condition also. |
| Requirement No: 4 |
| Statement: The CA tool must be able to save the simulation state and the transition parameters so that users can load the settings again without having to remember how they were set up for past simulations. |
| Source: Meeting #2 |
| Dependency: Requirement #1 |
| Conflicts: None |
| Supporting Materials: None |
| Evaluation method: Functionality |
| Revision History: Version 1.0 |
| Status: Requirement met. |
| Requirement No: 5 |
| Statement: Each of the transition rules will have source code that is well documented and can be easily editted so that a user who is skilled in Java programming can create their own unique and complex transitioning rules. |
| Source: Meeting #2 |
| Dependency: Requirement #2 |
| Conflicts: None |
| Evaluation method: Functionality and robustness. Will need to be tested with a variety of different transition rules to make sure that the interface works 100% between the simulator and the transition rule. |
| Revision History: New in Version 2.0. Derived from Requirment #2. |
| Status: Requirement met. |
| Requirement No: 6 |
| Statement: The simulator must provide an interface where the user can add states to the simulation. The interface should be set up so that if the user chooses an invalid image for the simulator, it will prompt the user and not cause any harmful effects. |
| Source: Email |
| Dependency: Requirements #3 and #2 |
| Conflicts: None |
| Evaluation method: The interface will be tested with a variety of invalid inputs to make sure the system handles everything in an acceptable manner. |
| Revision History: Missing from Version 1.0, new in Version 2.0 |
| Status: Requirement met. |
| Requirement No: 7 |
| Statement: The simulator will provide an interface to assign a list of precedence of the states. This precedence is required to avoid random results during the actual simulation. |
| Source: Email |
| Dependency: Requirements #2, #3, and #6 |
| Conflicts: When it was realized that there could be possible multiple results from the simulation, we realized we needed this requirement to avoid it. Some emails were with Dr. Moshell regarding how this should be implemented. |
| Evaluation method: The interface will be extensively tested for robustness and functionality. The states precedences can be reversed to ensure that simulation results change. |
| Revision History: New in Version 2.0 |
| Status: Requirement met. |
In addition to the main actions listed above, the software will also be required to be well-behaved. Our program will check inputs for validity before processing them. Our program will also handle file exceptions so that the program doesn't simply crash if it can't find a program.
Our software may interface with an internet browser for the online help system, but the details of the interface have not been investigated. The software isn't expected to interface with anything else.
3.3Physical Environment Requirements:
3.4 Users and Human Factors Requirements:
User describtions and their constraints
3.5 Documentation Requirements:
Documentation Required:
The system will be most easily set up by a user with above average computer experience, and a little bit of programming experience. If the computer does not have the JRE installed the JDK will have to be downloaded, installed, and tested before installing the CASim application. That process will have to be completed by a more advanced user. Simply running the application can be accomplished by a less experienced user. And as mentioned before, if a user wishes to change the algorithm used for the transition properties, that user will need to have good knowledge of Java programming and object-oriented design.
This program will run on most modern desktop computers. The minimum PC requirements would be an Intel 486 processor (or equivalent), atleast 16MB of RAM, a VGA monitor, 600MB of hard drive space, Windows 95, Netscape Navigator or Internet Explorer, CD-ROM, and a mouse. Most of the above requirements are ball park estimates of what Windows 95, the JRE, and the application would need to run effectively. Any system that can support the JRE for Java 2 V1.3 can support our application. There is no support for Java with MS-DOS. Faster CPUs and more RAM could significantly improve performance on most machines.
Software and Hardware Requirements:
There are no security requirements for this program. If backup copies are to be made of the files, the simulation states and transition parameter files should be stored together to properly restore the simulation. If the code is recompiled with new transition classes, the old simulation files on that system will not work in the same manner as before. The user should consider making a new installation of the software in a separate directory when modifying the source code for future simulations.
3.9 Quality Assurance Requirements:
We will work to make sure that the final program is a quality product and that it doesn't have any faults through a very intense debugging and testing process after the software is developed.
One the final code is delivered, the user must work to make sure that any future code modifications are free of errors and bugs. The user should also take care when mixing simulation files from different compilations of the program because they will probably will not simulate in the same manner.
SECTION 4: Supporting Material
NONE
Template created by G. Walton (GWalton@mail.ucf.edu) on Aug 30, 1999 and last updated Aug 15, 2000
This page last modified by Michael Wales (Mag7Rule@aol.com) on December 10, 2000