Clinical Site Candidates s2

[Company Name] [Company Group, Division, Location]

Product Name: [Product Name] Document Title: Software Requirements Specification

Document Number: [Document Number] Document Filename: [Document Filename]

CONTROLLED COPY/ MASTER COPY STAMP HERE

OTHER STAMP HERE

Revision Revision DCO/ECO Revision Level Date Number Description of Revision Author DRAFT DD/MM/Y YY-00000 Draft Author Name Y 1.00 DD/MM/Y YY-00000 Initial Release Author Name Y

COMPANY PROPRIETARY AND CONFIDENTIAL [Company Name] Software Requirements Specification [Company Group, Division, Location] [Document Number] [Product Name] Rev x.xx DD/MM/YY

Table of Contents

1.0 Introduction...... 1 1.1 Purpose 1 1.2 Conventions...... 1 1.3 Intended Audience...... 1 1.4 Structure...... 1 1.5 Supporting Documents...... 1

2.0 System Overview...... 2 2.1 Use Case Analysis...... 2 2.2 System Architecture...... 5 2.3 Computer System...... 5

3.0 System Software Requirements...... 6 3.1 General Features...... 6 3.2 User Interface Requirements...... 6 3.3 Data Management Requirements...... 8 3.4 System Administration Requirements...... 8 3.5 Computer System Requirements...... 9 3.6 Device Interface Requirements...... 9 3.7 Performance Requirements...... 10 3.8 Reliability Requirements...... 10

Table of Figures

Figure 1. High-level Use Cases...... 3 Figure 2. [Product Name] Physical Architecture...... 5 Figure 3. Required Computer System Characteristics...... 9

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 1 of 1 [Company Name] Software Requirements Specification [Company Group, Division, Location] [Document Number] [Product Name] Rev x.xx DD/MM/YY

1.0 Introduction This document defines the requirements for [Product Name] which is intended to [Insert Product Function].

1.1 Purpose The purpose of this document is to define the software requirements for the [Product Name].

1.2 Conventions The “Requirement number” in bold italic precedes lines, which are requirements. Lines, which are not preceded by the Requirement identifier, are explanatory. The numbering is initially done by decades to permit insertion of additional requirements. Requirements that as deleted are marked “{Removed}” to preserve the numbering.

In order to distinguish requirements from narrative text, the word “shall” is used to distinguish each requirement defined in this document. The words “shall not” are used to state explicitly if an item is not required in the PC software.

“TBD” indicates incomplete information necessary to complete a requirement or explanation.

References to “software” in this document refer to the PC software unless otherwise defined.

1.3 Intended Audience It is assumed that the reader of this document has at least a casual familiarity with computer systems and software development methodology.

This document contains confidential information proprietary to Medical Digital Photography, Inc. This document is not to be copied, circulated or substantively discussed without prior written approval.

1.4 Structure This document consists of the following sections:

Section 1 Introduction - This section describes the intent and structure of the document.

Section 2 System Overview - This section gives a broad overview of the system. It is presented in terms of use case descriptions and the system architecture.

Section 3 System Software Requirements - This section describes the requirements for the PC software. It is based upon the information in the System Overview.

1.5 Supporting Documents [Product Name] Software Development Plan

[Product Name] Functional Requirements Specification

[Product Name] User Interface Requirements Specification

2.0 System Overview This section provides the context for the more detailed software requirements specified in later sections. The Use Case Analysis provides a high level view of the major functions provided by the software from all of the system's operational perspectives. The System Architecture summarizes the hardware environment where the software operates and the interfaces to hardware devices that are controlled by the software.

[Product Name] is intended [Insert Product Function].

2.1 Use Case Analysis The use case analysis has two components:

 Key user roles of [Product Name] are identified.

 Primary functions of the [Product Name] required by each of those user roles are defined.

The user roles are referred to as “actors.” The associated primary functions are called "use cases." When a number of use-cases are related - act on or in a similar manner - they are said to "extend" an underlying use-case.

2.1.1 Actors The following Actors are defined for this [Product Name]:

2.1.1.1 Manufacturer [Company Name] employee or representative who assembles and tests [Product Name] for use by Operators.

2.1.1.2 Service Technician Individual trained by [Company Name] to install, configure and service the [Product Name].

2.1.1.3 Operator Runs the [Product Name], capturing images and associated patient data, and communicating data, and installs software version upgrades.

Figure 1. High-level Use Cases

SYSTEM

Installs

Upgrades

MANUFACTURER Starts

Repair Database

IMAGE MANAGEMENT

Capture Images

View Images

Save Images

Transfer Images

Annotate Images

Transmit Images

SERVICE TECHNICIAN Delete Images

OPERATOR Print Images

Import Images

DATA MANAGEMENT

Record Data

Edit Data

Delete Data

Display Data

2.1.2 Use Cases for Operator The operator is primarily concerned with capturing images, recording patient data, and managing information using the [Product Name]. The operator interacts with the [Product Name] via the computer display with a mouse and keyboard. Some uses cases may be easier to perform with the use of a keyboard and mouse. For example screens that require entering alphanumeric characters, such as operator name or a component name, are less tedious with a keyboard. The operator performs all steps involved in capturing, storing, viewing, and communicating still images, motion images, and associated patient data.

2.1.2.1 Starts [Product Name] The operator will rely upon the computer system to automatically start the [Software Name] application software at computer system startup, or under various circumstances may start the [Software Name] application software manually.

 The operator may execute the [Software Name] application software.

 More than one copy of the [Software Name] application software may be started and run at a time on the computer system.

2.1.2.2 Repair the Database The operator has the ability to initiate a database repair function. This function . . . .[Insert the purpose of this function.]

2.1.2.3 Install Software Version Upgrades As required by product corrections or feature enhancements, factory or on-site software upgrade will be required. The operator must insure the proper version of the product is set up. The operator must insure no loss of valuable data .

2.1.3 Use Cases for Service Technician The service technician is primarily concerned with initial installation, upgrades, and maintenance of the [Product Name]. The system is setup and installed on site. The service technician may perform image management and data management functions.

2.1.3.1 Install software version upgrades. As required by product corrections or feature enhancements, factory or on-site software upgrade will be required. The Service Technician must insure the proper version of the product is set up. The Service Technician must insure no loss of valuable data.

2.1.3.2 Configure the [Product Name] Hardware. After software installation, software upgrade, or servicing it may be necessary to set certain system parameters. These may include allocating space for data storage.

2.1.3.3 Service PC software. From time to time, it may become necessary to correct PC software problems. The service technician must be able to diagnose problems. The service technician must isolate and save data while doing any repairs.

2.1.4 Use Cases for Manufacturer The manufacturer is primarily concerned with shipping fully functional, reliable [Product Name]. There are no software requirements for capabilities specific to supporting the manufacturer's use of the [Product Name].

2.1.4.1 Install software version. The service technician installs and configures the software at the factory or on-site. The on-site install may be required to correct computer system problems such as a disk crash. The Service Technician must insure the proper version of the product is set up.

2.2 System Architecture This section provides a brief summary of key aspects of the system architecture to provide a context for the software requirements. It summarizes the hardware environment where the software operates and the interfaces to hardware devices that are controlled by the software. The [Product Name] (Figure 2) is composed of:

 Computer system,

 Input devices for operator interaction with the computer system including: keyboard, mouse, and video processors,

 Display for operator to monitor and review software operations,

 Printer to produce hardcopies of images and text data.

Figure 2. [Product Name] Physical Architecture.

Keyboard Printer

Computer

Mouse Video LAN Processor

2.3 Computer System The computer system is used during all phases of image and data management. It provides a platform for:

 Running the [Product Name] application;

 Interfacing the various external devices; and,

 Viewing and storing images and data.

The computer system utilizes a multi-processing operating system to support concurrent operations. The computer is able to support the number of serial devices required, a combination of user input devices, and, the throughput required to read and write to these devices. The computer system interfaces with the following peripheral components:

 Peripheral #1, and

 Peripheral #2.

3.0 System Software Requirements This section describes all of the requirements that define the [Product Name] software. The descriptions include:

 General requirements that apply to all software components; and

 Device interface requirements.

3.1 General Features The computer system receives images from a video processor or digital camera. Prior to capturing any images the [Software Name] system software must be initialized and the operator must execute the image capture process. When the operator requests shutdown, the system enters Shutdown Phase.

Requirement 10. The [Product Name] software shall automatically start at system boot.

Requirement 20. [Software Name] software shall allow only one copy of itself to execute on the computer system.

Requirement 30. The [Software Name] software shall be ready for operation when the splash screen appears and the operator presses any key to begin.

Requirement 40. The [Software Name] software shall indicate it is ready by displaying the splash screen to the operator.

Requirement 50. The [Software Name] software shall support American English.

The [Software Name] software is ultimately intended for use in multiple countries. Initially, a single language is defined for the product. The [Software Name] software textual information will need to be separately translatable so that other languages may be installed with future releases.

3.2 User Interface Requirements The design of the operator screens will focus on ease of use and comprehension. All screens will be operated via a keyboard, or mouse. Simple controls like oversized buttons, radio boxes, check boxes, sliders, spin controls and selectable lists will be favored over edit controls that require typing in numbers or characters.

Note: Detailed requirements and specification of the user interface are found in the “User Interface Requirements Specification” document.

3.2.1 Service technician Interface Standard installation and maintenance tools provide the Service technician interface - InstallShield, operating system Control Panel and Administration Tools.

3.2.2 Operator Interface The Operator interface encapsulates the system monitoring and control functions. The Operator interface must be easy to comprehend at a glance. The interface is intended to support concurrent test steps. The interface should allow the operator to quickly understand the situation and select the proper controls. The operator should be captured in a single panel with the major modes and subsystems in separate panels that can easily be navigated.

The Operator user interface displays information to support:

 Image management; and

 Data management.

The following types of screens are expected:

 Splash screen;

 Main control screen;

 Screen x;

 Screen y;

 Screen z;

3.2.3 Main Control The Main interface encapsulates interface elements to:

 Launch a data entry screen;

 Transfer data;

 Export patient data;

 Access data;

 Access system utilities;

 Search the database; and,

 Exit the program.

To perform these activities and provide the necessary information, the panel contains a number of user interface elements: buttons and check boxes that allow the selection of detailed information for each function.

Requirement 100. The Main Control panel shall support controlling the items defined in UIRS §4.2 "Main Control panel".

3.2.4 Screen X The Screen X interface (see UIRS §4.3 "Screen X") displays detailed patient data stored on the computer hard drive and allows for the manipulation of such data. In addition, it facilitates the generation of new patient data.

Requirement 110. The Screen X panel shall support viewing the patient information as defined in UIRS §4.3 " Screen X panel ".

3.2.5 Screen Y The Screen Y interface (see UIRS §4.4 " Screen Y panel") allows the operator to manipulate (view, edit, delete, transmit or print) selected data.

Requirement 120. The Screen Y panel shall support viewing the functions as defined in UIRS §4.4 " Screen Y panel ".

3.2.6 Screen Z The Screen Z interface (see UIRS §4.5 " Screen Z panel") allows the operator to view a x file highlighted in the screen y.

Requirement 130. The Screen Z panel shall support viewing images as defined in UIRS §4.5 " Screen Z panel ".

3.3 Data Management Requirements This section defines the requirements for all aspects of data management. These requirements support the storage and retrieval of data. A database or similar facility will be used to provide well-defined, structured storage for patient data. Table 1 enumerates some of the data elements that may be captured during surgical and non-surgical procedures and evaluations.

The data is dynamic. There must be functions to support editing the database. To maintain the integrity of the test database, repair capabilities are provided.

Requirement 400. The [Software Name] software shall maintain persistent information in an online database.

Table 1. [Product Name] Database Elements.

Demographic Data; Medical Data;

3.4 System Administration Requirements

3.4.1 Software upgrade Software version upgrades will be installed by the service technician or operator using a wizard (e.g. InstallShield). Installing a software version upgrade may require a system reboot. There are no requirements for distributing software version upgrades remotely via phone lines, Internet, or other media.

3.4.2 System Power On and Off Requirement 450. When the system is turned on, a [Company Name] [Software Name] splash screen shall be displayed as the system initializes.

There is no requirement to prevent Operating system console information from appearing during startup before or after the [Company Name] [Software Name] splash screen appears. The system will proceed through the normal Operating system startup sequence when power is turned on.

Requirement 460. There shall be a procedure for graceful shutdown of the system.

The shutdown procedure will assure that all files and database information is closed.

3.4.3 [Product Name] Configuration Data The [Software Name] software has a number of configuration values that are set at time of [Software Name] software installation.

Requirement 470. The [Software Name] software shall provide an installation method and persistent storage for a Facility Name.

3.5 Computer System Requirements The [Product Name] will be tested and run in a specific operating environment. This section describes the required hardware and software platform characterstics.

Requirement 500. The [Software Name] computer system shall be configured as defined in Table 2. Required Computer System Characterstics.

Figure 3. Required Computer System Characteristics.

Component Description System Unit IBM [insert unit descriptions here, include model #s] Speed CPU [Insert speed here] Bus Memory [Insert memory here] Ports Connect serial devices: [insert serial devices here] Connect parallel devices: [insert parallel devices here] Storage -- Fixed [Insert hard disk reqs here] Storage – Removable [Insert removable media reqs here] Media Graphics SVGA [insert graphics reqs here] Image Capture [Insert image capture reqs here]

Requirement 510. The [Software Name] operating system shall be Microsoft Windows XP.

3.6 Device Interface Requirements The [Product Name] computer will need software interfaces to a variety of hardware devices to control system-operating behaviors.

Requirement 520. The [Software Name] software shall accept input from an external scanner unit.

Requirement 530. The [Software Name] software shall interface with a [Insert interface unit].

Requirement 540. The [Software Name] software shall interface with [Insert interface unit].

3.7 Performance Requirements The system is expected to:

[Insert specific performance requirements related to system storage capabilities, etc.]

3.8 Reliability Requirements The system is expected to be available on demand. Non-service trained personnel operate it. The system should be reasonably self-sustaining. The system, when restarted, will attempt to diagnose its condition and clean up. Only approved / pre-tested adjunct software will be permitted on the system.

[Insert specific reliability requirements here.]

[Document Filename] COMPANY PROPRIETARY AND CONFIDENTIAL Page 10 of 1