SDLC - System Requirements Specification Outline
SDLC - System Requirements Specification Outline
SDLC - System Requirements Specification Outline
March 2009
Revision History
REVISION HISTORY REVISION/WORKSITE # SDLC Outlines - #5358 OSI Admin 5358v2 DATE OF RELEASE August 29, 2008 03/26/09 OWNER OSI - PMO OSI-PMO SUMMARY OF CHANGES Initial Release Updated document to reference that this outline should be used when developing RFP requirements. Updated the roles to reflect responsibilities associated with System Requirements Specification.
OSIAdmin #5358
Table of Contents
1. PURPOSE......................................................................................................................................... 1 2. SCOPE.............................................................................................................................................. 1 3. RESPONSIBILITIES......................................................................................................................... 1 4. SYSTEM REQUIREMENTS SPECIFICATION OUTLINE.................................................................2
OSIAdmin #5358
1. PURPOSE
This document should be used by the Office of Systems Integration (OSI) projects to assist in defining RFP requirements. This document provides guidance in the uniform development of the System Requirements Specification (SyRS) document, which is a structured collection of information that embodies the requirements of the system. The purpose of the system requirements specification is to communicate stakeholder requirements to the technical resources that will specify and build the system. This document was based on the following Institute of Electrical and Electronics Engineers (IEEE) Standards: IEEE Standard (STD) 1233-1998.
2. SCOPE
The SyRS is a product that is produced during the System Development Life Cycle (SDLC). The SDLC is a conceptual model used for project management that describes a series of phases involved in a system development project. The OSI has defined the following phases as part of the SDLC model: Requirements Analysis, Design, Development, Test, Implementation, and Transition to Maintenance and Operations (M&O). The SyRS is constructed during the analysis phase of the SDLC and is a deliverable of this phase. The SyRS serves as a blueprint for completing the project. It is the reference document for the project and all subsequent SDLC phase documents, such as, the detailed design specification, testing documents, and system documentation.
3. RESPONSIBILITIES
3.1 Contractor The Contractor is responsible for developing, updating, and obtaining approval for the SyRS, if it is included as a requirement in the contract. 3.2 Project Manager The Project Manager is responsible for coordinating the efforts of those involved in the SyRS development, review, and approval. 3.3 Contract Manager The Contract Manager verifies that the SyRS is developed, reviewed, and approved. 3.4 Systems Engineer The Systems Engineer may provide input in developing the SyRS. 3.5 Project Team The project team member(s) is responsible for assisting in the development and review of the SyRS.
OSIAdmin #5358
OSIAdmin #5358
4.5.4 Major System Conditions Specify major conditions and their associated capabilities. 4.5.5 Major System Constraints Describe major constraints of the system. 4.5.6 Assumptions Describe the assumptions that can affect the requirements specified in this SyRS. Assumptions are factors that are believe to be true during the life cycle of the project, that if changed may affect the outcome of the project. Dependencies are outside of the scope and control of the project and must remain true for the project to succeed. 4.5.7 Dependencies Describe the dependencies that can affect the requirements specified in this SyRS. 4.5.8 Operational Scenarios Provide descriptive operational scenarios for the system. 4.6 System Capabilities, Conditions and Constraints In the requirements subsections, specify all requirements to a level of detail sufficient to enable development of the system. Each requirement documented in the requirements sections must have a unique identifier for requirements traceability and should be ranked for importance and/or stability. 4.6.1 Business Requirements Describe all business requirements for the system. 4.6.2 Functional Requirements Provide the functional requirements necessary to comprehensively define the fundamental actions that must take place within the system to accept and process the inputs and to process and generate the outputs. 4.6.3 Physical Requirements 6.6.3.1 Construction Specify the environmental characteristics of where the system will be installed. 6.6.3.2 Durability Specify the durability characteristics of the system. 6.6.3.3 Adaptability Specify the growth, expansion, capability, and contraction characteristics of the system.
OSIAdmin #5358
6.6.3.4 Environmental Conditions Detail the environmental conditions to be encountered by the system. 4.6.4 Logical Data Requirements Describe the logical data requirements for the system. 4.6.5 Performance Requirements Describe the critical system performance requirements, such as response time or system capacity. 4.6.6 Operations Requirements 6.6.6.1 System Maintainability Describe any maintainability requirements that apply to maintaining the system in the support environment. 6.6.6.2 System Reliability Describe any reliability requirements and define the conditions under with these requirements will be met. 4.6.7 Security Requirements Define any security requirements for the system. 4.6.8 Policy and Regulations Requirements Define any policy or regulations requirements that are necessary for the system. 4.7 Reference Documents Provide any references used in the creation of the document. 4.8 Glossary Provide an alphabetized list of definitions for special terms and acronyms used in the document. 4.9 Appendices The appendices should contain material that is too detailed or large to be included in the main body of the document. Refer to each appendix in the main body of the text where the information applies.
OSIAdmin #5358