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 |
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 starts simulation and has the simulator save the results in steps for later viewing | User selects Simulate in away mode from the simulation menu. User then specifies the interval for the simulation to be captured before the simulation starts. | Program steps through the simulation. The simulation displays each time clock in the GUI and saves each state after the specified interval occurs. The simulation continues until it reaches the specified time duration. | The program displays the dialog boxes for the user to fill out the simulation parameters. Then the program goes through the simulation process, and saves the state to disk when it reaches the save interval. This continues until the simulation reaches the specified time duration. |
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 or loads the simulation transition properties | The user clicks on Load... or Save... from the transition menu on the editor. The user then selects the file to load or save. | When the user click Load... or Save... from the transition menu on main editor window, the program brings up the file selection dialog. After the user selects the file, the program performs the specified action. | The program opens the file selection dialog window. When the user selects the file, it will save all the parameters of the transitions that the user has specified. It WILL NOT save the classes used in the program. If the user recodes one of the transitions, the program will load the transition parameters of previous simulations, but they will be parameters for the old class, not the new one. |
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: Save transition properties
Use Case: Load transition properties
Use Case: Reprogram Transition Algorithm
SECTION 3: Specific Requirements
Requirement No: 1 |
Statement: Simulation tool must be able to have initial conditions modified with a user-friendly editor |
Source: Meeting #2 |
Dependency: None |
Conflicts: None |
Supporting Materials: None |
Evaluation method: Functionality |
Revision History: Version 1.0 |
Requirement No: 2 |
Statement: Simulation must have transition parameters that can be easily modified. These transitions should also be able to be reprogrammed later for more complex algorithms. |
Source: Meeting #2 |
Dependency: None |
Conflicts: None |
Supporting Materials: None |
Evaluation method: Functionality |
Revision History: Version 1.0 |
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 |
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 |
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 October 22, 2000