Functional Requirements

F.1 Support user login

Users will specify a name and password.

F.2 Support manual editing of variable records

Concepts supported by the Macaw editor are described in the Business Layer of the design.

F.3 Support searching within the Macaw data entry tool.

Curators will be able to search for specific records using one or a combination of the following search criteria:

search phrase that appears in the variable name or the variable label
date
year
category
whether the variable is a derived or raw variable

F.4 Allow curators to edit ontology terms associated with variables

Data curators will be able to define ontology terms that each include a name, description and URI name space.

F.5 Support batch loading of variables from SPSS files

The application will be able to extract the meta data contained in an SPSS file to populate the database with variable descriptions.

F.6 Create an API that can be used by other software clients that want to access variables.

Developers will be able to retrieve meta data about variables via a Java interface that publishes methods that provide listings for variables, supporting documents, categories and key words.

NF.7 Integrate Macaw with SWIFT

The application will be able to import data from legacy tables in SWIFT which were originally developed to manage meta data. Macaw will also be able to export its entire data set back to SWIFT.

Non-functional Requirements

Non-functional requirements describe aspects of design which are used to evaluate the operation of the system rather than of any one feature.

NF.1 Provenance: Maintain audit trail of changes made to records

The date, userID and description associated with each change will be recorded in a log that is accessible by all users. The audit trail will allow users to review all the changes they've made or all the changes that have been made to a variable. Change listings will appear in reverse chronological order.

NF.2 Testability: The application should support automated testing of major functional units

A collection of automated JUnit test cases will be developed which exercise the functionality published in the API required in F.6.

NF.3: Security: The application should validate users before allowing them to use features.

NF.4 Maintainability: The application should be designed to be maintained by a succession of lone developers.

NF.5 Maintainability: The application should be designed to minimise the effects of long-term technological obsolescence

NF.6 Reusability: The application should be designed so that the requirements, architecture are reusable by other MRC projects

NF.7 Interoperability: The application will support being deployed as either an application or a launchable component.

NF.8 Interoperability: The application will be able to export its data in formats that comply with data standards for social sciences data.

NF.9 Capacity: The application will be able to support concurrent users.

Author: Kevin Garwood