InSitu Behavioral Procedure Testbed

User Requirements

InSitu Home

About

Project Plan

User Requirements

Scenarios

System Architecture

Technical Requirements

Downloads

Site Change Log

Overview
Feature Summary
Project Phases

Overview

For the moment this is a collection of user oriented features, functional and otherwise, of the In Situ Behavioral Procedure Testbed. These are only the high level user oriented features, and will be technical only insofar as the technical details are visible to users of the testbed. Developer-level technical requirements can be found (eventually) in the Technical Requirements section.

This feature list is one way of looking at requirements. Feature lists are good for summarizing what is in a product (or needs to be in a product), and describing the feature, but they do not do a good job of illustrating why the feature is needed or why the user needs it. The usage Scenarios page will show how a feature will be used. Ultimately, no feature should appear here as a "Must Have" unless it is also in a "Must Have" scenario.

User characteristics are described in the Market Analysis section of the Project Plan. All user requirements found in this document are based on those characteristics.

The user level features will have to be prioritized; grouped into useful and implementable subsets; and assigned to project phases. Each project phase will serve as user requirements for a development phase.

Feature Summary

For the time being, this subsection is being used to collect a list of all of the user features that we can think of, along with any description or comments. Features are tentatively broken down into three categories: "Must Have", "Should Have", and "Nice To Have". Features with a category are listed in no particular order.

Must Have

These features are absolutely required. Product cannot be used, maintained, released, etc., without them.

Ownership and Support

Community Based: All project plans, features, architectures, designs, implementations, and so on, will be maintained by an interested community, freely available to all, owned by none, with all participating in the project to the ability of their skills, resources, needs, etc. No liability will be assumed by members of the community.
Downloadable Source & Binaries: Human readable and machine executable versions for supported platforms will be available as free downloads.

Usable

Centralized Communications: Testbed will provide means of interconnecting components in a controlled manner for an installation.
Centralized Data Collection: Testbed will provide means of logging and otherwise collecting experimental/simulation data in a centralized manner for an installation.
Centralized Control: An In Situ installation will provide a control panel for control and monitoring of experiments.
Parameterized Pre-built Models: Will provide a set of behavioral models for common types of simulations; pre-built models will be customizable via configuration parameters.
Parameterized Pre-built Procedures: Will provide a set of behavioral procedures for common types of schedules of reinforcement and other procedures; procedures will be customizable via configuration.
Data Exportable in Common Formats: Data collected by the system will be exportable in formats for data analysis systems used by the market (e.g., spreadsheet formats, ...).
Time/Event Based: Interaction of modules will be time and event based. All logging, messaging, etc., will include time stamps, event identification, and any necessary event data.
User Definable Events: Users will be able to define events without modification to In Situ testbed code.
Standardized Configuration Format: Configuration files will use a popular structured format for which there are widely available parsing and validation capabilities (e.g., XML).
Simple Module Templates: For cases in which user code must be plugged in, source for simple, easy to use, adaptors will be provided in a variety of computer languages. Users will paste their code (or otherwise integrate it) with whatever adaptation might be required to match the call interface.

Extensible

Componentized: Users can plugin or otherwise connect their own behavioral models and procedures without recompiling, relinking, or otherwise rebuilding the In Situ testbed; at most a platform specific adaptor will have to be built.
Computer Language Independent: Interfaces will be provided for the most popular languages used by the market (e.g., C, C++, Objective C, Java, Pascal, Basic, Snobol, Lisp, Smalltalk, Python, Perl, TCL).
Defined Component Interfaces: Interfaces via which users plugin their components will be well defined, stable, clearly documented.
Common Module Interface: All modules, whether they implement behavioral models or behavioral procedures, will use the same interface so that they may support inter-module simulations in which social behavior or group behavior is simulated.
Modules Limited Only By Interface: A module may do anything, so long as it satisfies the module interface; that is, a behavioral "model" may be an algorithm, a hardware adaptor, or anthing else.
Behavioral Model Customizable: User may integrate her/his own behavioral model into InSitu for testing.
Behavioral Procedures Customizable: User may integrage her/his own behavioral procedures for testing her/his own, or any other, behavioral model.

Deployable

Platform Independent: To the degree practical, will be available for, or portable to, at least the most common desktop computing systems used by our market.
Architecture Independent: Will not be dependent upon a particular computing architecture.
Interoperable: Testbed installations, components, etc., will be able to freely interact with each other, or read/write each other's data without external converters, adaptors, etc.

Reliable

Robust: Misbehaving user components will only affect the experiment(s) of which they are part; failure of the testbed will not affect other applications on the machine on which they are running.
Troubleshooting Support Built-In: While In Situ will be optimized for efficiently running simulations, it will also include troubleshooting or problem detection facilities that are configurable and/or controllable via the UI (e.g., trace logging, expanded informational message logging, debug message logging).

Should Have

These are features that would greatly enhance functionality or usability, but which are not necessarily part of the core functionality. The product will be usable without these features, but would be more useful and easier to use with them. The product can go out the door without these features.

Modules Location Independent: Modules may all be on the same machine as each other and the testbed controller, or all components may be on separate machines, or any combination in between.
Security: Only registered users of an installation may interact with a networked installation. Unauthorized attempts will be logged.
Real Time: The testbed will be capable of running in a soft real time mode that will allow it to control experimental sessions with live organisms, given that the appropriate hardware interface modules are written.
Restartable: If the user's behavioral model provides the optional save/restore functionality, a terminated session will be restartable from the point of (a) controlled termination, or (b) the last "checkpoint".
Multiple Subjects: Will support multiple subject experiments/simulations, include such as social behavior; group contingencies,
Multiple Concurrent Evaluations: Support multiple experiments/simulations simultaneously.

Nice To Have

These are features that we would like to have, but whose absence will not significantly reduce the usability or functionality of the product. They may be added should a low-cost opportunity arise; a volunteer wishes to do them above all else; etc.

Process Control Language: In addition to allowing users to plug in code to implement stimulus generation modules (i.e., procedures), a textual state oriented process control language will be provided.
Process Control Visual Programming: In addition to the textual process control language, a visual programming environment will be provided for development of stimulus generation modules.
Automated Evaluation: Testbed will provide a means of defining expected behavior of a model, and evaluating how well the observed behavior fits the expected behavior.