TEMPLATE

Nonfunctional Requirements Definition

<Insert Project Name>
Version: Major.Minor

This template developed by Requirements Quest® is based on IEEE (Institute of Electrical and Electronics
Engineers) 830 Standard SRS (Software Requirements Specification). For additional information, visit
http://www.ieee.org. To request an electronic copy of this template, send an email to
inquire@requirementsquest.com or visit www.RequirementsQuest.com.
<Insert Project Name> Nonfunctional Requirements Definition

Table of Contents

1. INTRODUCTION..........................................................................................................3
1.1. PURPOSE OF THIS DOCUMENT.............................................................................................................. 3
1.2. REFERENCE MATERIALS....................................................................................................................... 3
1.3. SPECIFIC TERMS AND ACRONYMS........................................................................................................ 3
1.4. ASSUMPTIONS..................................................................................................................................... 3
1.5. CONSTRAINTS...................................................................................................................................... 3
1.6. DEPENDENCIES................................................................................................................................... 3
2. NONFUNCTIONAL REQUIREMENTS........................................................................4
2.1. NONFUNCTIONAL REQUIREMENT STATEMENTS......................................................................................4
2.2. COMMON INFORMATION....................................................................................................................... 5
3. APPENDICES..............................................................................................................6
3.1. REVISION HISTORY.............................................................................................................................. 6
3.2. VALIDATION HISTORY........................................................................................................................... 6
3.3. REQUIREMENTS ISSUES....................................................................................................................... 6
3.4. ATTACHMENTS..................................................................................................................................... 6

2
<Insert Project Name> Nonfunctional Requirements Definition

1. Introduction
[Insert Relationship Map- provides a broad view of the entities impacted by the project scope.]

1.1. Purpose of this document

This document contains all nonfunctional requirements for this project.

1.2. Reference Materials

There are many other documents that together describe the complete set of requirements for this project.
Reference Document Name Brief Description Location of Definitive
Source

1.3. Specific Terms and Acronyms

Terms here are specific to understanding the content of this document.
Term or Acronym Description

1.4. Assumptions
Identify anything that adds clarification to or provides background information about the nonfunctional
requirement statement, or other related item.
ID Assumption Statement Related To
A1

1.5. Constraints
Identify anything that puts limits on implementing the nonfunctional requirements.
ID Constraint Statement Related To
C1

1.6. Dependencies
Detail any external event, condition, or system that must be in place for a requirement to be implemented.
ID Dependency Statement Related To
D1

3
<Insert Project Name> Nonfunctional Requirements Definition

2. Nonfunctional Requirements
2.1. Nonfunctional Requirement Statements
Nonfunctional requirements focus on the qualities that must be applied to design and implement a system.
These are specific standards and attributes in support of the other requirements. For detailed information
about nonfunctional requirements, including over 2,000 suggested elicitation questions, reference
The Quest for Software Requirements, by Roxanne E. Miller, www.RequirementsQuest.com.
Column Header Key:
BR = Business Rules Identifier, CI = Common Information Identifier, S = Status, P = Priority
ID Nonfunctional Requirement Statements BR CI S P
OPERATION Requirements: How well does the system perform for daily use?
Describe the user concern for using the functionality. The user perceives the system as a tool to automate tasks.

Access Security How well is the system guarded against unauthorized access?
The extent to which the system is safeguarded against deliberate and intrusive faults from internal and external sources.
N-ACS1
Accessibility How easy is the system to use by people with varying capabilities?
The extent to which the software system can be used by people with the widest range of capabilities to achieve a specified goal in a specified
context of use.
N-ACC1
Availability How dependable is the system during normal operating times?
The degree to which users can depend on the system to be up (able to function) during “normal operating times.”
N-AVL1
Confidentiality How well does the system make sensitive data available to authorized users?
The degree to which the software system protects sensitive data and allows only authorized access to the data.
N-CNF1
Efficiency How fast can it process? How many can be processed? How well does the system respond?
The extent to which the software system handles capacity, throughput, and response time.
N-EFC1
Integrity How accurate and authentic are the data?
The degree to which the data maintained by the software system are accurate, authentic, and without corruption.
N-INT1
Reliability How immune is the system to failure?
The extent to which the software system consistently performs the specified functions without failure.
N-REL1
Safety How well does the system prevent harm to people and the environment?
The degree to which a software system prevents harm to people or damage to the environment in the intended context of use.
N-SAF1
Survivability How resilient is the system from failure?
The extent to which the software system continues to function and recovers in the presence of a system failure.
N-SRV1
Usability How easy is it to learn and operate the system?
The ease with which the user is able to learn, operate, prepare inputs, and interpret outputs through interaction with a system.
N-USE1

4
<Insert Project Name> Nonfunctional Requirements Definition

ID Nonfunctional Requirement Statements BR CI S P

REVISION Requirements: How easy is it to correct errors and add functions?
Describe the user concern for changing source code or data that drive the system. The user perceives the system as programmed
language statements.

Flexibility How easy is it to modify to work in different environments?

The ease with which the software can be modified to adapt to different environments, configurations, and user expectations.
N-FLX1
Maintainability How easy is it to upkeep and repair the system?
The ease with which faults in a software system can be found and fixed.
N-MNT1
Modifiability How easy is it to change the software system, and at what cost?
The degree to which changes to a software system can be developed and deployed efficiently and cost effectively.
N-MDF1
Scalability How easy is it to expand or upgrade the system’s capabilities?
The degree in which the system is able to expand its processing capabilities upward and outward to support business growth.
N-SCL1
Verifiability How easy is it to show the system performs its functions?
The extent to which tests, analysis, and demonstrations are needed to prove that the system will function as intended.
N-VER1
TRANSITION Requirements: How easy is it to adapt to changes in the technical environment?
Describe the user concern for managing the upkeep of the software. The user perceives the system to have characteristics similar to
hardware.

Installability How easy is it to install, uninstall, and reinstall the software system?
The ease with which a software system can be installed, uninstalled, or reinstalled into a target environment.
N-INS1
Interoperability How easy is it to interface with another system?
The extent to which the software system is able to couple or facilitate the interface with other systems.
N-IOP1
Portability How easy is it to transport?
The ease with which a software system can be transferred from its current hardware or software environment to another.
N-POR1
Reusability How easy is it to convert for use in another system?
The extent to which a portion of the software system can be converted for use in another.
N-REU1

2.2. Common Information

In the Nonfunctional Requirement Statements above, specific information that is referenced multiple times
may be described once here. This “named information” may then be referenced by its name with quotes
around it in the rest of the document.
ID Named Information Related Definition or Business Usage / Definitive
Req. ID Business Elements Source
CI1
CI2
CI3

5
<Insert Project Name> Nonfunctional Requirements Definition

3. Appendices
3.1. Revision History
Change Changed Description of Change Version
Date by

3.2. Validation History

Participant Index
ID Stakeholder Name Specific Role or Area of Expertise
Supplier 1
Supplier 2
Supplier 3
Supplier 4
Receiver 1
Receiver 2
Receiver 3
Receiver 4

Outcomes: A = Accept, C = Accept with Conditions, R = Reject

Review Overall Supplier Outcome(s) Receiver Outcome(s) Identified Issues
Date Outcome S1 S2 S3 S4 R1 R2 R3 R4

3.3. Requirements Issues

ID Description Raised by Assigned to Statu
s
IS1
IS2
IS3
IS4

3.4. Attachments
Below are supplemental documents that help to illustrate and define the nonfunctional requirements.
3.4.1. Attachment