cabig Proteomics LIMS

Transcription

1 cabig Template SOFTWARE REQUIREMENTS AND SPECIFICATION DOCUMENT cabig Proteomics LIMS DOCUMENT CHANGE HISTORY Version Number Date Description 1.0 June 2005 Draft 1.1 July 2005 Modified first version 2.0 January 2006 Revisited to add architecture and component chapters 2.1 February 2006 Unused notes and appendixes are deleted April 2004

2 cabig Proteomics LIMS protlims prototype v.1.0 Document Version 2.1 [Insert approval date of document]

3 Document Change Record Version Number Date Description 1.0 June 2005 Draft 1.1 July 2005 Modified first version 2.0 January 2006 Revisited to add architecture and component chapters 2.1 February 2006 Unused notes and appendixes are deleted [SRSD_Project_Version.doc] i [Publish Date]

4 TABLE OF CONTENTS SOFTWARE REQUIREMENTS AND SPECIFICATION DOCUMENT... I 1. INTRODUCTION SCOPE Identification System Overview Document Overview REFERENCE DOCUMENTS PROJECT DESCRIPTION PROJECT PERSPECTIVE PROJECT FUNCTIONS USER CHARACTERISTICS CONSTRAINTS protlims Statement Of Work cabig Compliance Additional constraints, programming language and tools being employed QUALIFICATION PROVISIONS ASSUMPTIONS AND DEPENDENCIES REQUIREMENTS SECURITY INTERFACES User Interface Application Programming Interface (API) BUSINESS TIER Business Façade Business Logic Logic Utilities FILE STORAGE RELATIONAL DATABASE SYSTEM ARCHITECTURE SYSTEM ARCHITECTURE OVERVIEW ARCHITECTURAL DESIGN COMPONENTS WEB MODULE COMMON MODULE BUSINESS FACADE MODULE FILE ACCESS COMPONENT DATA ACCESS MODULE EJB MODULE SECURITY MODULE DATABASE MODULE LOGIC UTILITIES MODULE SIGN OFF APPROVAL APPENDIX A ACRONYM LIST [SRSD_Project_Version.doc] ii [Publish Date]

5 1. INTRODUCTION This Document (SRSD) captures the complete software requirements for the proteomics LIMS (protlims) and describes the design decisions, architectural design and the detailed design needed to implement the software. It provides the acquirer visibility into the design and provides information needed for software support. The purpose of protlims is to allow the recording of all experimental samples, processes, procedures, analyses, and results of proteomics studies to a searchable relational database. Recording of such data, and associated metadata, will provide improved record keeping, record retrieval, and report generation and review. protlims is a LIMS system dedicated to studies in the realm of proteomics. The initial goal (goal of this version) is to develop the system to the point in the analytical workflow where sample are prepared for mass spectroscopy. This entails recording of biological sample data, sample preparation, protein separation/resolution (if any is performed), and isolated protein sample preparation (if separation was performed and further preparation is performed). Goals of the protlims development are: 1. Allow the recording of all necessary, and desired, data and metadata pertaining to proteomic analyses. 2. Allow interoperability with parallel LIMS and/or analytical systems. 3. Remain cabig compliant. 4. Though not required, design with future web services is in mind. The system is being developed in collaboration with the Fox Chase Cancer Center (FCCC) Proteomics Facility and the cabig adopters: H. Lee Moffitt Cancer Center & Research Institute. 1.1 SCOPE The Fox Chase Proteomics Laboratory Information Management System (protlims) is being developed as part of the Cancer Bioinformatics Grid (cabig ) initiative sponsored by the National Cancer Institute and facilitated by Booz Allen Hamilton. The system is being developed in collaboration with the Fox Chase Cancer Center Proteomics Facility and the cabig adopters: H. Lee Moffitt Cancer Center & Research Institute. The goal of this project is to develop a stand-alone LIMS system dedicated to studies in the realm of proteomics. The goal of the current version is to capture the data and metadata to the point in the analytical workflow where sample are prepared for mass spectroscopy Identification This is the initial version of the Fox Chase Proteomics Laboratory Information Management System (protlims). [cabig _SRSD_Template.doc] 1 [Publish Date]

6 1.1.2 System Overview This is the initial version of the Fox version of the Fox Chase Proteomics Laboratory Information Management System (protlims). Choices on which data to store and some use cases were initially taken from the calims project. The calims data model, however, did not satisfy the full needs of the proteomics laboratories. As a result data models devoted to proteomics, PeDRO and its successor, HUPO s Proteomics Standards Initiative/General Proteomics Standards (PSI/GSP), are being leveraged. In addition, an effort is being made to coordinate with other cabig proteomics efforts (e.g., Rproteomics) and to harmonize the object model with related object models (e.g., MicroArray and Gene Expression [MAGE]) to improve and simplify protlims interoperability with other systems Document Overview This SRSD captures the complete software requirements for initial development of the Fox Chase Proteomics Laboratory Information Management System (protlims), as part of NCI s cabig initiative There are no additional or specific security or privacy considerations associated with this document. The document and associated software system is being developed transparently and as open source. Questions, comments and requests may be submitted to the Fox Chase Cancer Center Bioinformatics Facility. The remaining SRSD sections are organized as follows: The remaining SRSD sections are organized as follows: Section 2. Project Description: Describes the general factors that affect the protlims. 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. Section 4. System architecture: Describes architectural aspects of the system as a whole. Section 5. Components: Describes functional and architectural aspects of the system components. Appendix A. Acronym List: Defines the abbreviations used on the project. 1.2 REFERENCE DOCUMENTS For additional project, and requirement specific information, refer to the following documents: Use-case requirements document is available at the cabig cvs server: MS_2005_03_08.doc [cabig _SRSD_Template.doc] 2 [Publish Date]

7 Other documentation is also available at the Fox Chase Cancer Center Bioinformatics Facility website: [cabig _SRSD_Template.doc] 3 [Publish Date]

8 2. PROJECT DESCRIPTION The protlims records the data associated with the complete workflow of proteomic analyses, and will provide a data pipeline from analysis step to analysis step. protlims is affected by the data collected by researchers conducting proteomic analyses. These data may be from heterogeneous sources and may be used as input to other analyses. As such, efforts are being made to harmonize the protlims object model with those systems from other domains, e.g., microarray analysis. This will allow and simplify interoperability of systems used to analyze the same biological materials by parallel research domain spaces. Development of the protlims has begun using model drive architecture (MDA) and an iterative development process (IDP). Each development iteration of the IDP will complete a classic software development cascade including: Analysis which produces an SRS revision Design which produces a Software Design Document revision Construction which produces a new code revision Quality Assurance Testing both at the Unit Test and Integration System Test levels 2.1 PROJECT PERSPECTIVE The system is being developed in collaboration with the Fox Chase Cancer Center Proteomics Facility and the cabig adopters: H. Lee Moffitt Cancer Center & Research Institute. protlims is being designed to allow its function, optionally, as (1) a stand-alone proteomics LIMS [present] or as (2) an integrated component of interoperable LIMSs [future] or (3) a cagrid service [future]. Programming is in Java to allow platform independence for the application server (e.g., JBoss being used in FCCC s implementation). As a user interface, Internet web pages will be generated by the protlims to allow conventional web browsers to provide a graphic user interface. Administrative functions will also be available via the web interface. protlims employs an external relational database and the server s directory file system (or its equivalent). The relational database provides data storage and file location information for files stored by protlims. Fox Chase Cancer Center is using Oracle for this purpose but the system is being developed to allow for alternate databases to be used. Data collected into the relational database may be either entered directly through the web interface, or by uploading files to be parsed by protlims. Parsed files may be generated by a variety of proteomics analytical tools and are parsed by the system automatically into the database as well as being stored in the server s directory file system (or its equivalent). In addition, the directory file system is used by protlims for the storage of other native proteomics data files, e.g., gel images, and ancillary files ( attachments ) that the user chooses to associate with the data. [cabig _SRSD_Template.doc] 4 [Publish Date]

9 2.2 PROJECT FUNCTIONS This project will be focused on the creation of a cabig -compliant proteomics Laboratory Information Management System (LIMS), namely: protlims. The initial version will track the lab processes from biological sample registration through 2D gel electrophoresis separation of proteins and excision of protein spots for analysis by mass spectroscopy. The schema and data model support the addition of additional data types and new data types, as they emerge. The availability of an open source proteomics LIMS will ultimately allow a distributed development model in which additional modules can be contributed by other centers. 2.3 USER CHARACTERISTICS Anticipated end-users of protlims are protein analysts in research laboratories or, more specifically, dedicated proteomics facilities. In addition, researchers who are not performing the analyses themselves, but have proper permissions to access the system and specific data subset(s), may also act as end users. 2.4 CONSTRAINTS protlims Statement Of Work We are constrained to work within the context of our statement of work (SOW). We expect that the system description will evolve in the course of our analysis but our core product and resource utilization will remain framed by our SOW cabig Compliance We are constrained to comply with all cabig standards on silver compatibility level. It is a requirement that protlims participate as a fully functioning component of cabig. We seek to adopt all cabig sanctioned architectural patterns within a reasonable time after they are established. When cabig compatibility issues emerge abruptly in contrast to our development stream we will adjust at the start of our next development iteration. Silver level compatibility guidelines can be found at: Additional constraints, programming language and tools being employed Java is the programming language being used to allow platform independence. A Java application server is required for protlims implementation. FCCC s implementation is being developed utilizing the JBoss Application Server ( a freely available, J2EE 1.4 certified, open standards and open source, Java application server. A relational database back-end is required for protlims functionality. Fox Chase Cancer Center is using Oracle for this purpose but protlims is being developed to allow for [cabig _SRSD_Template.doc] 5 [Publish Date]

10 alternate databases to be used. PostgreSQL ( is being used as a freely available open source model relational database. Programming tools Function Application UML modeling tools Sybase PowerDesigner 10.0 Sparx Systems - Enterprise Architect Compuware OptimalJ 3.3 MDA modeling tool Compuware OptimalJ 3.3 Source code generation tool Compuware OptimalJ 3.3 Java IDE JetBrains IntelliJ IDEA 4.5 JSP and HTML code editor Macromedia DreamWeaver MX 2004 Database modeling tool Sybase PowerDesigner 10.0 Database mining tool Benthic Software Golden QUALIFICATION PROVISIONS Project management requires that all generated and non-generated code and interfaces (application program interface [API] and graphical user interface [GUI]) will be tested. Change management requires that all generated and non-generated code and interfaces (application program interface [API] and graphical user interface [GUI]) will be regression tested. All non-generated code shall be documented in the IDE. Unit testing includes empty data tests, known incorrect data tests, and limit testing. System tests will be performed on newly installed machines to demonstrate that normal operation does not require any software that is not explicitly stated in the requirements. 2.6 ASSUMPTIONS AND DEPENDENCIES protlims is a LIMS dedicated to those areas of research involved in protein isolation, separation and identification i.e., proteomics. As such, it is assumed that proteomics researchers, analytical systems and tools are available for interaction with protlims. [cabig _SRSD_Template.doc] 6 [Publish Date]

11 3. REQUIREMENTS 3.1 SECURITY protlims is required to use Java Authentication and Authorization Service (jaas) implementation to provide security aspect of the system. Authentication options include LDAP and alternative method for non-ldap users (database or password file) protlims allows user and role based authorization. Initial protlims prototype version will be designed with these authorization requirements in mind, but may actually contain user and role based authorization only partially. 3.2 INTERFACES User Interface protlims is accessed by user via internet browser, thus a web user interface is required. The web interface is created with by the Jakarta Struts Framework composed of Struts forms, JSPs, and Struts actions. User interface provides user access to system functionality defined by use cases (see Referenced documents section). User interface allows user to create and review information about conducted proteomics research. User interface also allows authorized personnel to administer protlims Application Programming Interface (API) Silver level compatibility requires that a well-described API s provide access to data in the form of data objects that are instances of classes represented by a domain model. 3.3 BUSINESS TIER Business Façade A Business Façade is required in the protlims architecture to handle communication between the presentation and web tiers and the business logic (EJB) tier. Functionally this hides or exposes business component functionality. In addition, the Business Façade manages data transfer to and from the business components and handles Application transactions Business Logic Business logic implements all system functions: Maintenance of data (create and update) with EJB (Enterprise Java Beans) Read-only querying of data with DAC (Data Access Components) File upload/download to/from File Storage [cabig _SRSD_Template.doc] 7 [Publish Date]

12 3.3.3 Logic Utilities Logic utilities provide functionality for parsing of supported format data files. Initial version of protlims supports: Nonlinear Dynamics Progenesis image analysis export file for Microsoft Excel Pick list in Microsoft Excel file 3.4 FILE STORAGE protlims requires access to, and use of, the server s local file system (or its equivalent) as a dedicated named user (e.g., user_name protlims; group_name lims ). This access is used for the storage of data, and associated files in their native format. protlims control of the relevant directory tree organization is required and organized in a project oriented structure. In this way, if for any reason the directory tree must be accessed directly by the System Administrator, the tree may be navigated logically. Data and associated files stored may be of any type of electronic storage format (e.g., digital images [e.g., jpeg or tiff], digital text [e.g., XML or pdf], or binary files). Metadata about file location is retained in the required relational database (Section 3.6). If for some unforeseen reason stored files are damaged or deleted by external means, protlims is required to fail retrieval gracefully returning an appropriate error message about file unavailability. Limitation of file size and total storage space are independent of protlims, being a limitation of the computer storage operating system and storage media. Earlier operating systems had maximum file sizes of approximately 2 gb, but this limit has been increased more recently. File size is not a likely limitation to use. Total storage media does become a concern due to the relatively large size of files, and number of files, the proteomics experiments generate. 3.5 RELATIONAL DATABASE A relational database back-end is required for protlims functionality. Fox Chase Cancer Center is using Oracle for this purpose but protlims is being developed to allow for alternate databases to be used. PostgreSQL ( is being used as a freely available open source model relational database. No other database alternative is being tested in the immediate future. Alternatives must be capable of views and hierarchical queries. The relational database retains all data entered through the web interface and network paths to data and associated files. It is required that no data is ever deleted from the database, itself, though the user may use the web interface delete function to delete data entries from the list of viewed data. In this way all data is retrievable for future access if necessary, e.g., for auditing purposes. [cabig _SRSD_Template.doc] 8 [Publish Date]

13 4. SYSTEM ARCHITECTURE 4.1 SYSTEM ARCHITECTURE OVERVIEW The protlims utilizes a multi-tiered systems architecture (Figure 4.1-1). The system is being built using model driven architecture (MDA). This separates functional roles in the system into individual domain models. The application model (Platform Specific Model; PSM) is generated from the domain model (Platform Independent Model; PIM) using technology patterns of J2EE. User access is provided by an internet/web interface (Tier 1: Client Tier). The client accesses the interface using an internet/web browser application of their choosing. The Client Tier communicates with the systems web components composed of the web server and (Tier 2: Web Tier) and application server (Tier 3: Business Tier). These tiers are isolated from the user by system modules providing a business façade and business logic. The Business Tier communicates with the Database Server (Tier 4: Data Storage Tier) for data storage and retrieval. As specified in the present requirements and specifications document, in addition to the relational database, collateral files are stored in a dedicated file directory structure. Tier 1: Client Tier Tier 2: Web Tier Tier 3: Business Tier Tier 4: Data Storage Tier HTML Java Server Pages Struts EJB session beans EJB entity beans Data access components JDBC Connector technologies Web Browser Web Server Application Server Network Network Network Database Server & Directory 4.2 ARCHITECTURAL DESIGN Figure 4.1-1: System Architecture Overview The user interface (Figure 4.1-1, see: Presentation) is generated by a Jakarta Struts framework: Struts forms, Java Server Pages (JSPs), and Struts Actions. The Presentation Tier and Business Logic components communicate with the Business Façade by utilization of shared components accessible to all components of the system (Figure 4.1-1, see: Common). Methods of the session beans of the Business Logic component (Figure 4.1-1, see: Business Logic) access Entity Beans and Data Access Components (DAC) as appropriate for user selected functions. Data of the database records are recorded and retrieved by methods of the Entity Beans and DAC as [cabig _SRSD_Template.doc] 9 [Publish Date]

14 necessary for user selected functions. Similarly, files stored in the protlims directory tree are stored and retrieved as necessary for user selected functions. Files Presentation Struts Forms JSPs Business Facade Business Facade File Access Component Business Logic Entity Beans DBMS Struts Actions Session Beans Data Access Components Web Services* Common Update Object Key Data Object Collection, List Collection, List Collection, List Security Model Logic Utilities Figure 4.2-1: protlims Architectural Design * Web services integration is not part of first year requirements [cabig _SRSD_Template.doc] 10 [Publish Date]

15 5. COMPONENTS 5.1 WEB MODULE Purpose The Web Module provides the user interface (section 3.2.1) Function Subordinate Dependencies Interfaces The Web Module allows user to access, update and create information via web browser. The Web Module is implemented with Jakarta Struts framework. The Web module consists of jsp pages, struts forms, actions and configuration files, and also resource, style-sheet and java script files. Web interface appearance may depend on used web browser. Primary browsers are: Internet Explorer on Windows, Safari on MacOS and Mozilla Firefox on other operating systems. Web interface is not guaranteed to be displayed correctly on other browsers. User-to-Web Module (for Input files to be parsed by the system): - Files exported from gel image analyzing software with data about detected spots (DeCyder and Progenesis) - Pick list (exported by software and modified by researcher) Interfaces Web Module-to-Business Façade, and vice versa: The Web Module accesses system logic via Business façade module. The Web Module uses data objects defined in the Common Module to communicate with the Business Façade. The Web module uses the Security Model to provide Authentication and Authorization. Each web component deals with its corresponding business façade components. For example, SampleSvcWebComponent: - Uses SampleSvcBusinessFacade to create the sample in the database - Uses SpeciesTypeBusinessFacadeComponent to populate the dropdown menu list of available species in the user interface - Uses SampleProviderBusinessFacadeComponent to populate the dropdown menu list of available providers in the user interface - and so on for other dependent look-ups Other components work in a similar fashion: RawSampleSvc, GelImageSvc, ProjectSvc, ProcedureSvc, etc. [cabig _SRSD_Template.doc] 11 [Publish Date]

16 ProjectSvc, ProcedureSvc, etc. [cabig _SRSD_Template.doc] 12 [Publish Date]

17 Interfaces [cabig _SRSD_Template.doc] 13 [Publish Date]

18 Processing The Web Module is implemented with Jakarta Struts framework: Client Web Tier EJB Tier Controller Model request Controller Servlet create Action Class r/w data Business Facade r/w data Session Bean Browser HTML response Read Struts- Config.xml forward View JSP r/w data read r/w data Form Bean r/w data Create Update Object r/w data r/w data Entity Bean Data Object get data Elements of the Struts framework include: Controller Servlet Implements the Controller part of the MVC. It receives and forwards requests using the struts-config.xml file Actions Classes Implement the Model part of the MVC. They perform actions and return statuses JavaServer Pages (JSPs) Implement the View part of the MVC. They are filled with data from the update objects and produce an HTML output to the client Struts-config.xml Defines the action mapping Form Bean A helper class that contains get and set methods for all the attributes that can be submitted via an HTML form. [cabig _SRSD_Template.doc] 14 [Publish Date]

19 5.2 COMMON MODULE Purpose Function Subordinate Describes the LIMS shared data structures for generation of, and LIMS interaction with, the user interface (section 3.2.1). The Common Module contains objects that are used to transfer information between modules inside system and also between system itself and other applications. Common module contains two separate modules: Core data elements Reflect the database tables Browser Reflects the database read-only views Dependencies Interfaces None None 5.3 BUSINESS FACADE MODULE Purpose Function Subordinate Dependencies Interfaces Control tier-to-tier (Web Unit to Business Logic Model) communication, and therefore improves network traffic performance in the LIMS. The business facade model provides access to business logic. It allows the presentation model to use the data and access the methods provided by Business Logic Model components. Business façade components: one for each ejb bean plus one BrowserSvc Business Facade Component for all DAC components. None Business façade serves as firewall between presentation and business logic tiers: web module business façade entity bean web module business façade session bean web module business façade File Access Component web module business façade Logic utilities [cabig _SRSD_Template.doc] 15 [Publish Date]

20 Interfaces [cabig _SRSD_Template.doc] 16 [Publish Date]

21 5.4 FILE ACCESS COMPONENT Purpose Function Provide upload and download of native file to and from directory file storage (see section 3.4). Saves uploaded file from LimsFileSvcUpdateObject into file storage Checks if requested file is available for reading Copies downloaded file from file storage to LimsFileSvcUpdateObject Subordinate Dependencies Interfaces None File Storage for File Access Component is located on the servers local file system. void uploadfile(limsfilesvcuo LimsFileSvcUpdateObject) void downloadfile(limsfilesvcuo LimsFileSvcUpdateObject) boolean isreadyfordownload (limsfilesvcuo LimsFileSvcUpdateObject) 5.5 DATA ACCESS MODULE Purpose Function Subordinate Dependencies Interfaces Provide read-only access to big subsets of information Perform queries on database views Data Access Components - one for each database view Oracle supports hierarchical queries, PostgreSQL doesn t. Sample-data hierarchy DAC analyzes connection metadata to determine current DBMS, and for Oracle hierarchical queries are performed (where applicable), for other DBMS (including PostgreSQL) hierarchical queries are replaced by simple queries that only retrieve one level of children/parents Each DAC has findbyproperties() method: findbyproperties (filter <NameOfTheView>UpdateObject) returns <NameOfTheView>UpdateObjectCollection NameOfTheView>UpdateObjects belongs to browser part of common module Sample-data hierarchy DAC also provides findallchildren() and findallparents() methods to retrieve information about pedigree for particular sample or datafile. [cabig _SRSD_Template.doc] 17 [Publish Date]

22 Processing Each non-null attribute in filter update objects is parsed as additional query condition. If all attributes are null, all available entries are retrieved from appropriate view. 5.6 EJB MODULE Purpose Function Subordinate Manage information Store data to persistence (database) tier Entity components and Session components Dependencies EJB 2.0 Interfaces Entity beans are used by business façade to retrieve information from database: business façade entity bean database Interfaces Session beans are used by business façade to create and update groups of objects sometimes called domain views (not to be confused with database views) business façade session bean several entity beans database [cabig _SRSD_Template.doc] 18 [Publish Date]

23 [cabig _SRSD_Template.doc] 19 [Publish Date]

24 5.7 SECURITY MODULE Security module purpose is to provide authentication and authorization methods to the system. In the current version of the system authentication will be provided by Java Authentication and Authorization Service (jaas) implementation developed at Fox Chase Cancer Center. Authorization features will be limited to laboratory personnel laboratory project access restriction (stored in database). Java Authentication and Authorization Service is a set of APIs that enable services to authenticate and enforce access controls upon users. Future releases of the protlims should fully support user-based authorization 5.8 DATABASE MODULE Purpose Function Subordinate Dependencies Interfaces Provide data storage Keep data, response to queries Tables and views Two sets of scripts and configuration files are provided (one for Oracle and one for PostgreSQL) to handle differences between two supported DBMS. None. 5.9 LOGIC UTILITIES MODULE Purpose Function Subordinate Dependencies Interfaces Provide logic utilities to web and business façade modules Utilities provide classes to handle input file parsing. Currently supported formats are xls files exported from Progenesis or created by researcher according to upload format requirements. UploadParser interface, implementations for all supported formats, factory class. UploadParser implementations heavily depend on input file format each particular implementation is supposed to parse. Changes in these formats should be reflected in UploadParser implementation changes. Factory class provides access to appropriate UploadParsers for web and business façade modules. Obtained by factory UploadParser interface provides method for parsing input file stream into information about spot analysis or gel plug pick list. [cabig _SRSD_Template.doc] 20 [Publish Date]

25 [cabig _SRSD_Template.doc] 21 [Publish Date]

26 6. SIGN OFF 6.1 APPROVAL Architecture Workspace Rep Print Name Date VCDE Workspace Rep Print Name Date Adopter Rep Print Name Date [cabig _SRSD_Template.doc] 22 [Publish Date]

27 APPENDIX A ACRONYM LIST Term/ Abbreviation protlims API cacore cadsr CDE CSM DAC DBA DBMS EVS FCCC GUI HUPO JSP LIMS MAGE MGED PDF PM PSI/GPS RM RTM SCM SDK SDLC SDP SE SEPG SM SOP SOW SPI SQA SRS SW TBD TM UML XMI XML Description Proteomics Laboratory Information Management System Application Programming Interface Cancer Common Ontologic Reference Environment Cancer Data Standards Repository Common Data Element Common Security Module Data Access Component Database Administrator Database Management System Enterprise Vocabulary Services Fox Chase Cancer Center Graphical User Interface Human Proteomics Organisation Java Server Pages Laboratory Information Management System MicroArray and Gene Expression (MGED Society) Microarray Gene Expression Data Portable Document Format (Adobe) Project Manager Proteomics Standards Initiative/General Proteomics Standards (Human Proteomics Organisation [HUPO]) Requirements Manager Requirements Traceability Matrix Software Configuration Management Software Development Kit Software Development Lifecycle Software Development Plan Software Engineering Software Engineering Process Group Software Manager Standard Operating Procedure Statement of Work Software Process Improvement Software Quality Assurance Software Requirements Specification Software To Be Determined Test Manager Unified Modeling Language XML Metadata Interchange (Object management Group [OMG]) Extensible Markup Language (World Wide Web Consortium [W3C]) [cabig _SRSD_Template.doc] 23 [Publish Date]