Download A Flexible 3D-Visualisation Engine With Force

The 'Flight' Simulator
Page 19 of 117
5 Requirements Definition
The Requirements Specification Document (Appendix A) details the high-level requirements of the
system as a whole. The Architectural Design Document (Appendix C) shows the high-level design of
the Flight system, giving an overview of its constituent parts. The requirements definition stage of the
project takes these high level requirements, and distributes them to the necessary components of the
system. Each component is then examined in greater detail, and requirements may be added or refined.
After this process each component should have a set of requirements, which it must fulfil in order to
satisfy those described in the Requirements Specification document. (Note that some requirements
from the requirements specification will not appear here. For example, the need for an introduction
screen resulted in the EDSSplash component, but will not result in any further requirements. Note also
that the Flight Task Language absorbs many requirements.)
This section gives a brief overview of the requirements of each component in the system. The
Requirements Definition Document (see Appendix D) provides full descriptions of these requirements.
Note that these requirements were discovered at various stages of the project. As new functionality
was required, the Requirements Specification and Architectural Design Documents were updated, and
then the Requirements Definition was performed again, distributing the requirement to the relevant
component (or components). To save time and space, however, the requirements are given here in their
final form.
5.1 Flight Requirements
The Flight process is the main component of the Flight system, and actually performs the simulation.
When launched, the program should configure itself with a task selected by the user. The name of this
task will be extracted from the 'task.ini' file.
The user should be able to exit the simulation at any time. Control over the graphical settings of the
simulation should be available, along with control over an external view and its position. The program
should also allow the user to rewind, pause, and fast-forward any Controls which are reading their state
from disk.
The simulation itself should provide support for particles (such as smoke), structures, terrain, fogging,
force feedback effects, and graphical models of the Controls.
During the simulation, the joystick should operate as documented by the author of the main Control.
No concrete requirements can be formed here, but descriptions of the standard Controls are available in
Appendix K.
5.2 FlightLoader Requirements
The FlightLoader component will be a Visual Basic program, providing a graphical user interface to
the system. The program should display a list of available tasks, and a method should be provided
whereby the user can refresh this list (in order to include task files added while the program is running).
The user should be able to perform simple editing of task files, as well as copying, renaming and
deleting these task files. The user should have the ability to view the 'trace.log' file from a previous
simulation run.
The user should be able to initiate the simulation, after choosing a task to perform. In this case, the
program should write the name of the selected task to the 'task.ini' file, before launching the FlightLink
program. This program will synchronously launch the EDSSplash process, followed by the main Flight
simulation process. During this time, the FlightLoader program will continue to operate.
The program should terminate on request from the user.
5.3 FlightLdr Requirements
The FlightLdr component will be a simple loader program, used as a front end to the Flight system on
machines without Visual Basic runtime support. The program should display a list of tasks available to
Douglas Currie