Information Technology Division(ITD)
<Project Name>
Non-Functional Requirements Specification
November 2, 2011
Version <1.0>
[Note: Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All and right-click on the document. This brings up the Update Table of Contents dialog box. Select “Update Field” and then select “Update Entire Table” and press OK.
For Headers and Footers, view the header or footer, select the field and right click on it. Do the same update process as described above.
<Project Name> / Version: <1.0>Non-Functional Requirements Specification / Date: 10/20/2018
Revision History
Date / Version / Description / Authordd/mm/yyyy / 1.0 / Original structure design / <name>
dd/mm/yyyy / x.x / <details> / <name>
Table of Contents
1.Introduction / Overview
1.1Scope
1.2Definitions, Acronyms and Abbreviations
1.3References
2.Security
2.1Application Security
2.1.1Application Security
2.1.2Security Matrix
2.2Business Continuity
2.3ISO Security Model
3.Usability
3.1Training
3.2Help Features
4.Reliability
4.1Availability
4.2Integrity
5.Performance
6.Current Technical Environment
6.1Current Software
6.2Current Hardware
7.Infrastructure Requirements
7.1Capacity Requirements
7.2Hardware Requirements
7.3Software Requirements
7.4Processing Events
8.Implementation Requirements
8.1Standards
8.2Data Conversion/Migration
8.3Other Requirements
9.System Support Requirements
10.Design Constraints
11.Purchased Components and Licensing Requirements
12.Non-User Interfaces
12.1Hardware Interfaces
12.2Software Interfaces
12.3Communications Interfaces
13.Legal, Copyright and Other Notices
14.Acceptance
- 1 -
<Project Name> / Version: <1.0>Non-Functional Requirements Specification / Date: 10/20/2018
Non-Functional Requirements Specification
1.Introduction / Overview
[The introduction of the Non-Functional Requirements Specificationshould provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references and overview of this Non-Functional Requirements Specification.
For example, the following may be included in the document as is with the project name inserted:
The purpose of this documentis to capture the <project name> system requirements that usually do not represent functional requirements or are functional but are shared by the use cases. ]
1.1Scope
[This section of the document should describe
(1) What standard requirements are included in this document, and
(2) What standard non-functional requirements are not included for this project.
Below is an example which can be included in your document as is:
The standard set of requirements for the Information Technology Division includes:
- Security requirements
- Non user interfaces
- Legal and regulatory requirements, protocols and application standards.
- Other requirements such as archiving and retention, backup and recovery, operating systems and environments, compatibility requirements, and design constraints.
- Quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements.
- Global functionality
The standard non-functional requirements not included in this project are:
- ADA Systems are not considered in the legal protocols because there is no user interfaces for this system
- Non-user interface section is not included because there are no external interfaces.]
1.2Definitions, Acronyms and Abbreviations
[A reference should be made to the glossary which will contain the definitions for this project]
1.3References
[This subsection should provide a complete list of all documents referenced elsewhere in the Non-Functional Requirements Specification. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to a hyperlink to a website, an appendix or to another document.]
Example:
- ADA Regulations Link
- Technical accessibility guidelines
- NY State Compliance Requirements
- Information Technology Division System Development Life Cycle (SDLC)document found in the ITD Toolbox.
- Rational Template for Supplementary Specification – provided by the Rational Software.
2.Security
Security is not an add-on function; rather it should be integrated in each step of the development life cycle. For detailed items designed to highlight security issues, tasks and deliverables see the ITD SDLC document Appendix B – Security Checklist.
2.1Application Security
The intent of this section of the document is to detail the requirements for authorization to use the <project name> application. This is used to build application security at the functionality level. Define the following:
2.1.1Application Security
Application Access and Decision Making Authorization.
Define the role and describe the access that it has to the Use Case (process). If the use case is defined generally (e.g. “maintain account”) this may include information about permissions to create, update, read or delete (accounts).
Describe any restrictions that may exist relative to this Actor and Use Case. Restrictions may include limiting access to data (e.g. classified as confidential), or data that is not relevant to the end user (e.g. regional data for regions other than end user).
Role / Description / Permissions / Restrictions<role1>
<role2>
Etc.
2.1.2Security Matrix
Access of groups and individuals, groups and systems to specific systems functionality.
Events v. Roles / <role 1> / <role 1> / <role 1> / <role 1> / role n>…<event 1> / x / x / x
<event 2> / x / x / x
<event 3> / x
<event 4> / x / x / x
<event 5> / x / x
<event 6> / x / x
<event 7> / x / x / x / x / x
2.2Business Continuity
Business Continuity Narrative describing the overall sensitivity of the system processes and data in terms of required availability and acceptable downtimes.
Example:
Following are the anticipated impacts of system downtime:
It is expected that system downtime…
In the event of sustained outages…
The risk is highest for requests for…
Servers are located in different physical locations…
An impact is present of external users...
2.3ISO Security Model
Communicate with the Information Security Office (ISO) through the life cycle of the project. The ISO has a model for data security classification as follows:
C – Confidentiality
I – Integrity
A - Availability
Include the ISO on the team in the concept phase, prior to the initiation of a project. When the User begins to think about a project considerations regarding CIA need to be made. The Requirements Phase is the best stage to Identify and classify risks. Consider the following:
What the data is – are there confidentiality issues?
Who will need access and how will they get it?
How “right” does the information have to be?
What will be the impact if the information is unavailable?
3.Usability
[This section should include all of those requirements that affect usability. Examples:
- Specify the required training time for a normal user and power users to become productive at particular operations.
- Specify measurable task times for typical tasks, or
- Specify ease of use requirements
- Base usability requirements of the new system on other systems that the users know and like.
- Specify requirements to conform to common usability standards ]
3.1Training
Describe the Training Requirements (if any)
3.2Help Features
Describe the Help Requirements.
Example:
Each feature of the <system> will have built-in online help for the user. Online Help shall include step by step instructions on using the System. Online Help shall also include definitions for terms and acronyms.
4.Reliability
[Requirements for reliability of the system should be specified here. Suggestions:
4.1Availability
Specify % of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations etc. Example:
The <system> System will be available 24 hours a day, 7 days a week. There will be no more than 4% down time.
4.2Integrity
Specify precision (resolution) and accuracy (by some known standard) that is required in the systems output. Example:
Precision will be determined for individual computations.
5.Performance
This section documents the performance requirements of a system by identifying the workloads, scenarios and resources related to system events. A system event is one or more use cases and/or scenarios involved in a dynamic situation involving a similar set of resources. An example of a system event is a “busy hour” during which a maximum processor load is expected. A list of system events is developed and prioritized based on expected utilization and criticality of use case scenarios.
Definitions:
Use Case / Scenario - Name or identifier for the Use Case and Scenario for the process being analyzed
Peak Utilization Timeframes and Frequency- Times when the Use Case/Scenario is accessed heavily (e.g. 8-9AM) The maximum frequency with which Use Case/Scenario is accessed (e.g. 100 per hour)
Resource- A description of how the Use Case/Scenario is accessed (e.g. online, system run)Data AccessedEntities and attributes accessed by the Use Case/Scenario
Average Utilization- Frequency with which the Use Case/Scenario is accessed on average(e.g. 100 per hour)
Criticality - Relative criticality of Use Case/Scenario as related to business needs (e.g. High, Moderate, Low)
Performance Requirements - Response or turn around time required by the business for this Use Case/Scenario.
Use Case Scenario / Peak Utilization Timeframe and Frequency / Resource / Average Utilization / Criticality / User Population5.1<Performance Requirement One>
[The requirement description.
5.2<Performance Requirement Two
[The requirement description.
6.Current Technical Environment
Identification of the Current Technical environment is a Systems Requirements Analysis activity to describe the physical requirements on the system being developed. The Current Software analysis provides information on software development tools that are available and/or required for systems development. The Current Hardware analysis provides information on hardware and networks that are available and/or required for systems development, test and implementation.
6.1Current Software
This table describes the software tools that are available or required for use in the development of the new system.
Tools / Dev/Test/Prod / Resource Specification / QuantityPresentation Layer
Web Services
Component Ware
Middleware (data access)
Reporting Tool
RDBMS
Software Configuration Management Tool
6.2Current Hardware
Resource / Resource Specification / QuantityApplication Server
Database Server
Workstations
Network
Printer
Backup Media - Data
Backup Media - Source code
7.Infrastructure Requirements
7.1Capacity Requirements
Capacity Requirements are summarized and provided to the network/technology specialist to define the physical deployment architecture for the application.
Number of Local Users / Estimated number of main office end users.Number of Remote Users / Estimated number of regional end users or other remote end users.
Estimated Number of Concurrent Users / Estimate number of concurrent application users. This can be a range but minimally should define the expected maximum.
Estimated Transaction Volumes-Average / The average number of transactions to be processed over a given period of time.
Peak Processing Period / Description of peak processing period (e.g. month end, daily 8-9AM etc.)
Estimated Transaction Volumes-Peak / The peak number of transactions to be processed over a given period of time.
Disk Space-Applications Server / Estimated disk space requirements for application libraries.
Disk Space-Application Database / Estimated disk space requirements for application databases (Development, Test, Production and Production Maintenance)
7.2Hardware Requirements
Resource / Resource Specification / QuantityApplication Server
Database Server
Workstations
Network
Printer
Backup Media - Data
Backup Media - Source code
7.3Software Requirements
This table records the software tools that will be utilized in each of the application layers.
Tools / Dev/Test/Prod / Resource Specification / QuantityPresentation Layer
Web Services
ComponentWare
Middleware (data access)
Reporting Tool
RDBMS
Software Configuration Management Tool
7.4Processing Events
Define scheduled processes and the dependencies.
8.Implementation Requirements
Specifies or constrains the coding or construction of a system; such as, required standards, data conversion / migration needs, implementation languages, policies for database integrity, resource limits, and operation environments.
8.1Standards
The Development Standards identifies or adopts standard techniques and practices related to the development of application software. Project Development Standards are adopted from ITD Department standards. References to Standards Documents and Policy Guides are included in Systems Design documentation.
Standard / Description / ReferenceAccessibility for the Disabled / Development standards used to comply with Americans with Disabilities Act (ADA) guidelines for Web Accessibility. / ADA regulations are available on .
Technical accessibility guidelines are available on World Wide Web Consortium -
The State of New York Enterprise IT Policies may be found at the following website:
Coding / Coding standards are specific to the development tool and define, naming conventions and the structure and formatting of programs in the new system. Coding standards include SQL standards, which define techniques for data access. / Reference ITD Coding standards.
JDeveloper
Oracle Developer
Web Presentation (GUI) / GUI standards establish the look and feel of the user interface and how components are assembled. This includes applications styles (e.g. dockable menus), application frameworks, (e.g., Microsoft MFC) and standardized GUI components (e.g., message boxes, menus etc.) / Reference ITD Web Development Standards.
Help System / Help System standards define the tools and overall design standards for the application help system. This includes standards for page and field level help, how help content is defined and maintained and how help interfaces with other definitional aspects of the application (i.e. data dictionary, system and user documentation). / Reference ITD Help System Standards.
Metadata / Metadata standards define the methods and naming conventions used to develop the data model. / Reference ITD Metadata Standards.
Security Standards / Security Standards identify user types and access controls that are standard across applications. / Reference Security Standards and Guidelines.
Software Configuration Management (SCM) / SCM standards define the tool(s) and methods for managing and tracking changes to application software as it evolves through the development lifecycle. / Reference ITD Software Configuration Standards.
Software Quality Assurance (SQA) / SQA standards define the processes and metrics used to ensure and measure software quality. / Reference ITD Software Quality Assurance Standards.
8.2Data Conversion/Migration
8.3Other Requirements
9.System Support Requirements
Support requirements provide information relative to the impact the application is expected to have on operational support resources and should include:
Help Desk Support
Network Support
Application Support
Database Support
Administrative Support
Security Support
Training Support
9.1<Support Requirement One>
Support TypeType of support required; Help Desk Support, Network Support, Application Support, Database Support, Security, Training or Administrative Support. Each system may require multiple Support Types.
Service Level Definition / Defines expectations related to system performance and availability and the related support needs in a way that can be measured. Support needs include requirements for help desk problem resolution turnaround, support coverage/schedule, defect resolution turnaround, systems availability, security support and other service needs as defined by the customer.
It is not expected that a “Service Level Agreement” will be developed for each application. However, an assessment of the operational support needs of the business application should be developed to determine if those needs fall within the parameters of ITD’s existing support levels.
Role / The roles expected to be performed by support individuals. Role definitions are available in the Roles and Responsibility appendix. For example: Application Support may require a Business Analyst, Developer and Tester. Database Support may include Data Architect and DBA.
Estimated HRS/WK / Estimated hours per week of support for roles defined.
10.Design Constraints
[This section should indicate any design constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components,coding standards, naming conventions, class libraries, maintenance access, maintenance utilities.]
10.1<Design Constraint One>
[The requirement description.
11.Purchased Components and Licensing Requirements
[This section describes any purchased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.]
[Defines any licensing enforcement requirements or other usage restriction requirements which are to be exhibited by the software.]
12.Non-User Interfaces
[This section defines the non-user interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, etc, so that the software can be developed and verified against the interface requirements. Specifies an external item with which a system must interact, or constrains on formats, timings, or other factors used by such an interaction]
Identifier / Name of External Interface (filename or report identifier).Source / Source of External Interface (function, system or organization)
Destination / Destination of External Interface (function, system or organization)
Type / Media of Interface (EDI, XML, tape, EFT)
Reference / Reference to supporting documentation including file descriptions and required data definitions.
12.1Hardware Interfaces
[This section defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc.]
12.2Software Interfaces
[This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application, or components being developed for subsystems outside of the scope of this SRS, but with which this software application must interact.]