# caBIG Software Requirements and Specification Template

DOCUMENT CHANGE HISTORY

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

  1.0          November 2004  Draft

  1.1          March 2005     Added Sign-Off Page
  ------------ -------------- -------------------------------------------

*\[The first objective of the Software Requirements and Specification
Document (SRSD) is to capture the complete software requirements for the
system, or a portion of the system. The SRSD should fully describe the
external behavior of the application or subsystem identified. It also
should describe nonfunctional requirements, design constraints and other
factors necessary to provide a complete and comprehensive description of
the requirements for the software.*

*\[The second objective of the SRSD is to describe the design of the
requirements. It describes the design decisions, architectural design,
and the detailed design needed to implement the software. The SRSD is
used as the basis for implementing the software. It provides the
acquirer visibility into the design and provides information needed for
software support.*

*Template Instructions:*

*Throughout this template there are many italicized text areas
surrounded in brackets \'\[\]\', similar to these instructions. These
areas either prompt for user entry or provide instructions for
completing the section. **Delete** each bracketed text area after
completing the document. If a section title is italicized and surrounded
in brackets '*\[\]*', i.e.* \[*Notes*\]*, this indicates that the entire
section is **optional**.*

*Areas in regular text are standard wording that may not require
modification.*

***Q5 Disease Classification by Mass Spectrometry Pattern Recognition
Developer Project / 79761CBS10\]***

***Q5 R Plug-in Release 1.0***

Software Requirements and Specification Document

**Version 1.1**

***\[Insert approval date of document\]***

Document Change Record

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

  1.0           *\[Insert      Initial draft document
                approval date  
                of document\]* 

  1.1                          Added Technical Details to document
  ------------- -------------- -------------------------------------------

TABLE OF CONTENTS

1\. caBIG Software Requirements and Specification Template
[i](#cabig-software-requirements-and-specification-template)

2\. Introduction [1](#introduction)

2.1 Related Documents [3](#related-documents)

2.2 Scope [3](#scope)

2.2.1 Identification [3](#identification)

2.2.2 System Overview [4](#system-overview)

2.2.3 Document Overview [6](#document-overview)

2.3 Reference Documents [6](#reference-documents)

3\. Project Description [7](#project-description)

3.1 Project Perspective [7](#project-perspective)

*3.2 Project Functions* [7](#project-functions)

3.3 User Characteristics [8](#user-characteristics)

3.4 Constraints [8](#constraints)

3.5 Qualification Provisions [10](#qualification-provisions)

3.6 Assumptions and Dependencies [10](#assumptions-and-dependencies)

4\. Requirements [11](#requirements)

4.1 Datafile Handling [11](#datafile-handling)

4.2 Analysis Routines [12](#analysis-routines)

4.3 Analysis Output [13](#analysis-output)

5\. System Architecture [14](#system-architecture)

6\. Components [15](#components)

6.1 q5 [15](#q5)

6.2 mzXML [17](#mzxml)

6.3 normalize [18](#normalize)

6.4 pcaProject [19](#pcaproject)

6.5 pca [20](#pca)

7\. \[*NOTES*\] [21](#notes)

8\. Sign off [22](#sign-off)

8.1 Approval [22](#approval)

9\. Appendix A -- Acronym List [23](#appendix-a-acronym-list)

10\. \[*Appendix B -- Other Appendices*\]
[24](#appendix-b-other-appendices)

# Introduction

This SRSD captures the complete software requirements for the *Q5
software* and describes the design decisions, architectural design and
the detailed design needed to implement the software. It provides the
acquirer visibility in to the design and provides information needed for
software support.

The Q5 application is a probabilistic classification algorithm that
employs principal components dimension-reduction and linear discriminant
analysis.

Q5 has shown utility in disease classification of expression-dependent
proteomic data from mass spectrometry of human serum. Q5's ability to
classify complex fragment mixtures was evaluated by testing its ability
to discriminate the mass spectra of healthy vs. disease human serum
samples. The two disease states examined in testing were ovarian and
prostate cancer. Existing screening methods for both cancers carry a low
positive predictive value (PPV). When detected early, the 5-year
survival rate increases for both cancers.

Q5 outputs a classifier (discriminant) capable of classifying new mass
spectra into one of the classes. The new spectra (called test spectra)
that have not been seen by the algorithm and their classifications are
unknown to the algorithm; the goal of the Mass Spectra Classification
Algorithm (MSCA) is to determine the correct classification based on the
classifier constructed from the training set. Classification
verification is the testing process by which the discriminant is
evaluated for its ability to correctly diagnose test samples. MSCAs can
be characterized by the type of MS data processed, type of algorithm
employed, and method of classification verification used.

**Completeness of mass spectrum.** Analysis may be performed on either
complete or partial mass spectra. Complete mass spectra consist of the
relative intensities of all m/z values acquired during MS data
collection. This includes the relative intensities observed for all m/z
values from 0 up to the upper limit of detection. An MSCA that processes
complete mass spectra works with the entire recorded spectra: no values
are "manually" excluded through preprocessing. When portions of a
spectrum are excluded from consideration, we say a partial spectrum is
generated.

**Heuristic vs. Exact Classification Algorithms.** Heuristic
classification algorithms include approaches such as genetic algorithms,
neural networks, and simulated annealing. These algorithms generally
require multiple iterations to converge to a classifier; furthermore,
the solution found by heuristic algorithms is not guaranteed to be
optimal. In addition, many heuristic approaches are non-deterministic.
Even when run on the same training set, the same non-deterministic
algorithm often converges to a different discriminant. In contrast,
MSCAs that utilize closed-form exact solutions (CFES) compute an exact
solution using closed-form equations. CFES algorithms are
computationally efficient; they are non-iterative and deterministic
(i.e., always compute the same solution). Linear Discriminant Analysis
(LDA), and thus Q5, are CFES algorithms.

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

## Related Documents

The current Q5 distribution contains a set of Matlab (Mathworks Inc,
Natick, MA) functions. Q5 is presently written entirely in Matlab.

Reference: Ryan H. Lilien, Hany Farid, and Bruce R. Donald.
\"Probabilistic Disease Classification of Expression-Dependent Proteomic
Data from Mass Spectrometry of Human Serum.\" Journal of Computational
Biology, 10(6) 2003, pp. 925-946.

Q5 Use Case Scenarios (2005)

## Scope

The overall scope of the Q5 Disease Classification by Mass Spectrometry
Pattern Recognition Developer Project / 79761CBS10 is to reproduce the
Q5 algorithm currently implemented in the Matlab software, a proprietary
software package, into the open source software environment of R (a GNU
Project implementation of the proprietary S software package developed
originally at Bell Laboratories).

Initially the software will be implemented under the category of a tool,
however the intent of the overall process is to make the Q5 software a
service. This category redefinition will occur when the Fox Chase LIMS
piece is implemented. This will require update to this document and
utilization of not only a base UML document of the programmatic flow and
interfaces but usage of the CDE and formal review by the VCDE upon
implementation of this functionality. We hare hoping to work directly
with the Fox Chase group to ensure that the data elements are in sync to
the caBIG vocabulary but in line with the caBIG grid as a whole.

For more information about the R software package please refer to the
url: http://www.r-project.org/

### Identification

**Abbreviations:**

-   Q5 Software Project - Abbreviated reference to the \"Q5 Disease
    Classification by Mass Spectrometry Pattern Recognition Developer
    Project / 79761CBS10\"

-   OHSU - Oregon Health and Science University

### System Overview

The Q5 software outputs a classifier (discriminant) capable of
classifying new mass spectra into one of the classes( such as healthy
vs. disease). The new spectra (called test spectra) that have not been
seen by the algorithm and their classifications are unknown to the
algorithm; the goal of the Mass Spectra Classification Algorithm (MSCA)
is to determine the correct classification based on the classifier
constructed from the training set. This method was originally outlined
in the paper by Ryan H. Lilien, Hany Farid, and Bruce R. Donald.
\"Probabilistic Disease Classification of Expression-Dependent Proteomic
Data from Mass Spectrometry of Human Serum.\" Journal of Computational
Biology, 10(6) 2003, pp. 925-946.

The current adopter site for the software is targeted as Oregon Health
and Science University and they will be performing the user acceptance
and initial usage functions. The development group is composed of
various members of the Computational Genetics Laboratory and other
members of the Dartmouth Medical School.

The development site for the software will be located at the Norris
Cancer Cotton Center located in Lebanon, N.H. and Dartmouth College with
initial user testing and deployment at the OHSU site.

This development effort will utilize a \"modified waterfall method\" of
software development with the SDLC phases being:

-   Risk Analysis Assessment

```{=html}
<!-- -->
```
-   Base Analysis (Both system level and interfaces)

-   Requirements gathering

-   Development of use case scenarios

-   Base prototype conversion of the current Q5 algorithm functionality

-   Requirements release for final software development

-   Development of test cases

-   Implementation of the software for testing

-   Execution of system test cases locally for validation

-   Execution of use cases externally for validation

-   Software release documentation and training

**Software Development Life cycle Flow:**

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

The Major Components of the R version of Q5 will consist of the
following:

-   Base Q5 algorithm developed as an R software plug-in

-   Reading of a standardized datafile of mass spectrometry data (to be
    defined)

-   Output of a project determined standardized format for analysis
    results

-   Connectivity to the Fox Chase LIMS server located at Dartmouth
    Research Computing Resource as a mechanism for input/output source
    for the mass spectrometry data.

### Document Overview

This SRSD captures the complete software requirements for the Q5
software release 1.0 as part of the Q5 Software Project.

*This document should be considered as a mechanism to outline the
requirements for design of the Q5 software. For detail regarding the
algorithm itself, please refer to the original paper outlining the
algorithm as referenced in section 2.1.*

The remaining SRSD sections are organized as follows:

-   **Section 2. Project Description**: Describes the general factors
    that affect the Q5 Software Project.

```{=html}
<!-- -->
```
-   **Section 3. Requirements**: Describes all the software requirements
    to a level of detail sufficient to enable designers to design a
    system to satisfy those requirements, and testers to test that the
    system satisfies those requirements.

-   **Section 4. Notes:** Contains general information that aids in the
    understanding of this document.

-   **Appendix A. Acronym List:** Defines the abbreviations used on the
    project.

## Reference Documents

For additional project, and requirement specific information, refer to
the following documents:

-   Ryan H. Lilien, Hany Farid, and Bruce R. Donald. \"Probabilistic
    Disease Classification of Expression-Dependent Proteomic Data from
    Mass Spectrometry of Human Serum.\" Journal of Computational
    Biology, 10(6) 2003, pp. 925-946.

-   Q5 Project Use Case Scenarios

# Project Description

## Project Perspective

\[Describe the relationship of the software products or projects.
Describe the hardware and peripheral equipment with which the project
operates.\]

![](media/image3.png){width="5.350694444444445in" height="4.05625in"}

The structural architecture is outlined in the graphic depicted above.
The Q5 software will run within the R Software framework as a module.
This software package supports installations to Unix (and variants), Mac
and Windows operating systems as to make it cross platform usable.

## *Project Functions*

> NCCC and Dartmouth have performed research on disease classification
> by spectrometry pattern recognition. The tie of clinical proteomics
> programs to patient diagnosis and the monitoring of treatments is in
> early stages of technology development and substantiation. Valid early
> detection protocols in identifying the presence or absence of
> cancerous cells will increase patient survival rates and extend their
> life expectancies by hastening appropriate management of treatable
> malignancies. Proteomic profiling of cancer cells exposed to
> experimental therapies will provide critical information in designing
> treatment regiments and discovering therapeutic targets. To address
> this challenge, researchers at Dartmouth have developed Q5, a Mass
> Spectrometry Classification Algorithm (MSCA) that is a combinatorially
> precise algorithm cast in closed-form equations and therefore provides
> a means to compute an optimized solution for disease classification.
> Q5 is designed to distinguish between plasma profiles of normal and
> disease-bearing individuals. Currently, Q5 is available as a MatLab
> application.
>
> NCCC will apply an internally developed mass spectrometry pattern
> recognition tool, Q5, designed to distinguish between plasma profiles
> of normal and disease-bearing individuals. Ultimately, NCCC aims to
> deliver rapid disease classification method for dozens of neoplastic
> and other diseases through further development of Q5. Support for Q5
> development with caBIG technologies and standards will facilitate the
> participation of institutions in data analysis.
>
> To date, the Q5 algorithm method has been developed, evaluated and
> applied by one research group at Dartmouth. The current implementation
> uses MatLab for statistical calculations. For this project, Q5 will
> (1) Be translated to open source; (2) Be deployed to the Adopter
> site(s) for analysis; (3) Be adapted to the caBIG architecture.

## User Characteristics

The primary target user audience identified by the caBIG adopter (OHSU)
site has been the role of a bio-statistician with assistance for
software installation via a bio-informatics specialist.

Bio-statisicians and bio-informatics personnel at OHSU will be
evaluating the output of the analysis routines for accuracy.

Developers located at the Dartmouth site will be performing unit testing
on code produced for the Q5 project.

## Constraints

1.  External Software Dependencies

The R software Project page supports operating system releases for Max
OS (System 8.6 to 10.2.x and above) as well as Linux and Microsoft
Windows(95 and later). The source code for the R software is available
for the software for compilation on additional platforms as well.

The R software was selected as a natural candidate due to the great
number of inherent statistical functions already readily available to
the language allowing possible additional statistical analysis of the
results set via the use of the internal graphing functions. Finally, the
compatibility of R to other toolsets and development languages might be
used in structuring an \"end to end\" workflow for analysis of the data
by the given site using the product.

Presently the only dependencies are the inclusion of the PROcess,
caMassClass and MASS modules to be loaded. These packages can be
retrieved at the CRAN (Comprehensive R Archive Network) or the
BioConductor R repository.

When loading the packages for Q5, the order of precedence should be
PROcess, caMassClass and then Q5 (which will call MASS if already
installed)

The Q5 Project has identified the R software version 2.1.1 to be the
target environment for development of the Q5 R script.

**[Data Standards:]{.underline}**

2.  Q5 Data Input Format

The specifics of the input format for the Q5 software has not been
defined at this point outside of the development decision to utilize the
mxXML format. Use of this format appears to be a somewhat standardized
format in the mass spectrometry field and should allows integration into
workflow with other caBIG sponsored products such as the R-Proteomics
project.

The goal is to make this flexible but adhere to a standard that allows
for flexibility and maintainability within the changing caBig
infrastructure. Consideration of the widely used format of mzXML for the
use by the Fox Chase LIMS server as well as the availability of XML
parsers for various platforms is the current consideration for the
output format. At present the Q5 software will output a classifications
such as "diseased" and "non diseased". Although there are more complex
terminologies used in the accurate description of disease states, this
is seen outside the initial scope of the Q5 project and therefore not
extended to meet more specific classification output types.

At present, the adopters of the Q5 project do not intend to implement
the LIMS system, so the software will be able to accept pre-formatted
mzXML datafile from the local workstation as well. Addition of the LIMS
connectivity will modify the category of this software from tool to
service, therefore, requiring additional modeling of the system, it's
interaction with the server and to ensure that the data elements are in
line with the caBIG vocabulary.

3.  Q5 Data Output Format

The output format will be in the form of two files created during the Q5
analysis. These two files are supplied to the algorithm in R and are
written to provided path and filename. The raw output results will be
written to one file in the format of:

**Label:\<tab\>value**

The second file will contain the graph of the eigenvalues generated by
the Q5 analysis. The graphic will be rendered as a portable network
graphic formatted image (PNG). This format is compatible with most all
word processors on many platforms.

The selection of the R language for development was made based upon the
inherent statistical functions within the language itself that are
accessible to the end user and the fact that this software is open
source and freely available to many platforms and in source format. This
allows the potential for additional analysis and exploration of the end
results by the user proficient in the R software. The only database
interaction intended for the Q5 software is importing of spectra via the
Fox Chase LIMS server.

## Qualification Provisions

a\. Demonstration: The operation of the system or component that relies
on observable functional operation not requiring the use of
instrumentation, special test equipment, or subsequent analysis.

b\. Test: The operation of the system or component using instrumentation
or other special test equipment to collect data for later analysis.

c\. Analysis: The processing of accumulated data obtained from other
qualification methods. Examples are reduction, interpretation, or
extrapolation of test results.

d\. Inspection: The visual examination of code, documentation, etc.

e\. Special qualification methods: Any special qualification methods for
the system, such as special tools, techniques, procedures, facilities,
and acceptance limits.

## Assumptions and Dependencies

Prior installation of the R software environment on the local
workstation including the R MASS library (see section 3.4(1) for a
statement of dependencies as well).

The current version of R will configure and build under a number of
common Unix platforms including *cpu* linux-gnu for the i386, alpha,
arm, hppa, ia64, m68k, mips/mipsel, powerpc, s390, sparc , and
x86_64CPUs,powerpc-apple-darwin, mips-sgi-irix, rs6000-ibm-aix, and
sparc-sun-solaris.

All Maldi-Tof data sets used by the adopter will be pre-processed (via
R-Proteomics or similar software) to reduce dimensionality prior to
execution of the Q5 software and make the analysis more time efficient.
Although this is not a requirement of the software it is a workflow used
by the adopter site. Q5 should be able to run on raw full spectra
(properly formatted in mzXML) without pre-processing although the length
of processing time may increase greatly.

# Requirements

*The Requirements categories outlined correspond to each functional area
of the Q5 software and the software flow diagram.*

## Datafile Handling 

Table 3.1-1: Data Handling Requirements

  ----- ------------- -------------------------------------------------------
  Req   Requirement   Requirement Description
  ID    Type          

  1.1   System        The system will allow the end user to import spectra
                      from a local datafile located on the client workstation
                      or network.

  1.2   System        The system will allow the end user to import spectra
                      from a Fox Chase LIMS server into the Q5-R software via
                      an mzXML transport mechanism.

  1.3   Interface     The system will display an error to the user if the
                      datafile attempting to be imported is improperly
                      formatted for usage.

  1.4   System        The input datafile format will be in mzXML format.
                      *Technical tag details will be outlined in the
                      architecture section.*

  1.5   System        The Q5 system will accept both properly formatted
                      Seldi-TOF and Maldi-TOF data as inputs to the software.

  1.6   System        The Q5 system will allow for sample attribute
                      acquisition by common ID value (a SUID, or single
                      unique ID) from the Fox Chase LIMS. This indicates that
                      the metadata drawn for a given record will be accessed
                      by its SUID not the record itself in case of metadata
                      extension.
  ----- ------------- -------------------------------------------------------

## Analysis Routines 

Table 3.1-1: Analysis Routines Requirements

  ----- ------------- -------------------------------------------------------
  Req   Requirement   Requirement Description
  ID    Type          

  2.1   System        The Q5 system will allow the user to indicate whether
                      or not the imported dataset is to be used for
                      testing/training or to be split for use as both.

  2.2   System        The Q5 system will reduce the dimensional space for the
                      data using PCA (Principal Components Analysis) within
                      the software. This mechanism will be made visible to
                      the user so that they can call this portion of the
                      functionality from the R environment.

  2.3   System        Following PCA, the Q5 system will implement a linear
                      discriminant analysis method against the data. This
                      mechanism will be made visible to the user so that they
                      can call this portion of the functionality from the R
                      environment.

  2.4   System        The output of the LDA step of the Q5 system will be a
                      linear discriminant used to classify the remainder of
                      the data. This mechanism will be made visible to the
                      user so that they can call this portion of the
                      functionality from the R environment.
  ----- ------------- -------------------------------------------------------

## Analysis Output 

Table 3.1-1: Analysis Output Requirements

+----+---------+-------------------------------------------------------+
| R  | Requ    | Requirement Description                               |
| eq | irement |                                                       |
| ID | Type    |                                                       |
+----+---------+-------------------------------------------------------+
| 3  | System  | The Q5 system will output the disease classification  |
| .1 |         | from the analysis in a numerical value as well as the |
|    |         | associated statistics (Classification Sensitivity,    |
|    |         | Classification Specificity, Percentage of Samples     |
|    |         | Classified, Percentage of Samples Correctly           |
|    |         | Classified, and Positive Predictive Value.) *These    |
|    |         | terms will be reviewed in the caDSR and made more     |
|    |         | solid to caBIG specifications.*                       |
+----+---------+-------------------------------------------------------+
| 3  | System  | The output datafile format will consist of two        |
| .2 |         | possible files.                                       |
|    |         |                                                       |
|    |         | 1.  datafile consisting of the output values          |
|    |         |     (outlined in the analysis output section)         |
|    |         |                                                       |
|    |         | 2.  graphics file containing the graph of eigenvalues |
|    |         |     in a portable network graphics format.            |
|    |         |                                                       |
|    |         | These filenames and paths will be supplied by the     |
|    |         | user to the Q5 script. If the user does               |
|    |         |                                                       |
|    |         | not provide these parameters to the script, the Q5    |
|    |         | script will write the output values to                |
|    |         |                                                       |
|    |         | standard out and produce an R graph of the            |
|    |         | eigenvalues.                                          |
|    |         |                                                       |
|    |         | *Details of the output format are contained in the    |
|    |         | data standards section (#3) of this*                  |
|    |         |                                                       |
|    |         | *document.*                                           |
+----+---------+-------------------------------------------------------+
| 3  | System  | The PCA function within the Q5 script will allow the  |
| .3 |         | user to output the values for a plot() function from  |
|    |         | R to produce a graph of sorted Eigenvalues.           |
+----+---------+-------------------------------------------------------+

# System Architecture

***Architectural Design** -- This diagram outlines the basic process
flow of the Q5 software. The flow uses the major functional components:*

-   *Q5 (main calling script) -- This is the primary script that is the
    controlling interface for the overall Q5 process.*

-   *LIMS -- Server used for raw spectra retrieval. Not used in the
    initial Q5 software release(to be implemented when the Fox Chase
    Proteomic LIMS server is available)*

-   *Database Filesystem -- General representation of the datafile (this
    will be deployed in the initial release as mxXML)*

-   *PCA -- Principal Components Analysis portion of the script. This is
    an exposed interface that will allow the user to implement the
    standard PCA as outlined by the Q5 algorithm or utilize their own by
    calling a different method such as a windows PCA library for
    instance.*

-   *LDA -- Linear Discriminant Algebra portion of the Q5 script. This
    was broken out in case the user might want to utilize another method
    during this piece.*

    ![](media/image4.png){width="5.2243055555555555in"
    height="4.804861111111111in"}

# Components

## q5

***Purpose** -- Provides the main function for the script. Trains a
disciminant on given training data and then assesses its predictive
capacity with testing data. This is the function of the Q5 algorithm.
Each of the functions it performs are accomplished by calling functions
that are passed as parameters, this allows users to substitute their own
functions for any of the steps in Q5 (with the exception of the
statistical parameters generated).*

-   ***Type** - This is the main function that implements the Q5
    algorithm.*

-   ***Functional Description** -- Performs the Q5 algorithm in a
    flexible fashion that allows the user to alter its
    sub-functionality.*

-   ***Subordinate** -- Four functions passed by the user. Provides
    default values that depend on pca, lda, pcaProject, and
    MASS:::predict.lda.*

-   ***Dependencies -** Requires the MASS package.*

-   ***Preconditions --** Requires two matrices of data, one for
    training, one for testing, requires two vectors that describe the
    classes of the data. Optionally takes four functions for dimensional
    reduction, discriminant construction, data projection, and class
    prediction.*

-   ***Interfaces -** q5(trainData, trainClasses, testData, testClasses,
    reductionFunction=pca, discriminantFunction=lda,
    projectionFunction=pcaProject,
    predictionFunction=MASS:::predict.lda)*

-   *Takes two matrices of real numbers, one of training data, one of
    testing data. Takes two vectors of integers the label the class of
    each row in the two matrices, 1 indicates diseased state. Returns
    the generated discriminant, the estimated positive predictive value
    of the discriminant, the percentage of cases in the testing data
    that were correctly classified, the estimated sensitivity and
    specificity.*

-   ***Graphics -** This is a non-graphical routine.*

-   ***Resources -** None*

-   ***Error Conditions --** The function will fail with an error
    message if any of the passed objects are not of the correct type.*

***Example Implementation --***

![](media/image5.png){width="6.867361111111111in"
height="2.8534722222222224in"}

##   {#section .unnumbered}

## mzXML

***Purpose** - The mzXML function loads a datafile from a user supplied
string containing the path to an mxXML file. It returns a list of two
values; \"mass\", the mass to charge ratio of each peak in th escan and
\"peaks\" which are the intensities for each peak in the scan.*

-   ***Type** - This is a conveneince function within the Q5 script for
    the user\'s use.*

-   ***Functional Description** - Reads each scan in the file and
    appends its peaks and mass to charge ratios to separate items in a
    list.*

-   ***Subordinate** - This function makes external calls to function
    read.mzXML in the caMassClass.*

-   ***Dependencies -** Requires the caMassClass package.*

-   ***Preconditions -** Requires a string describing the location of a
    local file in mzXML format. This function is called prior to
    executing q5.*

-   ***Interfaces -** mzXML(filename)*

-   ***Graphics -** This is a non-graphical routine.*

-   ***Resources -** None*

-   ***Error Conditions -** The function will fail with an error message
    on malformed mzXML. The function will also provide an error message
    if the user supplied string does not contain the path to a local
    mzXML file.*

-   ***Example Implementation --***

![](media/image6.png){width="5.023611111111111in"
height="1.5284722222222222in"}

## normalize

***Purpose** -- Normalizes the peak intensity matrix. This is not part
of the main script but it provides a simple normalization for the
convenience of users.*

-   ***Type** - This is a function that can be called before q5 to
    normalize the data.*

-   ***Functional Description** - The normalize function normalizes the
    peak intensities of a scan to the range \[0, 1\] using a standard
    linear transformation.*

-   ***Subordinate** - This function makes no function calls to
    dependency packages.*

-   ***Dependencies** -- None.*

-   ***Preconditions** - Requires a two dimensional matrix of real
    values*

-   ***Interfaces** -- normalize(mat)*

-   ***Graphics** - None.*

-   ***Resources** -- None.*

-   ***Error Conditions** -- This function will fail with an error
    message if it doesn\'t receive a matrix of rank 2.*

-   ***Example Implementation -***

![](media/image7.png){width="5.572916666666667in"
height="1.4680555555555554in"}

## pcaProject

***Purpose** -- Projects data into the pca space on which the
discriminant was defined.*

-   ***Type** - This is a function that can be passed to q5 as the
    projectionFunction parameter.*

-   ***Functional Description** -- Multiplies the user supplied matrix
    by the user supplied eigenvectors.*

-   ***Subordinate** -- This function makes no function calls to
    dependency packages.*

-   ***Dependencies** -- None.*

-   ***Preconditions** - Requires two two dimensional matrices of real
    values*

-   ***Interfaces** -- pcaProject(mat, eigvecs)*

-   ***Graphics** - None.*

-   ***Resources** -- None.*

-   ***Error Conditions** -- This function will fail with an error
    message if it receives the wrong type of input. The size of the
    second dimension of the matrix (mat) must be equal to the size of
    the first dimension of the second matrix (eigvecs).*

-   ***Example Implementation --***

![](media/image8.png){width="4.166666666666667in" height="0.78125in"}

## pca

The pca function performs principle components analysis on the given
matrix.

-   ***Type** - This is a function within the Q5 script with an exposed
    development interface.*

-   ***Purpose** -- Dimensional reduction of the data.*

-   ***Function** -- Performs principle components analysis by singular
    value decomposition, taking the diagonal of the resultant matrix and
    multiplies this by the input matrix.*

-   ***Subordinat**e -- None.*

-   ***Dependencies** -- Takes a two dimensional matrix of real values.*

-   ***Preconditions** - Requires a two dimensional matrix of real
    values*

-   ***Interfaces** -- Performs principle components analysis by
    singular value decomposition, taking the diagonal of the resultant
    matrix and multiplies this by the input matrix.Returns the resultant
    matrix and the eigenvectors and eigenvalues of the matrix..*

-   ***Graphics** - None.*

-   ***Resources** -- None.*

-   ***Error Conditions** -- This function will fail if it receives the
    wrong type of input with an error message.*

-   ***Example Implementation --***

![](media/image9.png){width="4.96875in" height="0.9270833333333334in"}

#  \[*NOTES*\]

*\[Insert any general information that aids in understanding this
document (e.g., background information, glossary, and rationale). This
section shall include a list of any terms and definitions needed to
understand this document.\]*

# Sign off

## Approval

*Architecture Workspace Rep Print Name Date*

*VCDE Workspace Rep Print Name Date*

*Adopter Rep Print Name Date*

# Appendix A -- Acronym List

*\[Insert an alphabetical listing of all acronyms and abbreviations, and
their meanings as used in this document.*\]

  -------------- -----------------------------------------------------------
  Term/\         Description
  Abbreviation   

  \[????\]       \[*Insert Project Name acronym*\]

  \[????\]       \[*Insert Project all other project Test Plan specific
                 acronyms and resort the table*\]

  DBA            Database Administrator

  PM             Project Manager

  RM             Requirements Manager

  RTM            Requirements Traceability Matrix

  SCM            Software Configuration Management

  SDLC           Software Development Lifecycle

  SDP            Software Development Plan

  SE             Software Engineering

  SEPG           Software Engineering Process Group

  SM             Software Manager

  SOP            Standard Operating Procedure

  SPI            Software Process Improvement

  SQA            Software Quality Assurance

  SW             Software

  TBD            To Be Determined

  TM             Test Manager
  -------------- -----------------------------------------------------------

# \[*Appendix B -- Other Appendices*\]

*\[Use appendices to provide information published separately for
convenience in document maintenance (e.g., charts, classified data). As
applicable, the main text of the document should reference each appendix
where the data would logically fit within the document. Appendices may
be bound as separate documents for ease in handling. Appendices shall be
lettered alphabetically (A, B, etc.).\]*