Writing Software Project Requirements


It is important to carefully consider the proposed program and the experiment, before making a formal request for the program. This ensures that the program is developed as quickly as possible, and does exactly what is required.

When requesting a program, the client should think in terms of what they want, and ignore what they think the computer can do. The client should give an ideal-world list of their requirements, then, the programmer can advise on what is, and what is not, possible.

Misunderstandings between the client and the programmer can be frequent and wasteful. Therefore, it is essential to be clear about what is required of the program. Discussions between the client and programmer are valuable, and should start as early as possible. It is important that the programmer can contact the client at short notice to clarify any issues, and offer prototypes for testing and feedback. Also, it is usual for several prototypes to be produced, so that the client has a better idea of what the final product will look like. It is likely that experimental procedures and parameters will be changed as pilot runs are conducted. This is natural and need not be a problem, providing that the factors most likely to change are identified early in the design.

This develop-demonstrate-develop cycle is known as "rapid prototyping" and is a very useful strategy in a research environment. Whilst it avoids having to predict vague and abstract (or simply unknown) features, it should not be seen as a replacement for careful planning. However, it requires the client to provide feedback to the programmer. Note that if the client is unavailable and no requirements have been given, development may be stopped until the client is available.

Software Features

Specification Changes


Subject Details (Name; Age; Sex; Date of birth)
Indicate all input requirements and the format they should take (i.e. date of birth may be in dd/mm/yy, name may be limited to n characters)
Experiment Details (Experimenter name; Date; Time)
If required, the system clock can set the date and time automatically, or by default (if the user presses a specific button at the prompt).
Other User Prompts (Instructions; Stimulus or results filenames)
If the participant is to be shown a set of instructions, the computer can display these from a text file. This has the advantage that the experimenter is able to change the file without contact with the programmer.
Test Parameters (Number of trials; Number of trial-blocks)
It is usually most convenient to have the test (and trial) parameters read from a stimulus file. The program can request a filename. If none is given the program can abort, or use a random (or pre-defined) set of parameters. The use of a stimulus file enables the experimenter to alter the test without recourse to the programmer. It is helpful to specify minimum and maximum possible values for all parameters early in the design stage.
Test Structure (Practice session; Trials arranged linearly or in blocks)
The computer can present trials in a straight sequence or arranged in blocks of a certain number (e.g. where conditions are being varied between blocks). Also, a practice session can be added, which is merely a number of trials whose results are not saved.
Stimuli Type (Words; Sounds; Images)
The experimenter can specify words, or images to be presented on screen, or sounds to be produced by the PC's speaker. Graphics stimuli are limited to simple line drawings and 2-dimensional shapes (2D representations of 3D can be too complex and slow for reaction-time experiments). Define images in terms of their colour and shape by drawings, etc. They should also have their screen size specified, along with the Inter-Stimulus Interval (ISI). Sounds should have their pitch defined. Text should have its on-screen size defined. All these items must have their duration defined and can be defined from a stimulus file. Note that the best possible resolution for stimulus screen duration is about 15 ms, so a stimulus presentation's duration will be a multiple of this value (which can vary between PCs).
Event Timing (Stimulus presentation times, Reaction times)
The experimenter must specify the events to be timed. Decision time and movement time are the usual measures. Decision time is the time taken from onset of the stimulus, to first reaction of the participant (for example, release of a 'home' button). Movement time is the time taken from the release of the 'home' button to the press of a response button. Reaction time is the addition of these two. Where a 'home' button is not available, reaction time is the only recorded measure. It is necessary to specify the units of the results (seconds, milliseconds).
Additional Hardware (Response buttons, Stereo headphones)
Where stereo (bi-lateral) auditory presentations are required, stereo headphones will be used. Where a specific response button layout is required, a button-pad will be constructed. It should be borne in mind that the keyboard is not ideal as a reaction pad from the psychologist's and programmer's points-of-view. Also, where the duration of graphical stimuli has to be closely controlled, it may not be possible to use the screen. Graphics hardware is not readily available, so such stimuli are limited to on/off indications, though simple 2-dimensional stimuli can be presented with a crude matrix of lights. If the structure of the device is important (position of buttons or stimuli, etc.) then a simple construction diagram giving dimensions should be drawn.
Output Format (Results filename; Data format; On-screen summary)
The computer can prompt the user for a filename in which to store the results from the experiment. The data will be saved in ASCII (text) format is compatible with any editor or word-processor (and SPSS). Specify the SPSS format (fixed or free) general format (for example one line per trial) and the structure of each individual item (for example leading zeros, minimum number of digits). Also specify the meaning of the data items. For instance, if you have a data item indicating whether the correct button was pressed, would you want it to be written in the results file as 'correct/wrong', 'yes/no', or '1/0'. We recommend avoiding the use of correct/incorrect as they look too similar and can be confused when reading long printouts. Also, when specifying what data is to be saved, always err on the generous side. It is always better to have too much information than too little. Any unused information can be easily ignored. Excessive quantity of data is not really a problem as even floppy disks are capable of holding over one hundred files of average size (say 10 KB). Each participant's data files will probably not exceed 20 KB (as a very rough estimate) in size.
Data Analysis (Descriptive statistics, 3S.D. stripping)
Due to pressure of time, we can no longer produce programs to calculate statistics other than simple means. As the results will be in ASCII format, any statistics should be performed with a separate statistics package.
Program Options (Command-line options)
It is possible to add command-line options to tailor the operation of the program. This feature is especially useful for running a program automatically (using batch file programs for instance). These options might include making the program ask for a participant number instead of name, or to skip certain user-prompts such as results filename, age/sex, etc. This allows the programmer to make the program as versatile as possible, while allowing the experimenter to turn off irrelevant features to simplify the participant testing procedure.

Home About Me
Copyright © Neil Carter

Content last updated: 2002-11-06