Informal Science Education II

Software Requirement Specifications

EEL 5881 - Software Engineering, Fall 2000

Modification history:

VersionDateWhoComment
Version 0.0 August 15, 2000 G. H. Walton Template
Version 1.0Jeffrey MillerOctober 18, 2000 Initial version

Team Name: Miles Computer Engineering

Team Members:


Contents of this Document

Introduction

Definition, Acronyms, and Abbreviations

Product Overview

Specific Requirements

Supporting Material


SECTION 1: Introduction

Software to be Produced:

Reference Documents:

Applicable Standards:

Definitions, Acronyms, and Abbreviations:


SECTION 2: Product Overview

Assumptions:

Stakeholders:

Event Table:

Event NameExternal StimuliExternal Responses Internal data and state
User starts CA SimulatorUser 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 setupUser 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 viewingUser 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 propertiesUser 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 stateUser 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 conditionThe 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 Diagram:

Use Case Diagram for Version 1.0

Use Case Descriptions:

Use Case: Loading Past Simulations

  1. User click on Load... from the file menu
  2. User is prompted with the file selection dialog window
  3. User picks path and file, then clicks open
  4. Program dereferences the old data structures and loads the new data structures.
  5. User is brought back to main editor window
Alternative: File not found

Use Case: Saving current simulation

  1. User click on Save... from the file menu
  2. User is prompted with the file selection dialog window
  3. User picks path and file, then clicks save
  4. Program saves the current state of the map, and the current time parameters
  5. User is brought back to main editor window

Use Case: Edit transition properties

  1. User clicks on Edit properties... from the transition menu on the main editing window
  2. Program brings up new window with all the transition properties: list of state order dominance, 5 different transition methods (and their corresponding parameters), and 5 checkboxes (one for each of the transition methods
  3. User fills out and edits the parameters of their choice
  4. User clicks OK when finished
  5. User is brought back to main simulation window

Use Case: Simulation

  1. User clicks on Start simulation from the simulation menu on the main editing window
  2. A window pops up asking the user to tell it how long to simulate for
  3. The program goes through and calculates how the simulation map will change in the next clock cycle
  4. After each clock cycle, the map is redrawn and all the changes are shown for the user to see as the computer processes the next set of changes
  5. Steps 3 and 4 repeat until the simulation reaches the specified time duration
  6. The simulation stops, and the user is simply at the main editor window with the map after the simulation concludes
Alternative: Simulation in away mode

Use Case: Save transition properties

  1. User selects Save transition properties... from the transition menu in the main editor window
  2. A file selection window pops up that user can enter the path and filename to save to
  3. The user then clicks the save button
  4. Program saves the transition property parameters to the file
  5. User is brought back to the main editing window

Use Case: Load transition properties

  1. User selects Load transition properties... from the transition menu in the main editor window
  2. A file selection window pops up that user can enter the path and filename to save to
  3. The user then clicks the load button
  4. Program loads the transition property parameters from the file
  5. User is brought back to the main editing window
Alternative: File not found

Use Case: Reprogram Transition Algorithm

  1. User looks up and reads included documentation on the source code and how to edit it
  2. User can edit the code simply with MS-DOS edit or a Java IDE.
  3. Transition classes are recompiled
  4. Program is run, tested, and debugged until the algorithm works the way it should


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

3.1 Functional Requirements:

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.

3.2 Interface Requirements:

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:

3.6 Data Requirements:

3.7 Resource Requirements:

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:

3.8 Security 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