Use Case Requirements

This section lists the requirements for the Clinical Study Tracker alongside the initials of people who proposed them.

Initials	Requirement Author
SR	Sheila Raynor
KG	Kevin Garwood
SL	Susan Latham
IS	Imran Shah
TG	Tim Gaysin
JA	Jane Abington
AW	Andy Wong
JS	Jill Skehan

Functional Requirements

Logging Tool Requirements

LTF-1: Track the progress of case study members through parallel activities, each comprising a sequence of activity steps that are represented by date field values. (SR)
LTF-2: Allow curators to associate each activity record of each case study member with a free-text comment. (SR)
LTF-3: Optionally enforce validation which ensures that date field values for an activity are arranged in non-descending order (IS)
LTF-4: Optionally enforce validation which ensures that in a sequence of activity steps, a populated date field cannot be preceded by a blank date field. (IS)
LTF-5: Every time someone updates a record, the date, author, and description of the change are recorded. (SR)
LTF-6: The application can filter case study records based on filter attributes which themselves are not the subject of curation. Examples include Location and Gender, which are not the curated but which can be used to isolate groups of subjects.(SR)
LTF-7: Filter based on case study records which are complete and incomplete. Complete means each step of each activity has been populated. (SR)
LTF-8: Filter case study records based on whether the date for a given activity step is filled in or left blank. (SR)
LTF-9: Filter case study records based on whether the date for a given activity step is between two dates. (SR)
LTF-10: Filter case studies based on the combinations of any two of the other filters (SR)
LTF-11: Display to the user a status message indicating which active filter is being used and the number of records that match the filter criteria. (SR)
LTF-12: Provide a menu option which describes the clinical study and provides contact details of people associated with it (SR)
LTF-13: Generate a progress bar graph where each bar represents a selected activity step. The height of the bar is represented by the number of subjects which meet specified filtering criteria. By default, the matching criteria are that a subject has a completed value for a specified activity step. (SR)
LTF-13.1: Filter results for the progress graph by records which match a preselected value associated with a given subject attribute (eg: location=Manchester). (SR)
LTF-13.2: Filter results for the progress graph by records which have an activity step date that is between two dates. (SR)
LTF-13.3: Filter results for the progress graph by using a combination of filters specified in LTF-13.1 and LTF-13.2. (SR)
LTF-13.4: Show a coloured bar as well as a number of matching subjects matching the filtering criteria.
LTF-13.5: Alter the order in which the activity steps are represented in the progress graph. (SR)
LTF-13.6: Choose the colour used to represent each activity step in the progress graph. (SR)
LTF-13.7: Label the progress graph with a title. (SR)
LTF-13.8: Show a legend representing the colours associating the name of an activity step with a progress bar. (SR)
LTF-13.9: Write a description of the filtering criteria on the progress graph. Also include the name of the end user and the date the graph was generated. (SR)
LTF-13.10: Save the progress graph as an image file. (SR)
LTF-13.11: Export graph data as a tab-delimited spreadsheet showing all subjects represented at least once in the graph. The spreadsheet would show columns for subject identifier and activity steps represented in the graph. (TG, AW, JA)
LTF-14: Produce a report which shows all the changes made to a specific record in reverse chronological order (SR)
LTF-15: Produce a report which shows all the changes a user has made in reverse chronological order. (JS)
LTF-16: Load and save activity data to and from tab-indented spreadsheets. (SL)
LTF-16: Represent a date field value in the forms through combination boxes corresponding to parts of the date format "dd-MMM-yyyy" (eg: 22-JUN-2008). (SR)

Administration Tool Requirements

ATF-1: Create and Destroy the database. (KG)
ATF-2: Import the identifier and filtering attributes (eg: location, gender) for each subject from a tab-indented list. (SR)
ATF-3: Synchronise the configuration file with the database. Ensure that for each activity and activity step in the configuration file, there is a corresponding table or field in the database (KG)
ATF-4: Be able to add, delete or update login ids. Each id comprises a username and a password. (SR)

Non-Functional Requirements

Maintainability-1: The software suite should
Maintainability-1: The tools should be able to be deployed as both standalone applications and components launched within other software applications.

Author: Kevin Garwood