***Software Requirement Specifications Document***

**DOCUMENT CHANGE HISTORY**

  -------------- ----------- --------------- -----------------------------
  Version Number Date        Contributor     Description

  Vx.x                                       

                                             

                                             
  -------------- ----------- --------------- -----------------------------

**\*\* Note to Document Author --** Red *and blue* text in this document
is directed at the template user to list process, build standards and
help build the document. The text should be removed before submitting
any formal documentation, including both draft and/or final,
deliverables. **\*\*\*\***

![](media/image1.jpeg){width="3.3333333333333335in"
height="0.9861111111111112in"}

TABLE OF CONTENTS

Background/Summary [3](#backgroundsummary)

Introduction [3](#introduction)

Document Overview [3](#document-overview)

Related documents [3](#related-documents)

Application System Diagram [4](#application-system-diagram)

Application Core Data [4](#application-core-data)

Release Overview [4](#release-overview)

Definitions [4](#definitions)

caBIG requirements [5](#cabig-requirements)

Vocabularies and Data Elements [5](#vocabularies-and-data-elements)

Environment [5](#environment)

Application Functional Requirements
[6](#application-functional-requirements)

New user creation and login [7](#new-user-creation-and-login)

New User Registration [7](#new-user-registration)

Logging into the System [7](#logging-into-the-system)

Retrieving Forgotten Password [7](#retrieving-forgotten-password)

Contacting Administrator [8](#contacting-administrator)

APPLICATION QUALITY (aka NON-functional) requirements
[8](#application-quality-aka-non-functional-requirements)

GUI Specifications [13](#gui-specifications)

Security Requirements this is one of the QRs
[13](#security-requirements-this-is-one-of-the-qrs)

Audit this is a Functional Requirement (or multiple FRs) associated with
one or more non-user actors and should therefore be documented as part
of a Use case Specification
[15](#audit-this-is-a-functional-requirement-or-multiple-frs-associated-with-one-or-more-non-user-actors-and-should-therefore-be-documented-as-part-of-a-use-case-specification)

Database schema how did we get to this relaitvely low-level
design/implementation level in an SRS?
[16](#database-schema-how-did-we-get-to-this-relaitvely-low-level-designimplementation-level-in-an-srs)

Requirement Change Management [17](#requirement-change-management)

GLOSSARY [17](#glossary)

# Background/Summary

\<\<Insert project background and summary information\>\>

# Introduction

## Document Overview

The System Requirements Document (SRS) document includes detailed
functional requirements for the system on 'what' are the behaviors based
on specified end-user use cases as well as non-functional requirements
such as GUI, quality & performance, usability and system behavior
requirements that directly or indirectly impact the system.

\<\<Insert document overview information and approach in developing the
Requirements to meet the key project goals. Please describe your
methodology for both Functional and Quality Requirements\>\>

##  Related documents

*\<\<Insert other reference document(s) with location\>\>*

  ------------------ --------- -------------------------------------------
  Document Name      Version   Location

  Vision & Scope               
  doc.                         

  Use Case                     
  Specification Doc.           

  Requirement                  
  Traceability                 
  Matrix                       

  Architecture Doc.            

  Quality                      
  Requirements                 
  Specification                
  Document                     
  ------------------ --------- -------------------------------------------

### Application System Diagram

*\<\<Insert block diagram that depicts the different functional units of
the system and the actors who perform those functions. Add reference to
architecture document for more info. If applicable.\>\>*

*I think we should require that this document be expressed in UML, e.g.
Deployment Digram, etc. so that all documentation becomes representable
in standardized normenclature.*

### Application Core Data

*\<\<Insert core data categories and/or dependencies with access
privileges.\>\>*

## Release Overview

\<\<Insert the scope and objectives of the project with release
information.\>\>

  ----------------- ----------------- -----------------------------------
  **Release**       **Date Released** **Version comments**

                                      

                                      

                                      
  ----------------- ----------------- -----------------------------------

## Definitions

Developers and Adopters are expected to clearly understand on the
definitions and agree upon the ranking of the definitions used with any
given requirement.

**MUST** - This word means that the definition is an absolute
requirement of the specification.

**MUST NOT** - This phrase means that the definition is an absolute
prohibition of the specification.

**WILL** - This word means that the definition is an absolute future
requirement of the specification.

**WILL NOT** - This phrase mean that the definition is an absolute
future prohibition of the specification.

**SHOULD** - This word means that there may exist valid reasons in
particular circumstances to ignore a particular item, but the full
implications must be understood and carefully weighed before choosing a
different course.

**SHOULD NOT** - This phrase means that there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or
even useful, but the full implications should be understood and the case
carefully weighed before implementing any behavior described with this
label.

**MAY** - This word means that a requirement is truly optional. The
developer may choose to include the item based on the needs of their
design.

# caBIG requirements

*\<\<Insert common requirements that may have direct dependency and/or
constraint to build standards and inherit requirements from caBIG
requirements. For examples, see below. \>\>*

### Vocabularies and Data Elements

  -------- ---------------- ------------------------------------------------
  **R#**   **Req. Name**    **Requirement details**

                            

                            

                            
  -------- ---------------- ------------------------------------------------

### Environment

All caBIG projects must be platform and database-independent
applications. In the case of caTISSUE Core, it means it should be
possible to run it on any operating system, should support any database
and should work on any web browser.

However, considering the large number of combinations of test scenarios,
caTISSUE Core must at least be certified on the following scenarios:

  ---------------- ------------------------------------------------------
  **Operating      Solaris 2.8
  system**         

                   Windows 2000, NT, XP

                   Linux

  **Database**     Oracle 9*i*, 10*g*

                   MySQL 4.1

  **Browser**      Netscape 7 and above

                   Internet Explorer 5 and above

  **Java**         1.3.1 and above
  ---------------- ------------------------------------------------------

  ------ ----------------- --------------------------------------------------
  **R    **Environment**   **Application must support the environments
  \#**                     outlined in above table**

                           

                           

                           

                           
  ------ ----------------- --------------------------------------------------

# Application Functional Requirements

\<\<Insert application specific requirements that may have
direct/indirect dependency and includes ALL user workflow. Add reference
to Use Case Specification document as appropriate and include all the
use cases in the functional requirements. Please list each requirement
for each step of the workflow. \>\>

\<\<Use or refer to responsibility based UML activity diagrams including
the documentation of ObjectsWithState (datagrams) that occur between
activities and lists dependencies with Forks if applicable to split and
merge into two parallel processes.\>\>

**\*\*Note: Some examples are listed on the following pages. The
formatting should be mimicked.\*\***

![](media/image2.png){width="5.25in" height="4.058333333333334in"}

## New user creation and login

*\<\<Insert description of this functional section. See below for an
example.\>\>*

This section describes the requirements for the following four
functionalities:

1.  Registration of new users

```{=html}
<!-- -->
```
1.  Logging into the system

2.  Retrieving forgotten password

3.  Reporting a problem without logging into the system

### New User Registration

*\<\<Insert description\>\>*

The following requirements describe this process of ........

  ------ ------------- ---------------------------------------------------
  **R    **Req. Name** **Requirement details**
  \#**                 

                       

                       

                       
  ------ ------------- ---------------------------------------------------

### Logging into the System

*\<\<Insert description\>\>*

The following requirements describe this process of Logging into the
System:

  -------- ---------------- ------------------------------------------------
  **R#**   **Req. Name**    **Requirement details**

                            

                            

                            
  -------- ---------------- ------------------------------------------------

### Retrieving Forgotten Password

*\<\<Insert description\>\>*

The following requirements describe this process

  -------- ---------------- ------------------------------------------------
  **R#**   **Req. Name**    **Requirement details**

                            

                            

                            
  -------- ---------------- ------------------------------------------------

### Contacting Administrator

\<\<Insert description\>\>

The following requirements describe this process

  ------ ------------- ---------------------------------------------------
  **R    **Req. Name** **Requirement details**
  \#**                 

                       

                       

                       
  ------ ------------- ---------------------------------------------------

# APPLICATION QUALITY (aka NON-functional) requirements

\<\<Insert application specific non-functional (Quality) requirements
that may have direct/indirect dependency. Non-functional requirements
include GUI specifications, Security requirements, Performance criteria,
availability requirements, etc. Quality Requirements, in order to be
testable and verifiable must have an associated Fit Metric and a given
QR may have a Use Case-specific FM, i.e. may be associated with multiple
UCs, each with a different FM (e.g. Performance or Usability QRs often
have different FMs depending on the specifics of the associated UC).\>\>

Please refer to below list of the 18 common quality requirements that
may be associated with functional requirements and/or use cases.

1.  Availability

*Definition: The amount or percentage of time that the System is
available for use by the users.* *Availability may be negatively
impacted by a variety of events including, but not limited to, user
error, hardware failure, external system events, unavailability of
support personnel, etc.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

Rank:

## 

2.  Compatibility

*Definition: The ability of the System under discussion to appropriately
interact with others systems in its context.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

## 

3.  Completeness

*Definition: For the domain of the System, the allowable maximum number
or percentage of errors of omission.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

4.  Correctness

######## Definition: The allowable maximum number or percentage of errors of commission 

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

## 

5.  Cost of ownership/Return on Investment

*Definition: The total costs (direct and indirect) of owning the
System.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

## 

6.  Environmental

*Definition: The environmental conditions in which the System must
function*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

7.  Extensibility

*Definition: The use of the System in the same context with additional
functionality.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

8.  Installation Complexity

*Definition: The combination of direct or indirect costs of the
installation of the System*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

## 

9.  Parallel Processing

*Definition: The ability of the System to fulfill requirements
simultaneously using duplicated rather than shared resources.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

10. Performance

*Definition: A measure of user expectations of System response times.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

11. Portability

*Definition: The ability of the System to fulfill its requirements in
more than one operating environment.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

12. Regulatory

Definition: The specific regulation(s) with which the System must be
compliant.

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

13. Reusability

*Definition: The use of the System in a different context with the same
functionality*.

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

14. Scalability

*Definition: The ability of the System to fulfill its requirements for
increasing numbers of users, transactions, etc*.

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

15. Security

*Definition: The requirements of the System with respect to access
control and/or other context-specific security rules and or
regulations.*

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

16. Time To Market

*Definition:* The statement of the time at which the System must become
available to and operable by its intended users.

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

17. Training Complexity

*Definition:* The combination of direct or indirect costs for the
training of the System's users.

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

18. Usability

*Definition:* The measurement of how often, how efficiently, and/or
correctly people use the System.

Statement of Requirement:

**\
Fit Metric/Success Criteria:**

**Rank:**

Some examples are listed below.

**\<\<***IF quality metrics have been used within Use Cases, please
refer to those with detailed fit metric***.\>\>**

## GUI Specifications

The following is a list GUI requirements to include the design, layout
and usability.

  -------- ------------- ----------------------------------------------------
  **R#**   **Req. Name** **Requirement details**

                         

                         

                         

                         

                         
  -------- ------------- ----------------------------------------------------

## Security Requirements this is one of the QRs

*\<\<Insert security requirements based on user roles and
responsibilities. \>\>*

The following table contains the different kinds of user groups. (For
example see below.)

+------------+---------------------------------------------------------+
| **Admin    | -   Is a \"super-user\" who manages the application     |
| istrator** |                                                         |
|            | -   Has privileges to submit, edit, disable, and query  |
|            |     all types of data in the system.                    |
|            |                                                         |
|            | -   Approves and manages user registration process.     |
|            |                                                         |
|            | -   Has a privilege to add and modify a new module.     |
|            |                                                         |
|            | -   Has a privilege to see all the identified data.     |
+------------+---------------------------------------------------------+
| **Su       | -   Is similar to Administrator but does not have       |
| pervisor** |     access to administrative functions.                 |
|            |                                                         |
|            | -   Has a privilege to submit, edit and disable         |
|            |     participant and module data in the system.          |
|            |                                                         |
|            | -   Has read only privilege to administrative data.     |
+------------+---------------------------------------------------------+
| **Te       | -   User role assigned to an individual who is          |
| chnician** |     in-charge of entering data into the system.         |
|            |                                                         |
|            | -   Handles curation, storage and distribution of       |
|            |     samples.                                            |
|            |                                                         |
|            | -   Has access to only de-identified data.              |
+------------+---------------------------------------------------------+
| **C        | -   User role assigned to an individual responsible for |
| ollector** |     the physical collection of samples.                 |
|            |                                                         |
|            | -   Is not expected to use the system and hence does    |
|            |     not have any access privileges                      |
|            |                                                         |
|            | -   Will be used only to fill the COLLECTED_BY data     |
|            |     element of collection event parameter of that       |
|            |     specimen.                                           |
+------------+---------------------------------------------------------+
| **Public** | -   Anyone having general research interest             |
|            |                                                         |
|            | -   Has read-only access to aggregate data              |
+------------+---------------------------------------------------------+

Table 1

Application must address following security privileges by using the
caBIG CSM module.

+----+------------+---------------------------------------------------+
| ** | **Req.     | **Requirement details**                           |
| R# | Name**     |                                                   |
| ** |            |                                                   |
+----+------------+---------------------------------------------------+
| Re | System     | Application must address system wide privileges   |
| q. | level      | by creating predefined roles and by assigning     |
| \# | Privileges | appropriate privileges to the roles. Error:       |
|    |            | Reference source not found lists the predefined   |
|    |            | roles and associate privileges.                   |
+----+------------+---------------------------------------------------+
| Re | P          | Application must address proprietary privileges   |
| q. | roprietary | by assigning the read only permission on          |
| \# | Privileges | proprietary data to specific user or group of     |
|    |            | users.                                            |
|    |            |                                                   |
|    |            | Note that the default security assignment is that |
|    |            | all actors can view all de-identified records and |
|    |            | that the owner of the data would need to specify  |
|    |            | that the data is not "global view" and have to    |
|    |            | restrict view to designated users.                |
|    |            |                                                   |
|    |            | For example, When an actor (clinician) registers  |
|    |            | a COLLECTION PROTOCOL then view privileges for    |
|    |            | that COLLECTION PROTOCOL and all children objects |
|    |            | (SPECIMEN COLLECTION GROUP, SPECIMEN, SPECIMEN    |
|    |            | EVENTS) can be restricted to specific actors      |
|    |            | (clinicians, scientists). The exception is the    |
|    |            | administrator actor and other actors defined as   |
|    |            | technicians/supervisors.                          |
+----+------------+---------------------------------------------------+
| Re | Regulatory | Application must address regulatory privileges by |
| q. | Privileges | reveling only de-identified data to unauthorized  |
| \# |            | user.                                             |
|    |            |                                                   |
|    |            | For example, an actor (clinician) enters a        |
|    |            | PARTICIPANT onto a COLLECTION PROTOCOL. The       |
|    |            | clinician has access to all identified            |
|    |            | information for that PARTICIPANT, but does not    |
|    |            | have access to identified information for other   |
|    |            | PARTCIPANTs or to identified information for that |
|    |            | same PARTICIPANT with respect to a different      |
|    |            | COLLECTION PROTOCOL                               |
+----+------------+---------------------------------------------------+
| Re | Cascading  | It must be possible to propagate the privileges   |
| q. | Privileges | down in the hierarchy for the children objects    |
| \# |            | when a particular privilege is applied to its     |
|    |            | parent object.                                    |
|    |            |                                                   |
|    |            | For example, READ permission on a COLLECTION      |
|    |            | PROTOCOL enables the READ permission to all       |
|    |            | specimens collected under that protocol.          |
+----+------------+---------------------------------------------------+

  ------------------- ------------------- ------------------ --------------------
  **Role\\Data**      **Administrative    **Participant      **Biospecimen Data**
                      Data**              Data**             

  **Administrator**   Add / Edit / View   Add / Edit / View  Add / Edit / View

  **Supervisor**      Identified View     Add / Edit / View  Add / Edit / View

  **Technician**      De-identified View  De-identified View Add / Edit / View
  ------------------- ------------------- ------------------ --------------------

## Audit this is a Functional Requirement (or multiple FRs) associated with one or more non-user actors and should therefore be documented as part of a Use case Specification

The system must be possible to audit each and every user action that
results in database access (read or write). Examples include: add/edit
administrative or biospecimen data, user login, query, distribution, and
so forth.

The audit information must contain the following information:

1.  User who performed the action

```{=html}
<!-- -->
```
1.  IP address of the computer from which the action is performed.

2.  Timestamp of action

3.  Object and data element (i.e. table name and column name)

4.  Previous value and current value of the data element

\*\* Note that the audit table must contain one entry per data element.
In case of some use cases like edit or disable, there might be more than
one entry in the audit tables per user action. For example, user updates
more than one data element in one edit action.

\<\< Sample constraint: The administrator is the only actor who has
access to read the audit data. The administrator will use the query
interface to read the audit data.\>\>

  -------- ------------- ----------------------------------------------------
  **R#**   **Req. Name** **Requirement details**

                         

                         

                         

                         

                         
  -------- ------------- ----------------------------------------------------

## Database schema how did we get to this relaitvely low-level design/implementation level in an SRS?

\<\<A script must be supplied to create the application Core database
schema in an automated manner. The script must create all the necessary
objects like tables, indexes, tablespaces, and any other database
constraints. A separate script for each adopter should be supplied for
creation of default users, roles and access privileges that is required
for setting up the dependant setup and schema.\>\>

The following are the requirements foe the database schema:

  -------- ------------- ----------------------------------------------------
  **R#**   **Req. Name** **Requirement details**

                         

                         

                         

                         

                         
  -------- ------------- ----------------------------------------------------

# Requirement Change Management

\<\<Insert detailed process and workflow to manage change in
requirements. See table example below for details that are required.\>\>

The following is the change configuration log for this document:

  ------------ ------------- -------------- ---------- --------------------- ------------
  **Date**     **Submitted   **Change       **Change   **Change Details**    **Status**
               By**          type**         ID**                             

  02/08/2006   K. Holland    Modification   RCM_1      RC_Login_002 --       Approved
                                                       Modified the          
                                                       requirement to allow  
                                                       unregistered users to 
                                                       view only records.    

                                                                             

                                                                             

                                                                             
  ------------ ------------- -------------- ---------- --------------------- ------------

# GLOSSARY

\<\<Insert data definitions used for the application.\>\>

  --------------------------- -------------------------------------------
  **Term**                    **Definition**

                              

                              

                              

                              

                              

                              

                              

                              

                              
  --------------------------- -------------------------------------------