System Requirements Specification (SRS) (Subsystem and Version #)

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "System Requirements Specification (SRS) (Subsystem and Version #)"

Transcription

1 of the (Subsystem and Version #) () (Document Revision Number) Contract (No.) Task (No.) GSA Contract (No.) Prepared for: The United States Department of Agriculture Food & Nutrition Service (FNS)/ Information Technology Division (ITD) 3101 Park Center Drive Alexandria, VA 22302

2 TABLE OF CONTENTS 1.0 INTRODUCTION Purpose Scope Policy System Description Points of Contact Document References Glossary ASSUMPTIONS AND CONSTRAINTS Assumptions Constraints CONTEXT FUNCTIONAL REQUIREMENTS Functional Process Requirements Requirement Statement Requirement Cross-Identification Process Requirements Function N INTERFACE REQUIREMENTS User Interfaces Hardware Interfaces Software Interfaces Communications Interfaces DATA REQUIREMENTS OPERATIONAL REQUIREMENTS Security Audit Trail Data Currency Reliability Recoverability System Availability Fault Tolerance General Performance Capacity Data Retention USER CLASSES AND MODES OF OPERATION Classes/Categories of Users User Classes Mapped to Functional Features Operational Scenarios GUIDELINES FOR REQUIREMENTS DEVELOPMENT Criteria for Good Requirement...11 ii

3 9.2 Unambiguous Complete Correct Consistent Verifiable Appropriate Implementation Independent Achievable Written in a Consistent Format Concise Ranked for Importance REQUIREMENTS TRACEABILITY MATRIX ATTACHMENTS OR APPENDICES Attachment/Appendix A Glossary Attachment/Appendix B Other...12 iii

4 <System> System Requirements Specification Revisions Revision Number Date Description iv

5 1.0 INTRODUCTION The is a formal statement of the application functional and operational requirements. It serves as a contract between the developer and the customer for whom the system is being developed. The developers agree to provide the capabilities specified. The client agrees to find the product satisfactory if it provides the capabilities specified in the SRS. Sections 1 through 9 describe the contents of the SRS in accordance with the software development life cycle (SDLC). Section 10 is provided for informational purposes only and describes the general requirements for generating a Requirements Traceability Matrix (RTM) in tandem with the SRS. It provides general guidelines for writing requirements. Section 11 provides information on optional Attachments and Appendices. A brief description of SRS functions, characteristics, and requirements structure includes the following: The SRS provides the following functions: Designing and developing the application system Evaluating the product in all subsequent phases of the lifecycle Determining the success of the project The SRS has the following characteristics: Demonstrates that the application provides value to FNS in terms of the business objectives and business processes. Contains a complete set of requirements for the application. Is solution independent. The SRS is a statement of what the application is to do not of how it works. The SRS does not commit the developers to a design. For that reason, any reference to the use of a specific technology is inappropriate in an SRS, unless the technology is listed as a system constraint (see Section 2.2). The SRS provides the following requirements, where a requirement is defined as a condition the application must meet for the customer to find the application satisfactory. A requirement has the following characteristics: Provides a benefit to the organization. That benefit is directly traceable to the business objectives and business processes of the FNS. Describes the capabilities the application must provide in business terms. Does not describe how the application provides that capability. Does not describe such design considerations as computer hardware, operating system, and database design. Is stated in unambiguous words. Its meaning is clear and unmistakable. Is stated in the positive mode, using the word "shall" (e.g., The system shall...). Only one instance of "shall" is permitted in a paragraph. 1

6 Is verifiable. 1.1 Purpose In this section, provide the purpose this application is intended to serve. Describe the business objectives and business processes from the Concept of Operations (ConOps) document and the cost-benefit analysis (CBA) that this application supports. 1.2 Scope Give a description of the intended scope of the system, how it will accomplish its purpose. 1.3 Policy Identify FNS policy decisions that affect the conduct of CM on the project. 1.4 System Description In this section, provide an overview of the physical system. Describe the system architecture, operating system, and application languages. Give an estimate of the size and complexity of the system in terms of number of user types, number of locations, interfaces, number of major processes, data capacity in business terms, numbers of major processes, etc. Summarize the conditions that created the need for the new system (or capability). Include any relevant background, such as the number of sites that are using the system. Identify other legacy or new systems with which this system interfaces. 1.5 Points of Contact List the names, titles, and roles of the major participants in the project. At a minimum, list the following: FNS IT Project Manager Development project leader User contacts FNS employee whose signature constitutes approval authority for the SRS 1.6 Document References List the documents that are sources or references for this SRS. Include meeting summaries, white paper analyses, and SDLC deliverables, as well as any other documents that preceded this SRS and provided information for the development of it. Also reference any documents that provided information on the relevant FNS version or business plan. 1.7 Glossary Include a list of terms, abbreviations, and acronyms used in this document. If the list is longer than a page, it can be included as an Appendix or Attachment to the SRS. If an attachment or appendix is used, include a reference to it here. 2

7 2.0 ASSUMPTIONS AND CONSTRAINTS 2.1 Assumptions State the assumptions associated with development of the system, where assumptions are defined as future situations, beyond the control of the project, whose outcomes influence the success of a project. The following are examples of assumptions: Availability of a hardware/software platform Pending legislation Court decisions that have not been rendered Future trends in immigration and naturalization Developments in technology 2.2 Constraints State the constraints associated with the development of the system, where constraints are defined as conditions outside the control of the project that limit the design alternatives. Constraints can be broadly categorized as technical and non-technical. The following are examples of both types of constraints: Government regulations Technical standards imposed on the solution (for example, the use of a specific Database Management System) Strategic decisions Distinguish constraints from preferences, as follows: Constraints exist because of real business conditions. For example, a delivery date is a constraint only if there are real business consequences that will happen as a result of not meeting the date. If failing to have the subject application operational by the specified date places the FNS in legal default, the date is a constraint. Preferences are arbitrary. For example, a date chosen arbitrarily is a preference. Preferences, if included in the SRS, should be noted as such. 3.0 CONTEXT Provide a context diagram of the system, with explanations as applicable. The context of a system being developed refers to the connections and relationships between the system and the outside world. Context Diagrams are often used to illustrate these connections and relationships. Exhibit 1-1 illustrates a generic context diagram. If users interact with this system, user interfaces must be shown explicitly in the context diagram. Exhibit 1-1. Generic Context Diagram 3

8 Interface Name 1 (User) Data 2 Data 1 Data 3 Data 4 Interface Name 2 System/ Application Name Interface Name 3 Data 5 Data 7 Interface Name 4 Data 6 Data FUNCTIONAL REQUIREMENTS The functional requirements describe the core functionality of the application. This section includes the data and functional process requirements. Generally, the ConOps is the source for specified or derived requirements. 4.1 Functional Process Requirements Process requirements describe what the application must do. Process requirements relate the entities and attributes from the data requirements to the users needs. State the functional process requirements in a manner that enables the reader to see broad concepts decomposed into layers of increasing detail. Exhibit 1-2 is a sample of process requirements levels stated in such a manner. It is presented only as an example of requirements headings decomposed from generalities into levels of increasing detail. Exhibit 1-2: Sample Process Requirements Section ID Requirement Description 4.1 Functional Process Requirements (this section) 4.2 Manage Naturalization Process Record Request for Naturalization Determine Eligibility for Naturalization Determine Suitability for Naturalization Determine Proficiency with the English Language Determine Knowledge of U.S. History, Law, and Customs Administer Citizenship Oath Confer Citizenship 4.3 Manage Schedules of FNS Personnel in Performing Naturalization Activities 4

9 4.1.1 Requirement Statement The requirements must be phrased with the definitive word shall and have a unique number for reference purposes. Each requirement and its identifier must be in a separated paragraph, i.e., one shall per paragraph. See also Section 10 of this document. The on-line RequisitePro FNS Template contains the standard formatting for requirements numbers, including prefixes. Exhibit 1-3 is an example of requirements stated in such a manner. Section/ Requirement ID Exhibit 1-3: Sample Process Requirements Provide Project Planning Capability SR * SR SR Requirement Definition The system shall provide a project planning capability The system shall allow authorized users to enter project plans and timelines The system shall allow authorized users to review, change, or update project plans and timelines * For this example, F is used to designate a Functional requirement. Other designations could be DF for Design Feature or STRQ for Stakeholder Request Requirement Cross-Identification Identification In Text The unique identification of requirements is an essential attribute of the requirement itself. Requirements that include lists can be handled in one of two ways. Each item in a list can have its own shall statement or be numbered (a), (b), (c), etc., or (i), (ii), (iii), etc. In this way, a requirement can be identified by its paragraph requirement number coupled with letter (a) or number (i). Caution: Bullets or other repetitive symbols are not permissible because they would not be unique identifiers. Note: The parentheses shown around the sublevel identifiers are shown for emphasis purposes only and are not part of the standard Identification In Table Sometimes requirements such as performance numbers are listed in tables. In such a case, each cell in a table is a requirement. Therefore, the first column of the table shown contains a unique identifier. Additionally, under the labels of the columns must be the letters (a), (b), (c), etc., or (i), (ii), (iii), etc., for the same reasons as discussed previously. Exhibit 1-4 illustrates the generic format of requirements in tables. Use as many columns as needed. 5

10 Requirement Number Exhibit 1-4: Generic Format of Requirements in Tables <Label 1> (a) <Label 2> (b) <Label 3> (c) <Label 4> (d) <Label 5> (e) # Requirement Requirement Requirement Requirement Requirement Note: Include the letters (a), (b), (c), etc., or (i), (ii), (iii), etc Process Requirements Process requirements may be supplemented with data flow diagrams, text, or any technique that provides the following information about the processes performed by the application: Context Detailed view of the processes, including: Data (attributes) input to and output (including reports) from processes High-level logic used inside the processes to manipulate data (do not state "how") Accesses to stored data Illustrate the high-level functions of the system in a level 0 diagram. Exhibit D1-5 depicts an example of a level-0 diagram. Caution: The major functions must match those identified in the Level-0 diagram. 4.2 Function N Provide the requirements for each function of the system, adding subsections (e.g., 4.2, 4.3, etc.) as needed and as described in Section INTERFACE REQUIREMENTS Interface requirements describe interaction of the system with users, hardware, software, and communications. 5.1 User Interfaces Describes the user interfaces that are to be implemented by the system. 5.2 Hardware Interfaces Define any hardware interfaces that are to be supported by the system, including logical structure, physical addresses, and expected behavior. 6

11 Exhibit 1-5. Sample Level-0 Data Flow Diagram Clients Orders Returned Orders Receive Order Order Information Billing Details Client Info Clients Billing Notice Client Data Client Billing Information Cash Inflow Invoice Payments Clients Orders Distribution Information Ship Product Product Product Product Storage 5.3 Software Interfaces Name the applications with which the subject application must interface. State the following for each such application: Name of application Owner of application (if external to the FNS) Details of interface (only if determined by the other application) 5.4 Communications Interfaces Describe any communications interfaces to other systems or devices, such as local area networks. 6.0 DATA REQUIREMENTS Describe the data requirements by providing data entities, their decomposition, and their definitions. The data requirements describe the business data needed by the application system. Data requirements do not describe the physical database and they are not at the level of identifying field names. For this purpose, a data dictionary should be provided, showing data entities, their attributes, and description. Refer to Section 4.1 for guidelines on formatting requirements in tables. 7

12 7.0 OPERATIONAL REQUIREMENTS Provide the operational requirements in this section. Operational requirements describe how the system will run and communicate with operations personnel. Do not state how these requirements will be satisfied. For example, in the Reliability section, answer the question, How reliable must the system be? Do not state what steps will be taken to provide reliability. The rules for stating requirements, outlined in Section 4.1, also apply to these requirements. Distinguish preferences from requirements. Requirements are based on business needs. Preferences are not. If, for example, the user expresses a desire for sub-second response but does not have a business-related reason for needing it, that desire is a preference. Other applicable requirements on system attributes may be added to the list of subsections below. If there is a ConOps for the system or application, all subsections listed in Section 6 of the ConOps document must be addressed in Section 7 of the SRS. 7.1 Security The Security Section describes the need to control access to the data. This includes controlling who may view and alter application data. Use the following criteria: State the consequences of the following breaches of security in the subject application: Erasure or contamination of application data Disclosure of Government secrets Disclosure of privileged information about individuals State the type(s) of security required. Include the need for the following as appropriate: State if there is a need to control access to the facility housing the application. State the need to control access by class of users. For example, No user may access any part of this application who does not have at least a (specified) clearance. State the need to control access by data attribute. State, for example, if one group of users may view an attribute but may not update it while another type of user may update or view it. State the need to control access based on system function. State, for example, if there is a need to grant access to certain system functions to one type of users, but not to others. For example, "The system shall make Function N available to the System Administrator only." State if there is a need for accreditation of the security measures adopted for this application. For example, C2 protection must be certified by an independent authorized organization. 7.2 Audit Trail List the activities that will be recorded in the application s audit trail. For each activity, list the data to be recorded. 8

13 7.3 Data Currency Data currency is a measure of how recent data are. This section answers the question, When the application responds to a request for data, how current must the data be? Answer that question for each type of data request. 7.4 Reliability Reliability is the probability that the system will be able to process all work correctly and completely without being aborted. Reliability is evaluated as follows: State the following in this section: What damage can result from failure of this system? Loss of human life Complete or partial loss of the ability to perform a mission-critical function Loss of revenue Loss of employee productivity What is the minimum acceptable level of reliability? State required reliability in any of the following ways: Mean Time Between Failure is the number of time units the system is operable before the first failure occurs. Mean Time To Failure is computed as the number of time units before the system is operable divided by the number of failures during the time period. Mean Time To Repair is computed as the number of time units required to perform system repair divided by the number of repairs during the time period. 7.5 Recoverability Recoverability is the ability to restore function and data in the event of a failure. Answer the following questions in this section: In the event the application is unavailable to users (down) because of a system failure, how soon after the failure is detected must function be restored? In the event the database is corrupted, to what level of currency must it be restored? For example The database must be capable of being restored to its condition of no more than 1 hour before the corruption occurred. If the processing site (hardware, data, and onsite backup) is destroyed, how soon must the application be able to be restored? 7.6 System Availability System availability is the time when the application must be available for use. Required system availability is used in determining when maintenance may be performed. 9

14 In this section, state the hours (including time zone) during which the application is to be available to users. For example, The application must be available to users Monday through Friday between the hours of 6:30 a.m. and 5:30 p.m. EST. If the application must be available to users in more than one time zone, state the earliest start time and the latest stop time. Include the times when usage is expected to be at its peak. These are times when system unavailability is least acceptable. 7.7 Fault Tolerance Fault tolerance is the ability to remain partially operational during a failure. Describe the following in this section: Which functions do not need to be available at all times? If a component fails, what (if any) functions must the application continue to provide? What level of performance degradation is acceptable? For most applications, there are no fault tolerance requirements. When a portion of the application is unavailable, there is no need to be able to use the remainder of the application. 7.8 General Performance Describe the requirements for the following: Response time for queries and updates Throughput Expected rate of user activity (for example, number of transactions per hour, day, or month) Specific performance requirements related to a specific functional requirement should be listed with that functional requirement (see Section 4.1 for guidance). 7.9 Capacity List the required capacities and expected volumes of data in business terms. For example, state the number of cases about which the application will have to store data. For example, The system shall be able to process a projected volume of 600 applications for naturalization per month. State capacities in terms of the business. Do not state capacities in terms of system memory requirements or disk space Data Retention Describe the length of time the data must be retained. For example, Information about an application for naturalization shall be retained in immediately accessible form for 3 years after receipt of the application. 8.0 USER CLASSES AND MODES OF OPERATION 8.1 Classes/Categories of Users Identify and describe the major classes/categories of users that will interact with the system (or capability). 10

15 8.2 User Classes Mapped to Functional Features In this section provide an explanation of what functions each user organization can access or use. Define any variations in the user work process that correspond to the use of the system by the different classes of users. 8.3 Operational Scenarios Develop sample usage scenarios for each major user class that show what inputs will initiate the system functions, system interactions, and what outputs are expected to be generated by the system. The scenarios should be comprehensive, to the extent that all user types and all major functions are covered. 9.0 GUIDELINES FOR REQUIREMENTS DEVELOPMENT The following subsections are not components of the SRS. They are given here as guidelines for developing requirements. 9.1 Criteria for Good Requirement Good requirements are necessary for the development of systems that satisfy user expectations. Good requirements support clear design, development, and test procedures. A good requirement has several important characteristics, as described herein. These criteria for good quality requirements are based on the IEEE Std 830, Recommended Practice for Software Requirements Specifications, dated November 1998, and are described herein. 9.2 Unambiguous It has only one interpretation. It avoids technical jargon. If specific technological terms are required for clarity, they must be defined in the requirement. 9.3 Complete It contains all information needed to write software for the requirement that is acceptable to the customer. It does not contain the phrase to be determined (TBD) unless it is accompanied by a description of the conditions required for its elimination, as well as a specification of who is responsible for its elimination. 9.4 Correct It adequately reflects the desired software function and performance. 9.5 Consistent It does not conflict with other requirements within the same system or related systems. It agrees with requirements defined in higher-level system documentation. 9.6 Verifiable It can be tested and confirmed. 11

16 9.7 Appropriate It adds value to an organization by improving its process. It is within the scope of the current statement of work. 9.8 Implementation Independent It can be satisfied by more than one design and implementation. It does not mention specific hardware or software. 9.9 Achievable It can be implemented within project time and budget constraints using available technology Written in a Consistent Format It begins with The system shall. Multiple sentences are phrased, The system shall also. (It is preferable that each requirement be stated in its own paragraph, i.e., one shall statement per paragraph.) 9.11 Concise It describes a single need. It is as short as possible without adversely impacting understandability Ranked for Importance It has an identifier to distinguish it in a document and for reference purposes REQUIREMENTS TRACEABILITY MATRIX When preparing an SRS, during the Requirements Definition Phase, also, create an initial RTM. Provide the initial RTM as a standalone document. Requirements and their unique identifiers appearing in the body of the SRS must appear verbatim in the RTM. The other significant column of the RTM at this stage of its development is the source of the requirement, which for the most part would come from the associated ConOps. Additionally, every requirement entry in the RTM must be identified with its source ATTACHMENTS OR APPENDICES Note: Attachments are listed as shown in the SRS outline at the end of this document. They are numbered in sequence here as part of the descriptive text Attachment/Appendix A Glossary If a glossary has not been provided as Section 1.6, in this attachment (or appendix), provide business terms peculiar to the system as well as the acronyms and abbreviations used in the document Attachment/Appendix B Other Provide any other attachments (or appendices) as needed; e.g., Data Dictionary. 12

17 Note: An initial RTM shall be provided in the SRS. The final RTM will be provided as a standalone document. See Section

Software Project Management Plan (SPMP)

Software Project Management Plan (SPMP) Software Project Management Plan (SPMP) The basic template to be used is derived from IEEE Std 1058-1998, IEEE Standard for Software Project Management Plans. The following is a template for the SPMP.

More information

Software Test Plan (STP) Template

Software Test Plan (STP) Template (STP) Template Items that are intended to stay in as part of your document are in bold; explanatory comments are in italic text. Plain text is used where you might insert wording about your project. This

More information

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director

System Development and Life-Cycle Management (SDLCM) Methodology. Approval CISSCO Program Director System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies content and format requirements for a Physical

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

ITS Projects Systems Engineering Process Compliance Checklist

ITS Projects Systems Engineering Process Compliance Checklist ITS Projects Systems Engineering Process Compliance Checklist FHWA Final Rule (23 CFR 940) This checklist is to be completed by the MDOT or LPA Project Management Staff. Please refer to the accompanying

More information

DATA ITEM DESCRIPTION

DATA ITEM DESCRIPTION DATA ITEM DESCRIPTION Form Approved OMB NO.0704-0188 Public reporting burden for collection of this information is estimated to average 110 hours per response, including the time for reviewing instructions,

More information

Design Document Version 0.0

Design Document Version 0.0 Software Development Templates Design Document Version 0.0 Description of Project DOCUMENT NO: VERSION: CONTACT: EMAIL: Ivan Walsh DATE: 4/13/2004 Distribution is subject to copyright. Design Document

More information

Software Design Document (SDD) Template

Software Design Document (SDD) Template (SDD) Template Software design is a process by which the software requirements are translated into a representation of software components, interfaces, and data necessary for the implementation phase.

More information

Capacity Plan. Template. Version X.x October 11, 2012

Capacity Plan. Template. Version X.x October 11, 2012 Template Version X.x October 11, 2012 This is an integral part of infrastructure and deployment planning. It supports the goal of optimum provisioning of resources and services by aligning them to business

More information

Montana Department of Transportation Information Services Division. System Development Life Cycle (SDLC) Guide

Montana Department of Transportation Information Services Division. System Development Life Cycle (SDLC) Guide Montana Department of Transportation Information Services Division System Development Life Cycle (SDLC) Guide Version 2 August 2, 2007 \mdt_sdlc_process\mdt_sdlc_v02.doc Table of Contents 1 Business Analysis...3

More information

SYSTEMS AND SOFTWARE REQUIREMENTS SPECIFICATION (SSRS) TEMPLATE. Version A.4, January 2014 FOREWORD DOCUMENT CONVENTIONS

SYSTEMS AND SOFTWARE REQUIREMENTS SPECIFICATION (SSRS) TEMPLATE. Version A.4, January 2014 FOREWORD DOCUMENT CONVENTIONS SYSTEMS AND SOFTWARE REQUIREMENTS SPECIFICATION (SSRS) TEMPLATE Version A.4, January 2014 FOREWORD This document was written to provide software development projects with a template for generating a System

More information

Lecture 17: Requirements Specifications

Lecture 17: Requirements Specifications Lecture 17: Requirements Specifications Why we need to write specifications Purpose and audience Choosing an appropriate size and formality Desiderata for Specifications Properties of good specifications

More information

DATA ITEM DESCRIPTION

DATA ITEM DESCRIPTION DD Form 1664, APR 89 Previous editions are obsolete Page 1 of 6 Pages 135/123 DATA ITEM DESCRIPTION Form Approved OMB NO.0704-0188 Public reporting burden for collection of this information is estimated

More information

8. Master Test Plan (MTP)

8. Master Test Plan (MTP) 8. Master Test Plan (MTP) The purpose of the Master Test Plan (MTP) is to provide an overall test planning and test management document for multiple levels of test (either within one project or across

More information

AMERICAN SOCIETY OF CIVIL ENGINEERS. Standards Writing Manual for ASCE Standards Committees. Prepared by ASCE Codes and Standards Committee

AMERICAN SOCIETY OF CIVIL ENGINEERS. Standards Writing Manual for ASCE Standards Committees. Prepared by ASCE Codes and Standards Committee AMERICAN SOCIETY OF CIVIL ENGINEERS Standards Writing Manual for ASCE Standards Committees Prepared by ASCE Codes and Standards Committee Revised August 20, 2010 Contents Section Page 1.0 Scope, purpose,

More information

From Chaos to Clarity: Embedding Security into the SDLC

From Chaos to Clarity: Embedding Security into the SDLC From Chaos to Clarity: Embedding Security into the SDLC Felicia Nicastro Security Testing Services Practice SQS USA Session Description This session will focus on the security testing requirements which

More information

Hardware Requirements Specification For

<Project Name> Hardware Requirements Specification For <Subsystem or Feature> Hardware Requirements Specification For Version [Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square

More information

Functional Specification Document

Functional Specification Document Functional Specification Document Table of Contents 1. Introduction... - 5-1.1 Purpose...- 5-1.2 Executive Summary...- 5-1.3 Scope...- 5-1.4 Definitions, Acronyms and Abbreviations...- 5-1.5 References...-

More information

DATA ITEM DESCRIPTION

DATA ITEM DESCRIPTION DATA ITEM DESCRIPTION Form Approved OMB NO.0704-0188 Public reporting burden for collection of this information is estimated to average 110 hours per response, including the time for reviewing instructions,

More information

Revision History Revision Date 3.0 14.02.10. Changes Initial version published to http://www.isasecure.org

Revision History Revision Date 3.0 14.02.10. Changes Initial version published to http://www.isasecure.org SDLA-312 ISA Security Compliance Institute Security Development Lifecycle Assurance - Security Development Lifecycle Assessment v3.0 Lifecycle Phases Number Phase Name Description PH1 Security Management

More information

Appendix 2-A. Application and System Development Requirements

Appendix 2-A. Application and System Development Requirements Appendix 2-A. Application and System Development Requirements Introduction AHRQ has set up a Distributed Systems Engineering Lab (DSEL) to support all internal development efforts and provide a facility

More information

System Requirement Checklist

System Requirement Checklist System Requirement Checklist Page 1 System Requirement Checklist The System Requirement (SR) document template (IDA-MS-SR) provides guidance and template material for use by IDA projects in producing project-specific

More information

REQUIREMENTS SPECIFICATION AND MANAGEMENT. Requirements Analysis and Specification

REQUIREMENTS SPECIFICATION AND MANAGEMENT. Requirements Analysis and Specification REQUIREMENTS SPECIFICATION AND MANAGEMENT In this note we give the requirements process in a software organization, a template for the requirements document, and the process to manage changes to the requirements.

More information

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME >

PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > PROJECT MANAGEMENT PLAN TEMPLATE < PROJECT NAME > Date of Issue: < date > Document Revision #: < version # > Project Manager: < name > Project Management Plan < Insert Project Name > Revision History Name

More information

INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM)

INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) Guide for Integrated Software Quality Management (ISQM) GUIDE FOR INTEGRATED SOFTWARE QUALITY MANAGEMENT (ISQM) SEPTEMBER 2012 (Updated July 2014 see next page) American Bureau of Shipping Incorporated

More information

Project Management Planning

Project Management Planning Develop Project Tasks One of the most important parts of a project planning process is the definition of activities that will be undertaken as part of the project. Activity sequencing involves dividing

More information

CalMod Design-Build Electrification Services

CalMod Design-Build Electrification Services SECTION 01800 SYSTEMS INTEGRATION AND INTEGRATOR REQUIREMENTS PART 1 GENERAL DESCRIPTION A. This section specifies the system-wide integration requirements for the Caltrain Electrification system, i.e.

More information

Software Requirements

Software Requirements Software Engineering Software Requirements Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce the concepts of user and system requirements To describe functional and

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

Information Technology Project Oversight Framework

Information Technology Project Oversight Framework i This Page Intentionally Left Blank i Table of Contents SECTION 1: INTRODUCTION AND OVERVIEW...1 SECTION 2: PROJECT CLASSIFICATION FOR OVERSIGHT...7 SECTION 3: DEPARTMENT PROJECT MANAGEMENT REQUIREMENTS...11

More information

3SL. Requirements Definition and Management Using Cradle

3SL. Requirements Definition and Management Using Cradle 3SL Requirements Definition and Management Using Cradle November 2014 1 1 Introduction This white paper describes Requirements Definition and Management activities for system/product development and modification

More information

DATA ITEM DESCRIPTION

DATA ITEM DESCRIPTION DATA ITEM DESCRIPTION Form Approved OMB NO.0704-0188 Public reporting burden for collection of this information is estimated to average 110 hours per response, including the time for reviewing instructions,

More information

Risk/Issue Management Plan

Risk/Issue Management Plan Risk/Issue Management Plan Centralized Revenue Opportunity System November 2014 Version 2.0 This page intentionally left blank Table of Contents 1. Overview... 3 1.1 Purpose... 3 1.2 Scope... 3 2. Roles

More information

Enterprise Test Management Standards

Enterprise Test Management Standards Enterprise Test Management Standards Version 4.0 09/28/2012 Document Number: FSA_TOADG_STDS_TEST.TMS_001 Document Version Control This section summarizes this document revision history. Each entry includes

More information

Sofware Requirements Engineeing

Sofware Requirements Engineeing Sofware Requirements Engineeing Three main tasks in RE: 1 Elicit find out what the customers really want. Identify stakeholders, their goals and viewpoints. 2 Document write it down (). Understandable

More information

CDC UNIFIED PROCESS PRACTICES GUIDE

CDC UNIFIED PROCESS PRACTICES GUIDE Document Purpose The purpose of this document is to provide guidance on the practice of Requirements Management and to describe the practice overview, requirements, best practices, activities, and key

More information

PROJECT MANAGEMENT METHODOLOGY SECTION 3 -- PLANNING PHASE

PROJECT MANAGEMENT METHODOLOGY SECTION 3 -- PLANNING PHASE PROJECT MANAGEMENT METHODOLOGY SECTION 3 -- PLANNING PHASE Table of Contents Introduction...3-1 Overview...3-1 The Process and the Project Plan...3-1 Project Objectives and Scope...3-1 Work Breakdown Structure...3-1

More information

The Project Management Plan will be used to guide, communicate and coordinate project efforts.

The Project Management Plan will be used to guide, communicate and coordinate project efforts. F.1 General Implementation Contractor Deliverables include critical system planning and development components. Sufficient deliverables have been identified at key steps in the project to guide the project

More information

Service Experience Group 10/1/2014. Support Level Agreement Version 2.0

Service Experience Group 10/1/2014. Support Level Agreement Version 2.0 Service Experience Group 10/1/2014 Version 2.0 Table of Contents 1. Purpose... 1 2. Scope of Support... 2 2.1 Included... 2 2.2 Not Included... 2 3. Support Fees... 3 4. Customer Obligation... 4 5. Spirent

More information

INTERNATIONAL STANDARD ON AUDITING 800 SPECIAL CONSIDERATIONS AUDITS OF FINANCIAL STATEMENTS PREPARED IN ACCORDANCE WITH SPECIAL PURPOSE FRAMEWORKS

INTERNATIONAL STANDARD ON AUDITING 800 SPECIAL CONSIDERATIONS AUDITS OF FINANCIAL STATEMENTS PREPARED IN ACCORDANCE WITH SPECIAL PURPOSE FRAMEWORKS INTERNATIONAL STANDARD ON AUDITING 800 SPECIAL CONSIDERATIONS AUDITS OF FINANCIAL STATEMENTS PREPARED IN ACCORDANCE WITH SPECIAL PURPOSE FRAMEWORKS (Effective for audits of financial statements for periods

More information

ISO 9001 for Small Projects

ISO 9001 for Small Projects Chapter 8 ISO 9001 for Small Projects INTRODUCTION TO ISO 9001 FOR SMALL PROJECTS Many organizations are intimidated by the amount of documentation associated with ISO 9001 conformance requirements. The

More information

SAMPLE. Software Requirements Specifications. Version <1.0>

SAMPLE. <Company Name> <Project Name> Software Requirements Specifications. Version <1.0> Version [Note: The following template is provided for use with the Unified Process for EDUcation. Text enclosed in square brackets and displayed in blue italics (style=infoblue)

More information

Accounts Receivable System Administration Manual

Accounts Receivable System Administration Manual Accounts Receivable System Administration Manual Confidential Information This document contains proprietary and valuable, confidential trade secret information of APPX Software, Inc., Richmond, Virginia

More information

Project Type Guide. Project Planning and Management (PPM) V2.0. Custom Development Version 1.1 January 2014. PPM Project Type Custom Development

Project Type Guide. Project Planning and Management (PPM) V2.0. Custom Development Version 1.1 January 2014. PPM Project Type Custom Development Project Planning and Management (PPM) V2.0 Project Type Guide Custom Development Version 1.1 January 2014 Last Revision: 1/22/2014 Page 1 Project Type Guide Summary: Custom Development Custom software

More information

GAMP 4 to GAMP 5 Summary

GAMP 4 to GAMP 5 Summary GAMP 4 to GAMP 5 Summary Introduction This document provides summary information on the GAMP 5 Guide and provides a mapping to the previous version, GAMP 4. It specifically provides: 1. Summary of Need

More information

VAIL-Plant Asset Integrity Management System. Software Development Process

VAIL-Plant Asset Integrity Management System. Software Development Process VAIL-Plant Asset Integrity Management System Software Development Process Document Number: VAIL/SDP/2008/008 Engineering For a Safer World P u b l i c Approved by : Ijaz Ul Karim Rao Revision: 0 Page:2-of-15

More information

INTERMEDIATE QUALIFICATION

INTERMEDIATE QUALIFICATION PROFESSIONAL QUALIFICATION SCHEME INTERMEDIATE QUALIFICATION SERVICE LIFECYCLE SERVICE DESIGN CERTIFICATE SYLLABUS Page 2 of 18 Contents SERVICE DESIGN CERTIFICATE 4 Target Candidate 4 Prerequisite Entry

More information

System Development Life Cycle Guide

System Development Life Cycle Guide TEXAS DEPARTMENT OF INFORMATION RESOURCES System Development Life Cycle Guide Version 1.1 30 MAY 2008 Version History This and other Framework Extension tools are available on Framework Web site. Release

More information

Software Project Management Plan

<name of project> Software Project Management Plan The document in this file is adapted from the IEEE standards for Software Project Management Plans, 1058-1998, which conforms to the requirements of ISO standard 12207 Software Life Cycle Processes. Tailor

More information

AC 20-148 REUSABLE SOFTWARE COMPONENTS

AC 20-148 REUSABLE SOFTWARE COMPONENTS AC 20-148 REUSABLE SOFTWARE COMPONENTS December 7, 2004 12/7/04 AC 20-148 CONTENTS Paragraph Title Page 1. Purpose....1 2. Motivation for this Guidance....1 3. Document Overview...1 4. General Guidelines

More information

This is the software system proposal document for the project sponsored by .

This is the software system proposal document for the <name of the project> project sponsored by <name of sponsor>. Guide to Preparing the SOFTWARE PROJECT MANAGEMENT PLAN R. Buckley CSc 190 Senior Project Department of Computer Science - College of Engineering and Computer Science California State University, Sacramento

More information

For Version 1.0

For <Project> Version 1.0 Oklahoma Department of Human Services Data Services Division Service-Oriented Architecture (SOA) For Version 1.0 Table of Contents 1. Service Oriented Architecture (SOA) Scope...

More information

Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP

Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP Appendix M INFORMATION TECHNOLOGY (IT) YOUTH APPRENTICESHIP PROGRAMMING & SOFTWARE DEVELOPMENT AND INFORMATION SUPPORT & SERVICES PATHWAY SOFTWARE UNIT UNIT 5 Programming & and Support & s: (Unit 5) PAGE

More information

Electronic Medical Record (EMR) Request for Proposal (RFP)

Electronic Medical Record (EMR) Request for Proposal (RFP) Electronic Medical Record (EMR) Request for Proposal (RFP) SAMPLE Proposal Due: [INSERT DESIRED DUE DATE] Table of Contents SECTION 1 RFP INFORMATION... 2 I. Introduction... 2 A. Purpose and Background...

More information

Department of Finance and Deregulation 2011/004 Portfolio Panels for IT Services ATTACHMENT A

Department of Finance and Deregulation 2011/004 Portfolio Panels for IT Services ATTACHMENT A 2011/004 Portfolio Panels for IT Services Definition of IT Services The definition for IT Services supports the Portfolio Panel Policy and reflects the Victorian eservices model. Key Service Category Management

More information

Template K Implementation Requirements Instructions for RFP Response RFP #

Template K Implementation Requirements Instructions for RFP Response RFP # Template K Implementation Requirements Instructions for RFP Response Table of Contents 1.0 Project Management Approach... 3 1.1 Program and Project Management... 3 1.2 Change Management Plan... 3 1.3 Relationship

More information

Infrastructure Information Security Assurance (ISA) Process

Infrastructure Information Security Assurance (ISA) Process Infrastructure Information Security Assurance (ISA) Process Handbook AS-805-B March 2005 Transmittal Letter A. Explanation. As part of the Postal Service s efforts to enhance security across all technology

More information

Distinguished Budget Presentation Awards Program Government Finance Officers Association. Awards Criteria (and explanations of the Criteria)

Distinguished Budget Presentation Awards Program Government Finance Officers Association. Awards Criteria (and explanations of the Criteria) 1 Distinguished Budget Presentation Awards Program Government Finance Officers Association Awards Criteria (and explanations of the Criteria) #C1. Mandatory: The document shall include a table of contents

More information

US Department of Education Federal Student Aid Integration Leadership Support Contractor January 25, 2007

US Department of Education Federal Student Aid Integration Leadership Support Contractor January 25, 2007 US Department of Education Federal Student Aid Integration Leadership Support Contractor January 25, 2007 Task 18 - Enterprise Data Management 18.002 Enterprise Data Management Concept of Operations i

More information

NABL NATIONAL ACCREDITATION

NABL NATIONAL ACCREDITATION NABL 160 NABL NATIONAL ACCREDITATION BOARD FOR TESTING AND CALIBRATION LABORATORIES GUIDE for PREPARING A QUALITY MANUAL ISSUE NO. : 05 AMENDMENT NO : 00 ISSUE DATE: 27.06.2012 AMENDMENT DATE: -- Amendment

More information

CLOUD SERVICE SCHEDULE

CLOUD SERVICE SCHEDULE CLOUD SERVICE SCHEDULE 1 DEFINITIONS Defined terms in the Standard Terms and Conditions have the same meaning in this Service Schedule unless expressed to the contrary. In this Service Schedule, unless

More information

SECTION 1: INTRODUCTION

SECTION 1: INTRODUCTION SECTION 1: INTRODUCTION Section 1: Introduction 1 INTRODUCTION Information Systems (IS) in the Special Supplemental Nutrition Program for Women, Infants and Children (WIC Program) support a number of program

More information

CSC 342 Semester I: 1425-1426H (2004-2005 G)

CSC 342 Semester I: 1425-1426H (2004-2005 G) CSC 342 Semester I: 1425-1426H (2004-2005 G) Software Engineering Systems Analysis: Requirements Structuring Context & DFDs. Instructor: Dr. Ghazy Assassa Software Engineering CSC 342/Dr. Ghazy Assassa

More information

MODEL SCHEDULING SPECIFICATION

MODEL SCHEDULING SPECIFICATION MODEL SCHEDULING SPECIFICATION Introduction (Not part of the specification) Before implementation, we recommend that your contract and this provision be reviewed and modified to ensure compatibility with

More information

3.11 System Administration

3.11 System Administration 3.11 The functional area is intended to contribute to the overall flexibility, efficiency, and security required for operating and maintaining the system. Depending on the architecture of the system, system

More information

DATA ITEM DESCRIPTION

DATA ITEM DESCRIPTION DATA ITEM DESCRIPTION Form Approved OMB NO.0704-0188 Public reporting burden for collection of this information is estimated to average 110 hours per response, including the time for reviewing instructions,

More information

unless the manufacturer upgrades the firmware, whereas the effort is repeated.

unless the manufacturer upgrades the firmware, whereas the effort is repeated. Software Validation in Accredited Laboratories A Practical Guide Gregory D. Gogates Fasor Inc., 3101 Skippack Pike, Lansdale, Pennsylvania 19446-5864 USA g.gogates@ieee.org www.fasor.com Abstract Software

More information

DATA ITEM DESCRIPTION

DATA ITEM DESCRIPTION DATA ITEM DESCRIPTION Form Approved OMB NO.0704-0188 Public reporting burden for collection of this information is estimated to average 110 hours per response, including the time for reviewing instructions,

More information

Project Risk Management: IV&V as Insurance for Project Success

Project Risk Management: IV&V as Insurance for Project Success Project Risk Management: IV&V as Insurance for Project Success Introduction Software development projects can be expensive and risky: Ever more complex mission-critical requirements lead to increasingly

More information

Use-Case Analysis. ! What is it? ! From where did it come? ! Now part of UML

Use-Case Analysis. ! What is it? ! From where did it come? ! Now part of UML Use-Case Analysis Use-Case Analysis! What is it?! An informal, user-friendly, technique useful for functional requirements analysis and specification! From where did it come?! Ivar Jacobson, a Swedish

More information

PHASE 5: DESIGN PHASE

PHASE 5: DESIGN PHASE PHASE 5: DESIGN PHASE During the Design Phase, the system is designed to satisfy the requirements identified in the previous phases. The requirements identified in the Requirements Analysis Phase are transformed

More information

Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews

Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews Department of Health and Human Services Centers for Medicare & Medicaid Services Center for Consumer Information and Insurance Oversight Guide to Enterprise Life Cycle Processes, Artifacts, and Reviews

More information

Department of Administration Portfolio Management System 1.3 June 30, 2010

Department of Administration Portfolio Management System 1.3 June 30, 2010 E 06/ 30/ 2010 EX AM PL 1. 3 06/ 28/ 2010 06/ 24/ 2010 06/ 23/ 2010 06/ 15/ 2010 06/ 18/ 2010 Portfolio System 1.3 June 30, 2010 Contents Section 1. Project Overview... 1 1.1 Project Description... 1 1.2

More information

Stages of the Audit Process

Stages of the Audit Process Chapter 5 Stages of the Audit Process Learning Objectives Upon completion of this chapter you should be able to explain: LO 1 Explain the audit process. LO 2 Accept a new client or confirming the continuance

More information

Certified Professional in Configuration Management Glossary of Terms

Certified Professional in Configuration Management Glossary of Terms Certified Professional in Configuration Management Glossary of terms used in Configuration Management Issue 2007.07 Association of the International Certified Configuration Manager e.v. Copyright 2007,

More information

System Development and Life-Cycle Management (SDLCM) Methodology

System Development and Life-Cycle Management (SDLCM) Methodology System Development and Life-Cycle Management (SDLCM) Methodology Subject Type Standard Approval CISSCO Program Director A. PURPOSE This standard specifies the content and format requirements for a Software

More information

Notice of Clarification

Notice of Clarification U. S. ELECTION ASSISTANCE COMMISSION VOTING SYSTEM TESTING AND CERTIFICATION PROGRAM 1225 New York Avenue, NW, Suite 1100 Washington, DC. 20005 Notice of Clarification NOC 09-004: Development and Submission

More information

A PLANNING MODEL FOR ABET ENGINEERING CRITERIA 2000

A PLANNING MODEL FOR ABET ENGINEERING CRITERIA 2000 A PLANNING MODEL FOR ABET ENGINEERING CRITERIA 2000 M. Dayne Aldridge and Larry Benefield College of Engineering Auburn University, AL 36849 Introduction ABET Engineering Criteria 2000 provides a new basis

More information

Microsoft Project Server 2010 Administrator's Guide

Microsoft Project Server 2010 Administrator's Guide Microsoft Project Server 2010 Administrator's Guide 1 Copyright This document is provided as-is. Information and views expressed in this document, including URL and other Internet Web site references,

More information

NEW HAMPSHIRE RETIREMENT SYSTEM

NEW HAMPSHIRE RETIREMENT SYSTEM NEW HAMPSHIRE RETIREMENT SYSTEM Auditors Report on Internal Control Over Financial Reporting and on Compliance and Other Matters Based on an Audit of Financial Statements Performed in Accordance With Government

More information

Document Control Information

Document Control Information Document Control Information Document Details Document Name Purpose of Document Document Version Number 5.4 Document Status Document Owner Prepared By The ITIL Intermediate Qualification Service Design

More information

HIPAA Security. 2 Security Standards: Administrative Safeguards. Security Topics

HIPAA Security. 2 Security Standards: Administrative Safeguards. Security Topics HIPAA Security SERIES Security Topics 1. Security 101 for Covered Entities 5. 2. Security Standards - Organizational, Security Policies Standards & Procedures, - Administrative and Documentation Safeguards

More information

4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java

4.1 Domain Analysis. Object-Oriented Software Engineering Practical Software Development using UML and Java 4.1 Domain Analysis Object-Oriented Software Engineering Practical Software Development using UML and Java Chapter 4: Developing The process by which a software engineer learns about the domain to better

More information

INTERNATIONAL STANDARD ON AUDITING 200 OBJECTIVE AND GENERAL PRINCIPLES GOVERNING AN AUDIT OF FINANCIAL STATEMENTS CONTENTS

INTERNATIONAL STANDARD ON AUDITING 200 OBJECTIVE AND GENERAL PRINCIPLES GOVERNING AN AUDIT OF FINANCIAL STATEMENTS CONTENTS INTERNATIONAL STANDARD ON AUDITING 200 OBJECTIVE AND GENERAL PRINCIPLES GOVERNING (Effective for audits of financial statements for periods beginning on or after December 15, 2005. The Appendix contains

More information

Software Quality Assurance Plan

Software Quality Assurance Plan For Database Applications Document ID: Version: 2.1a Planning Installation & Acceptance Integration & Test Requirements Definition Design Development 1 / 54 Copyright 2000-2006 Digital Publications LLC.

More information

Glossary of Object Oriented Terms

Glossary of Object Oriented Terms Appendix E Glossary of Object Oriented Terms abstract class: A class primarily intended to define an instance, but can not be instantiated without additional methods. abstract data type: An abstraction

More information

Bureau of Land Management. Information System Decommissioning Guide

Bureau of Land Management. Information System Decommissioning Guide Department Bureau of the Land Interior Management Bureau of Land Management Information System Decommissioning Guide Version Control Log Date Version # Author Description January 11, 2011 0.1 WO-550 Original

More information

Use Cases. Massimo Felici. Massimo Felici Use Cases c 2004 2011

Use Cases. Massimo Felici. Massimo Felici Use Cases c 2004 2011 Use Cases Massimo Felici Use Cases 1 Support requirements engineering activities and the requirement process Capture what a system is supposed to do, i.e., systems functional requirements Describe sequences

More information

Office of Inspector General

Office of Inspector General DEPARTMENT OF HOMELAND SECURITY Office of Inspector General Security Weaknesses Increase Risks to Critical United States Secret Service Database (Redacted) Notice: The Department of Homeland Security,

More information

Criteria for Flight Project Critical Milestone Reviews

Criteria for Flight Project Critical Milestone Reviews Criteria for Flight Project Critical Milestone Reviews GSFC-STD-1001 Baseline Release February 2005 Approved By: Original signed by Date: 2/19/05 Richard M. Day Director, Independent Technical Authority

More information

HIPAA CRITICAL AREAS TECHNICAL SECURITY FOCUS FOR CLOUD DEPLOYMENT

HIPAA CRITICAL AREAS TECHNICAL SECURITY FOCUS FOR CLOUD DEPLOYMENT HIPAA CRITICAL AREAS TECHNICAL SECURITY FOCUS FOR CLOUD DEPLOYMENT A Review List This paper was put together with Security in mind, ISO, and HIPAA, for guidance as you move into a cloud deployment Dr.

More information

Overview of: A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition

Overview of: A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition Overview of A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition Overview of: A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fourth Edition 1 Topics for Discussion

More information

NOTICE: This publication is available at: http://www.nws.noaa.gov/directives/

NOTICE: This publication is available at: http://www.nws.noaa.gov/directives/ Department of Commerce $ National Oceanic & Atmospheric Administration $ National Weather Service NATIONAL WEATHER SERVICE INSTRUCTION 80-304 April 21, 2009 Science and Technology Systems Engineering SOFTWARE

More information

Oracle Utilities Meter Data Management

Oracle Utilities Meter Data Management Oracle Utilities Meter Data Management Configuration Guide Release 2.0.0 E18293-01 August 2010 Oracle Utilities Meter Data Management/Meter Data Management Installation and Configuration Guide, Volume

More information

ALS Configuration Management Plan. Nuclear Safety Related

ALS Configuration Management Plan. Nuclear Safety Related Westinghouse Non-Proprietary Class 3 Advanced Logic System 6002-00002-NP, Rev. 10 Function Author Nuclear Safety Related July 2014 APPROVALS Name and Signature Anthony C. Pagano* Integrated Process Lead,

More information

ISMS Implementation Guide

ISMS Implementation Guide atsec information security corporation 9130 Jollyville Road, Suite 260 Austin, TX 78759 Tel: 512-615-7300 Fax: 512-615-7301 www.atsec.com ISMS Implementation Guide atsec information security ISMS Implementation

More information

SLIM Estimate and Microsoft Project Best Practices

SLIM Estimate and Microsoft Project Best Practices SLIM Estimate and Microsoft Project Best Practices There are many activities to perform during the life of a software development project. No single tool provides all of the functionality or data that

More information

Office of Inspector General

Office of Inspector General Office of Inspector General DEPARTMENT OF HOMELAND SECURITY U.S. Department of Homeland Security Washington, DC 20528 Office of Inspector General Security Weaknesses Increase Risks to Critical DHS Databases

More information

Software Requirements. Specification. Day Health Manager. for. Version 1.1. Prepared by 4yourhealth 2/10/2015

Software Requirements. Specification. Day Health Manager. for. Version 1.1. Prepared by 4yourhealth 2/10/2015 Software Requirements Specification. for Day Health Manager Version 1.1 Prepared by 4yourhealth Senior Project 2015 2/10/2015 Table of Contents Table of Contents Revision History Introduction Purpose Document

More information

Vision Document CUSTOMER RELATION MANAGEMENT SYSTEM Version 1.0

Vision Document CUSTOMER RELATION MANAGEMENT SYSTEM Version 1.0 Vision Document CUSTOMER RELATION MANAGEMENT SYSTEM Version 1.0 Submitted in partial fulfillment of the requirements of the degree of Master of Software Engineering CIS 895 MSE Project Kansas State University

More information