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.

Google Online Preview   Download