System Requirements Document - NM DoIT
[Insert Project Name]
SYSTEM REQUIREMENTS SPECIFICATIONS TEMPLATE
EXECUTIVE SPONSOR – [INSERT NAME]
Business Owner - [Insert Name]
Project Manager – [Insert Name]
Original Plan Date: [Insert Date, Spelled Out]
Revision Date: [Insert Date, Spelled Out]
Revision: [Insert Number]
Revision History
|Revision Number |Date |Comment |
|1.0 |August 14, 2007 |Original DoIT PMO Document |
| | | |
| | | |
| | | |
Table of Contents
Revision History 2
Table of Contents 3
Introduction 5
Purpose of This Document 5
Goals of the Project 5
System Scope 5
Client, Customer and Other Stakeholders 5
Users of the Product 6
Assumptions and Other Relevant Facts 6
Functional Requirements 6
Behavioral Requirements 7
Data Requirements 7
Integration Requirements 7
User Interface Requirements 7
Screen Layout Requirements 7
Reporting Requirements 8
Non-Functional Requirements 9
Usability Requirements 9
Ease-of-use Requirements 9
Documentation Requirements 9
Safety Requirements 9
Performance Requirements 9
Availability Requirements 9
Responsiveness Requirements 9
Reliability Requirements 9
Capacity Requirements 10
Scalability Requirements 10
Disaster Recovery & Business Continuity Requirements 10
Security Requirements 10
User Security Requirements 10
Data Security Requirements 10
Legal Requirements 10
Notification Requirements 10
Privacy Requirements 10
Operational Requirements 10
Hardware Requirements 11
Software Requirements 11
Network Requirements 11
Architectural Requirements 11
Data Management Requirements 11
Production Support Requirements 12
Software Licensing Requirements 12
Operational Concepts 12
Functionality (behavioral) 12
Use Cases 12
Functional Analysis Model 12
Data Models 12
User Interface Prototypes 12
Requirement Constraints & Dependencies 13
Design Constraint 13
Project Constraint 13
Reference Material 14
Acronyms and Glossary 14
Introduction
Purpose of This Document
The System Requirements Specification is the official statement of the system requirements for customers, end-users, and software developers. It details what services the system should provide, the system properties, and the constraints on the operation and development of the system.
Note: The introduction section is largely populated from the data captured in the Business Requirements Document. Review the Business Requirements Document content for any additions and corrections and place the information in the fields below.
Give a brief description of the business problem being addressed, and the background to the project. This includes:
1. A description of the work the user is currently doing and why it is not as good as it could be.
2. A clear statement of the business opportunity
This can be copied from the project charter or agency documents used to secure funding.
Goals of the Project
Provide a short description of what the product/system needs to do, or how it will contribute to the overall goals of the project. Having a short sharp goal will make the project’s intent clear to stakeholders and will aid in achieving consensus. The goal must provide direct benefit, e.g., value in the marketplace, reduced operations cost, and/or increased value or service to customers.
System Scope
Give a brief description of scope of work for the project, which defines the boundaries of the work and how it fits in the environment.
Client, Customer and Other Stakeholders
List the following:
3. The Client – The person/organization who pays for the product development
4. The Customer – The person/organization(s) who will use the product, or who will benefit by the existence of the product.
5. Other Stakeholders – The people/organizations that have a vested interest in the product
Users of the Product
Detail all of the roles of people who will interact directly with the product. This information may be available in the Organization Impact Analysis document.
Assumptions and Other Relevant Facts
Include any assumptions that were made with regards to the analysis/decisions of the project, its systems, and its requirements. Also include any other relevant facts regarding external factors that have an affect on the system, but are not covered by the other sections.
Functional Requirements
Functional requirements describe what the system must do (Behavioral Requirements), the data manipulated by its functions (Data Requirements), and the user interaction with the system (User Interface Requirements).
To ensure that each requirement has the necessary amount of information, use the Requirements Information Collection Template to capture the required data for each requirement. This template should be used for all types of requirements, and then the data from that template placed in this specification document under the appropriate requirement type section.
Behavioral Requirements
Specify the behavioral requirements, which describe what the system must do. These requirements should be supported by Use Cases, and thoroughly describe the behavior of the system. Include requirements for how the system should behave under abnormal circumstances, e.g., missing or invalid data.
Data Requirements
Specify the detailed data requirements for the system, including inputs, internal data, and outputs. Include the sources and destinations of the data, as well as requirements regarding frequency, latency (real-time, near real-time, daily) and volume. Identify data that must be converted, replicated or shared across software components.
State the System Logical Data Requirements, Data Input files, Internal Data Files, and Data Output files; State where the System Logical Data Requirements will be stored.
Integration Requirements
Specify requirements for integration with other application systems. Identify the data items or messages coming into the system and going out and describe the purpose of each. Refer to documents that describe detailed application programming interface protocols.
User Interface Requirements
State the detailed user interface requirements. Describe the logical characteristics of each interface between the software system and the users. Define the software components for which a user interface is needed. Details of the user interface design should be documented in a separate user interface specification.
Screen Layout Requirements
Define what type of data and functionality should be included on each screen. Primary focus is on content versus screen mock-ups. This may include sample screen images, any GUI standards or system family style guides that are to be followed, screen layout constraints, standard buttons and functions (e.g., help) that will appear on every screen, keyboard shortcuts, error message display standards, and so on. If known, include requirements such as number of frames, browser-based, etc.
Reporting Requirements
Utilize the following table to provide additional definition for each reporting requirement
|Report Type |Report Name |Description |Stakeholder Audience |Frequency |
|[Examples: Financial, | |[In a couple of sentences describe| |[Example: Daily, weekly, monthly,|
|Operational, Executive, | |the information that the | |etc.] |
|etc.] | |stakeholder audience would like to| | |
| | |obtain from this report] | | |
Non-Functional Requirements
Non-functional requirements consist of all properties that system must have. They are categorized here as Usability, Performance, Security, Legal, Operational Requirements.
Usability Requirements
Ease-of-use Requirements
Document the requirements pertaining to the ease with which the user must be able to interact with the system. Examples include the accessibility of information, high-level user interface guidelines, and support for various levels of user expertise (e.g., novice vs. power user).
Documentation Requirements
Document the kinds of user documentation that will need to be produced. This should include not only printed user manuals, but also any requirements for on-line help, tutorials, and installation instructions.
Safety Requirements
Document any requirements pertaining to possible loss, damage, or harm that could result from the use of the system. Define any safeguards or actions that must be taken, as well as actions that must be prevented. Refer to any external policies or regulations that govern the system’s design or use. Define any safety certifications that must be satisfied.
Performance Requirements
Availability Requirements
Document the required availability of the system, such as hours of operation and expected uptime requirements.
Responsiveness Requirements
Document the required responsiveness of the system, such as online response times and report deadlines.
Reliability Requirements
Document the required reliability of the system, such as mean time between failures.
Capacity Requirements
Document the required capacity of the system, including CPU, memory, disk space, and network bandwidth.
Scalability Requirements
Document the requirements for increasing the capacity of the system over time.
Disaster Recovery & Business Continuity Requirements
Document the requirements for system behavior and operation in the event of a disaster; Reference Business Continuity Document.
Security Requirements
User Security Requirements
Document the user security requirements of the system, including details of the user authentication and verification procedures to be implemented.
Data Security Requirements
Document the security requirements for the system, including data transmittal and storage. Include provisions for back-up and restore and off-site storage.
Legal Requirements
Notification Requirements
Document any necessary legal disclaimers, warranties, copyright notices, patent notice, trademark or other compliance requirements for the system.
Privacy Requirements
Document requirements relating to the storage and use of personal data collected from external users.
Operational Requirements
Hardware Requirements
Specify the computing platforms on which the system will run, and the expected usage of resources such as processor capacity, disk space, and memory. Describe the logical and physical characteristics of each interface between the software and hardware components of the system. This may include the supported device types, the nature of the data and control interactions between the software and the hardware, and communication protocols to be used. Include any constraints imposed on the system by the hardware environment. The detailed analysis and the implications of these environmental constraints may be included in the System Architecture Document.
Software Requirements
Specify the connections between this system and other specific software components (name and version), including databases, operating systems, middleware, tools, libraries, and integrated commercial components. Describe the services needed and the nature of communications. Include any constraints imposed on the system by the software environment. The detailed analysis and the implications of these environmental constraints may be included in the System Architecture Document.
Network Requirements
Specify the requirements associated with any communications functions required by this system, including e-mail, web browser, network server communications protocols, electronic forms, and so on. Specify the expected bandwidth requirements. Define any pertinent message formatting. Identify any communication standards that will be used, such as FTP or HTTP. Specify requirements for data transfer rates and message synchronization.
Architectural Requirements
Specify the architectural requirements and constraints for the system, such as architecture design patterns, IT standards, and COTS applications. Requirements pertaining to the portability of the system to other environments and the reusability of system components should be captured here. Also consider maintainability requirements, specified in terms of complexity analysis metrics thresholds.
Data Management Requirements
Specify the data management requirements, including data security (e.g., encryption), data retention, data archiving and purging, and backup and recovery. Identify specific data hosting requirements, such as operational data stores, data marts and data warehouses.
Production Support Requirements
Specify requirements pertaining to the monitoring and support of the system in production. Include requirements for the behavior of the system in the event of hardware and software failures (e.g., fail over requirements), instrumentation of the code to support system management tools, audit logging, error reporting, and status reporting.
Software Licensing Requirements
Specify any licensing enforcement requirements, or other usage restriction requirements. Specify software maintenance and support provisions.
Operational Concepts
Complete the following sections as appropriate to model and/or clarify the operational concepts and scenarios that include functionality, performance, maintenance, support, and disposal.
Functionality (behavioral)
Use Cases
Capture the system behavior in Use Case format, where each Use Case represents one or more system functions, triggered by a user or another system. The function is represented by a sequence of events, which in turn return a clearly defined deliverable to the user. Provide a list of Use Cases that were the basis for extracting various functional requirements (system features) of the system that will become basis for the component design and testing.
Functional Analysis Model
Create a graphical; object-based model based on the Use Case definitions (UML is the recommended format.) Reference the UML models here.
Data Models
User Interface Prototypes
If the project team chose to utilize prototypes, include Screen layouts and other prototype detail here.
Requirement Constraints & Dependencies
Constraints and dependencies often impact and/or provide direction on how the system must ultimately be developed. Dependencies are a form of constraint in that they can influence the timing, content, risk, etc. for a project. Business Rules can also be a form of constraint and need to be comprehended and captured here.
Use the following table to detail and uniquely identify any conditions that restrict the requirements to specifying a system that fits within the constraint for the project. There are two types of constraints.
• Design Constraints
o These are pre-existing design decisions that mandate how the final system must look, or the technology that it must use.
• Project Constraints
o These are constraints that cover things like budget, schedule, deadlines, etc.
Design Constraint
|ID |Constraint |
|C.1.1 | |
|C.1.2 | |
Project Constraint
|ID |Constraint |
|C.2.1 | |
| | |
| | |
| | |
Reference Material
Use this table to consolidate all reference documents, their filenames, and their location.
|Description |Filename and Version |Location |
|Requirements Trace Document | | |
|Use Cases (Business Requirements | | |
|Document) | | |
|System Architecture Document | | |
|Etc… | | |
Acronyms and Glossary
Include definitions for any unique symbols or notations that are used in the document, which may cause confusion with the intended message, or may result in multiple interpretations of some key terms. Define all the terms necessary to properly interpret the specification document, including acronyms and abbreviations. Include definitions for terms that have multiple uses, or unique State of New Mexico uses.
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- technical requirements
- functional requirements document template
- requirements specification pace
- user and functional requirements specifications
- software requirements specification srs template
- functional requirements document frd
- non functional requirements definition template
- system requirements document nm doit
Related searches
- crm requirements document template
- system requirements document example
- system requirements document template
- technical requirements document template
- dod system requirements document example
- functional requirements document dod
- dod functional requirements document template
- systems requirements document template
- operational requirements document dod
- functional requirements document dau
- functional requirements document checklist
- requirements document template