EDS - NFR Checklist

Business Analysis Capability

Non-functional Requirements Checklist

Requirements Determination Process

Template Control: Non-functional Requirements Checklist Template Version 1.0 -- Approval Date 16 July, 2007 Saved 21 July, 2008 EDS Internal Page 1 of 17 EDS and the EDS logo are registered trademarks of Electronic Data Systems Corporation. EDS is an equal opportunity employer and values the diversity of its people. Copyright © 2007, Electronic Data Systems Corporation. All rights reserved. D:\Work\Consulting Skills\Requirements\Software Requirements\Nonfunctional Requirements\Non-functional_Requirements_Checklist.doc

NON-FUNCTIONAL REQUIREMENTS CHECKLIST Amendment History - Document Status (e.g. Draft, Final, Release #):

CR# (optional)

Document Version#

Approval Date

Modified By Section, Page(s) and Text Revised

Non-functional requirements are those project requirements that do not directly address a client business or application need. Instead, they may address:

o A property the end product must possess

o The standards by which it must be created

o The supporting structure that makes it possible

o The environment in which it must exist.

DESCRIPTION As with business requirements, non-functional requirements must be recorded, evaluated, validated, and prioritized. However, non-functional requirements are often overlooked. Though they generally are not included in discussions of business functionality, clients have expectations of service and support that must be included in the project plan. Likewise, developers, installers, and support staff depend on critical resources to perform their jobs. Failure to adequately identify and plan for non-functional requirements in a project may have a serious negative impact on cost, quality, schedule, and client satisfaction. Refer to the reference document, Writing Good Requirements, for guidelines on creating quality requirements documents. This document is intended to serve as a checklist of non-functional requirements to be considered by requirements determiners as part of their efforts to create a correct and complete requirements document. Not all of the non-functional categories, listed in the following table, will apply to all projects. Subject matter experts from outside the project team may need to be consulted when compiling the non-functional requirements. These sources may include, but are not limited to:

o Technical architects

o Chief technologists

o Network specialists

o Security specialists

o Training specialists

Business Analysis Capability Non-functional Requirements Checklist Requirements Determination Process

Saved 21 July, 2008 EDS Internal Page 2 of 18 Copyright © 2007, Electronic Data Systems Corporation. All rights reserved. D:\Work\Consulting Skills\Requirements\Software Requirements\Nonfunctional Requirements\Non-functional_Requirements_Checklist.doc

o Legal specialists

o Financial specialists

o Documentation specialists

o Data center specialists

o Operations support specialists

o Auditors

o DBA’s

CONTENT/GUIDELINES Non-functional Category

Description Example

Audit-ability These requirements address the need for the product to be auditable. They may consider or specify: • Who will perform the audits • Standards to be applied • Frequency of the audits • How non-compliance issues will be handled • Fault and failure recording and tracking

These requirements address the need to trace or log use of the system. They may consider or specify:

• Who visited a Web page • Who read or updated a database • Who read or updated a program • What operations were performed

Example 1: Record in the database row the EDSNET id of the last person to update that row. Example 2: The client is responsible for validating that authorized personnel performed all updates.

Availability These requirements define when the product is available. They may consider or specify: • System up-time • Defined maintenance window • Dependence on other systems • Restore and reactivate procedures • Alternative processes and fail-over plans • Cost of availability (cost per transaction,

including support) • Cost of unavailability (cost of impact to

client)

Example 1: Routine system maintenance is conducted every Sunday, between 1:00am and 3:00am EST. The application is not available to users during this time. Example 2: The application is available to receive electronic shipping requests every 5 minutes between 5:00am and 6:00pm EST, Monday through Friday.



Non-functional Category

Description Example

Backup and Restore

These requirements address plans and provisions for backup and restore operations. They may consider or specify: • Named items for backup operations (data,

programs) • Responsibilities for performing backup and

restore operations • Storage medium • Volume • Storage location (on and off site) • Frequency and timing of backup operations • Data retention • Hot backups • Transportation to storage facilities • Facilities • Handling • Cataloging • Security • Retrieval • Procedures to request restoration

Example 1: Production services staff performs data backups on database server #3 daily, at 1:00am EST. Example 2: Daily data backup files are packed and transported to secret location #1 by Moving Company, every Friday between 1:00pm and 3:00pm EST. Example 3: File restoration requests are submitted on Form 123 to the production services supervisor.

Capacity These requirements address the system load at any given time. They may consider or specify: • Memory • Database size • Throughput • Number of users • Number of transactions processed • Rate of growth

Example: The network will accommodate 45 simultaneous users.

Computer Resources

See “Hardware”




Description Example

Conversion These requirements address the need for the product or product components to undergo one-time or ongoing transition activities. They may consider or specify: • Ongoing file format conversion for interface

with another application • One time file format conversion for data loads • Data migration • Special data validation and conversion

software • Automated conversion tools • Periodic upgrades of hardware and software • One time transition of an application to a new

application or platform • One time transition of computer resources to a

new product line • Training in the old and new environments to

support conversion • Training in the new environment for ongoing

support • Temporary acquisition of subject matter

experts to support conversion • Phased conversion • Parallel operations for testing and training

Example 1: The application is converted from VB6 to Oracle Forms 9.0 with no change in business functionality. Example 2: All customer transmitted purchase requests are translated to input specifications defined for program ABC123.

Data Integrity These requirements address the integrity of data. They may consider or specify: • Timeliness (how current must information be) • Database replication • Process sequencing • Language translation • Accuracy (specific values, free text) • Data quality • Referential integrity • Content • Format • Robustness

Example 1: Replicated database synchronization occurs every 5 minutes. Example 2: Data attribute values are verified against the data dictionary to ensure they do indeed contain the expected values or NULL values, if applicable.

Data Retention These requirements address the need to retain data after it is no longer considered active. They may consider or specify: • Archiving procedures • Backup and restore operations • Purges • Shelf life • Storage medium • Volume

Example 2: Database log files are saved for 20 years from date of archive.

Deployment See “Installability”




Description Example

Development Environment

These requirements address special arrangements made in the development environment in support of the project. They may consider or specify: • Hardware • Software • Licenses • Responsibilities for research, purchase, and

ownership of hardware, software, and licenses • Developer training • Relocation • Facilities • Additional phone lines • Security • Server • Network • Database • Memory • Compilers • Test data source • Special testing requirements

Example 1: Each member of the project development team receives a licensed copy of MS FrontPage 2000. Example 2: A copy of the production database resides in the development environment, with capacity to store 3000 client part numbers and associated attributes. Example 3: All project developers and testers will have full read/write access to the development database.

Disaster Recovery

See “Recoverability”

Documentation These requirements address specific documentation provided as a project deliverable. They may consider or specify: • Target audience or recipient • Architecture diagrams • Technical manuals • User instructions (format and content) • On-line help facilities • Multilingual capabilities • System overview documents • Data models • Code • Client documentation standards and templates • EDS documentation standards and templates

Example 1: EDS delivers all source code produced for the project to the client on final client sign-off of the project. Example 2: EDS provides a hardcopy, user instruction manual at system implementation.

Economics These requirements address economic specifications for the project. They may consider or specify: • Minimum profit increase • Minimum cost reduction • Budgetary limits on development or operating

costs • Maximum cost per transaction • Maximum cost per user

Example 1: The new load procedure reduces processing time by 5% over the 2001 average processing time. Example 2: The ongoing system support costs will not exceed $50 per user per month.




Description Example

Efficiency These requirements address product efficiency in the sense that there are no wasted or duplicated effort and minimal planned delays. They may consider or specify: • Anticipated user error rate • Speed and accuracy of processing • Process flow • Duplicated effort or tasks with other processes

or systems • Interaction with non-automated processes and

activities • Business process re-engineering

Example 1: Completion of batch job ABC triggers the start of batch jobs DEF and GHI.

Error Handling See “Robustness” Exception Handling

See “Robustness”

Expandability See “Scalability” Extensibility See “Scalability” Fail-over See “Recoverability” Flexibility See “Scalability” and “Usability” Hardware These requirements address specific hardware

considerations for a project. They may consider or specify: • Named vendors or products • Existing vendor contracts • Existing purchase agreements • Existing hardware • Hardware / Software compatibility • Infrastructure and installation compatibility • Size parameters • Client technical direction

Example 1: Only HP servers are installed. Example 2: All desktop computers are IBM PC compatible.

Information See “Data Integrity” Infrastructure These requirements address the infrastructure

necessary for the development, operation, and support of the product. They may consider or specify: • Accessibility to facilities, equipment, or system • Utilities (electrical, water, climate control) • Electrical backup (generators) • Phone lines • Network services • Performance requirements • Support requirements • Physical environment • Existing infrastructure

Example 1: The client is responsible for ensuring all utilities and phone lines are installed in the new warehouse by August 1. Example 2: The client provides a secured room for network hardware.




Description Example

Installability These requirements address the ease with which the product is installed in the user’s environment. They may consider or specify: • Responsibilities • Timing of installations • Locations • Number of installations • Dependencies in the installation schedule • Required infrastructure • Hardware / software version compatibilities • Installation guides (format, content,

multilingual requirements) • Installation procedures (automated or manual) • Installation package (instructions, CD,

downloads) • Procedures for installing patches and upgrades • Product release or upgrade schedule

Example 1: Telephone connections are installed and maintained by the local telephone service provider. Example 2: The firewall is installed and tested by network services before the application is delivered to the end users. Example 3: The client software installation instructions are written for the Windows 98 and Windows 2000 environments. Example 4: Client software installation instructions are available in English, German and Spanish.

International Use These requirements address special issues associated with the developing, implementing, and supporting an application or system that is used internationally. They may consider or specify: • Customs regulations • Security • Transportation • Language translation • Special character fonts • Communication • Fees (taxes, duties, tariffs) • Local contractors • Responsibilities • Licensing • Encryption • Work permits • Passports and visas • Export compliance

Example 1: All licensed software is purchased in the country where it will be used. Example 2: All installers have passports and visas to Brazil. Example 3: All program specifications will be written in English.




Description Example

Interoperability These requirements address the need for the product to interface with other applications or systems without interfering with the operation of those other applications or systems. They may consider or specify: • Named applications or systems with which to

interface • Messaging format, medium, and content • Compatibility with products from different

vendors • Conversion requirements for hardware,

applications, or data • Middleware architecture • Messaging and transmission protocols • Frequency • Multiple time zones • Process timing and sequencing

Example 1: Payments are uploaded to mainframe job ABC123 at 3:00am each Friday. Example 2: MQSeries is used to transmit invoices to the customer’s accounting system.

Learnability See “Usability” Legal These requirements address legal constraints that

are not covered in the functional requirements. They may consider or specify: • Laws • Government regulations and standards • Labor contracts • Supplier contracts • Intellectual property protection • Copyrights • Patents • Export compliance

Example 1: The application complies with U.S. Export Compliance laws. Example 2: Local building inspectors inspect all wiring installations. Example 3: The client assumes full ownership of source code created as part of the project.




Description Example

Maintainability These requirements address the ease with which the product accepts repairs or adapts to new functionality. These requirements address the process by which problems are reported and resolved. They may consider or specify: • Defined maintenance window • Maintenance across time zones • Procedure for emergency fixes • Meantime to repair • Support logistics (on-site, remote help desk) • 3rd party service contracts • Process for problem reporting and escalation • Procedure for logging and tracking defects • Root cause analysis of defects • Product release or upgrade schedule • Change request process • Support responsibilities • Client business direction • Client technical direction • Standards that ensure the product is

modifiable within budgeted time and resources

• Procedures to change run-time control or schedule parameters

• Routine diagnostic checks

Example 1: All hardware problems are reported to and repaired by company ABC. Example 2: The client-support telephone line is operational 24 hours a day, 7 days a week. Example 3: Anti-virus software is upgraded automatically on every PC on the network. Example 4: ABC Solution Centre coding standards are used for all in-house developed software.

Model Office Environment

These requirements address special considerations for the model office environment in support of the project. They may consider or specify: • Database • Memory • Data • Server • Network • Hardware • Software • Licenses • Responsibilities for research, purchase, and

ownership of hardware, software, and licenses • Software version compatibility • Security • Special testing requirements

Example 1: Software and hardware in the model office environment duplicates the production environment. Example 2: A copy of the production database resides in the model office environment. Example 3: EDS purchases and owns all software licenses for software used in the model office environment.




Description Example

Operation Environment

These requirements address special considerations for the operation and ongoing support of the delivered product. They may consider or specify: • Number of users • Database size • Memory • System availability • Event/job/process scheduling • System dependencies • Support and change request procedures • Problem escalation procedures • Roles and responsibilities • Hardware • Software • Licenses • Responsibilities for research, purchase, and

ownership of hardware, software, and licenses • Support contracts (hardware, software) • Documentation • Monitoring procedures • Alarm or action triggers • Response to triggers • Training and certifications • Location • Security • Procedures to change runtime control or

schedule parameters

Example 1: BMC Patrol is used to monitor the production servers. Example 2: An alert is triggered when the CPU utilization of the application server or database server exceed 85% utilization. Example 3: Critical batch cycles are monitored to completion. Example 4: In the event of the unavailability of the Web server, application server or monitored Web pages, an alert is provided to the production support staff. Example 5: The following environment is required to support the system Web pages: • Windows 95, Windows 98, Windows

NT, Windows 2000, Windows XP • Internet Explorer 5.x or above • Netscape 6.x or above • Optimized for 800x600 resolution

Packaging and Distribution

See “Installability”




Description Example

Performance These requirements address system performance. They may consider or specify: • Data throughput • Response time for transactions (real,

perceived, expected) • System capacity • Speed and accuracy of processing • Network latency (local, national, and

international usage) • Network routing options • Line speed • Load distribution based on activities, events,

dates, transactions, or users • Load distribution over time (hourly, daily,

weekly, monthly, or yearly cycles) • Impact of geographic diversity • Average • Spikes • Peaks • Data volume • Server load • Multiple applications running simultaneously

on shared components of the system (web server, application server, db server)

• Client business direction (including mergers, acquisitions, and expansions)

• Client technical direction • Historic metrics • Complete system operation (security, servers,

databases, and network)

Example 1: The maximum response time during the peak processing period of 10:00am to 3:00pm EST is 3 seconds. Example 2: The network services staff monitors the network load for 2 weeks after implementation. Example 3: In China and Brazil, there is a 5 second delay due to network latency.

Physical Environment

These requirements address the physical environment in which the product must function. They may consider or specify: • Location (indoors/outdoors,

office/factory/warehouse) • Number of locations • Diversity of locations • Temperature and climate constraints • Dimension constraints • Weight constraints • Stability/mobility • Safety • Durability

Example 1: The user interface workstation is located outside on loading dock A4. Example 3: All network servers are installed in room B-16, which is 5x5x9.




Description Example

Portability These requirements address the ease with which the product is implemented on or migrated to other platforms or operating systems. They may consider or specify: • Named platforms on which the product must

function • Platform-dependent languages or utilities • Ability to migrate to other platforms • N-tier architecture • Client technical direction • Client business direction • Existing client platforms

Example 1: The application runs on the following software platforms: • Operating System: Sun Solaris or HP

UX • Web Server: iPlanet • Application Server: BEA WebLogic

Server • Middleware: JDBC or MQSeries • Database: Oracle 8.0

Pre-Production Environment

See “Development Environment” and “Model Office Environment”

Privacy These requirements address data sensitivity and confidentiality. They may consider or specify: • Degree of sensitivity (personal) • Degree of confidentiality (EDS Private, EDS

Internal Use Only) • Web site privacy statement • EDS privacy policy • Client privacy policy • Ownership • Distribution • Security • Encryption

Example 1: Memos address to XYZ project team are marked “EDS Private”. Example 2: The EDS Policy team reviews the application Web site privacy statement.

Procedures These requirements address the processes, methods, procedures, or standards that will be followed in the development and support of the product. They may consider or specify: • Client policies • EDS corporate or local methods and processes • Industry standards • Certification to client or EDS standards • Named tools • Templates • Coding standards • Testing standards • Documentation standards

Example 1: The application is developed in accordance with EDS GSMS 2.0 processes. Example 2: The system is certified acceptable for implementation on GM-Online. Example 3: The application is modeled using Rational Rose

Processes See “Procedures” Production Environment

See “Operation Environment”




Description Example

Recoverability These requirements address the ability to recover from unexpected interruptions, including: • Power failures • Product failures • Lost data • Sabotage • Acts of nature • Acts of war, terrorism, or vandalism They may consider or specify: • Acceptable response time to recover • Mission criticality of products • Responsibilities • Organizational practices and standards • Disaster recovery drills • System backup and restore procedures • Data and system level recovery • Alternative practices and fail-over plans • Back-out procedures for a mid-transaction

crash • Penalties for failure to recover in acceptable

time

Example 1: All application components are restored and functioning within 48 hours. Example 2: Emergency lighting will activate automatically in the event of an electrical power failure.

Redundancy These requirements address the ability to replace a failed component with another component, that is, the degree of availability, or fault-tolerance, of the system or infrastructure. They may consider or specify: • Duplicate components • Automatic fail-over • Transaction level integrity • Replicated database

Example 1: A second application server is installed for automatic fail-over operations. Example 2: The system platform has the following redundant components:

• Routers • Firewalls • Content switches

Reliability These requirements address the acceptable defect rate or failure rate of the delivered product. They may consider or specify: • Degree to which the product performs to

expectations • Anticipated frequency or timing of failures • Expected cause of failures • Acceptable recovery time (downtime) • Mechanism for recording and tracking faults

and failures

Example 1: No more than 2 severity level 1 defects are reported in a calendar month. Example 2: The application runs with no system outages 99.5% between 7:00am and 5:00pm EST.

Reproducibility These requirements address the ability of the product to be re-created or replicated. They may consider or specify: • Actions to make illegal reproduction difficult • Procedures to reproduce a product for

replacement • Procedures for installation at additional user

sites

Example 1: The system build disk is protected as read-only. Example 2: Application executable files are downloaded from the project Web site.




Description Example

Resource Management

These requirements address responsibilities for acquisition or monitoring of personnel and equipment for the development, operation, and support of the product. They may consider or specify: • Lead time on equipment orders and installation • Training requirements • Specification of special skills • Ordering, installation, and maintenance, of

equipment • Budget constraints • Supplier contracts

Example 1: An experienced MQSeries developer is assigned to the project. Example 2: All hardware is delivered within 6 weeks of ordering.

Responsibilities These requirements address the need to associate people to the tasks for which they are responsible. They may consider or specify the task to be performed with these responsible parties: • Individual persons • Roles • Teams • Groups • Job functions • Organizations • Clients • Government agencies • Suppliers • Sub-contractors

Example 1: The client purchases and owns all software licenses for end users. Example 2: Company ABC is contracted for all hardware installations and hardware support.

Reusability These requirements address the ease with which the product or a product component is reused, or converted for use, in the same project or another project.

Example 1: The application uses the insurance claims validation framework, version 2.5. Example 2: All classes defined for the application become part of the enterprise class library.

Robustness

These requirements address how the product will respond to • Data exceptions • System failures • Hardware failures

They may consider or specify:

• Alarms and triggers • System response • Levels of severity • Organization policies and processes for such

events • Fault and failure recording and tracking

Example 1: The fail-over procedures require the system to automatically switch operation to server B when server A goes offline. Example 2: All system failures will be logged in the SIM tool and tracked until resolved. Example 3: Data validation error messages are explained in detail in the user help facility




Description Example

Scalability

These requirements address the ability of the product to adapt to new technologies and to changes in post implementation metrics. They may consider or specify: • Ability of the product to accommodate

product upgrades and new functionality (product releases)

• Change in throughput • Change in the number of users • Change in the number of transactions

processed • Change in level of support • Change in memory requirements • Horizontal scalability (adding similar

components) • Vertical scalability (adding capacity to

existing components) • Client business direction (including mergers,

acquisitions, expansions, and divestitures) • Client technical direction

Example 1: The number of users on the network increases 3% every 6 months to a maximum of 500 users. Example 2: New product releases are scheduled for every 3 months for 24 months. Example 3: The database grows by 2% per year




Description Example

Security These requirements address data security in terms of access restrictions placed on users and other systems. They may consider or specify: • Privacy • Industry standards • Data, screen, or application level controls • Data transmission protocols • Encryption • Remote access • Multi-system access • Password control (including constraints for

password content, re-use, and frequency of change)

• Export compliance

These requirements address software security from unauthorized access and modification to programs. They may consider or specify: • Client processes or methods • EDS processes or methods • Project change control procedures • Coding standards These requirements address physical security issues. They may consider or specify: • Access to buildings, rooms or equipment • Who authorizes access • Types of locks • Presence of security personnel These requirements address how authorization is assigned. They may consider or specify: • Who assigns authorizations • Who designates alternate authorized users • How access is assigned (named individuals,

group ids, roles, job function) • Procedure of obtaining temporary access • Procedures for changing passwords

Example 1: Only the team technical leader has program check-out/check-in authority. Example 2: Magnetic key cards to room A12 are issued to all project team developers. Example 3: All project team developers are granted read-only access to all programs in system ABC. Example 4: The client’s sales manager signs the system access requests for all sales personnel.

Serviceability See “Maintainability” Software These requirements address specific software

considerations for a project. They may consider or specify: • Named vendors or products • Existing vendor contracts • Existing purchase agreements • Existing software • Hardware / software compatibility • Software version compatibility • Patches • Licenses • Client business direction • Client technical direction

Example 1: The client will purchase and own all 3rd party software licenses. Example 2: MS Office 2000 will be installed on client workstations built after January 1, 2001.




Description Example

Standards See “Procedures” Supplier Contracts

These requirements reflect any standing contracts with suppliers held by either EDS or the client, which offer exclusive rights to opportunities associated with the project. They may consider or specify: • Labor agreements • Client owned subsidiaries • Staff augmentation • Purchase agreements • Support agreements • Product licenses

Example: Data modeling software will be purchased through the EDS agreement with Rational.

Support Environment

See “Operation Environment”

Supportability See “Maintainability” System Interface See “Interoperability” Training These requirements address commitments for

training to be delivered to the client or end user as a result of the project. These requirements address training to be provided to the project team in support of project activities. They may consider or specify: • Training provider • Types of training (end user, technical, vendor) • Cost • Budget allowance • Financial arrangements • Facilities • Location • Timing • Forum • Materials • Frequency • Duration • Preparation • Pre-requisites • Participants • Security • Training environment for the system (database,

server, network, application, data) • Ongoing support for training materials, plans,

and the training environment

EXAMPLE 1: All project developers will attend the 1-day MQSeries training workshop prior to joining the team. Example 2: The application deployment team provides 1 session of an end user workshop, at the client site, for a maximum of 10 users, during the week prior to system implementation.




Description Example

Usability These requirements address the ease with which a person uses the product. They may consider or specify: • Productivity level of the end user (anticipated

error rate) • User’s experience level (novice or highly

trained) • Diversity in user skills • Minimum / maximum level of training or

support required • Frequency of product use • Compatibility or consistency with other client

products • Aesthetics (volume, brightness, color

schemes) • Type of user interaction (real-time, one-way,

visual, audible) • System response to errors and invalid data

entry • Assistance (on-line help, remote help,

problem escalation) • Degree of user interaction (close monitoring,

periodic inspection) • Multilingual capabilities (for displays,

manuals, on-line help, fonts, translation) • Navigation • Instructions (format, content) • Physical limitations of the user • Interoperability with existing workflows and

user processes

Example 1: The user interface screen uses the attribute navigation sequence defined for the ABC application. Example 2: The monitor and keyboard are on a work surface that supports operation by persons while standing, who are less than 5 feet tall.

User Interface See “Usability” Vendor Contracts

See “Supplier Contracts”

REFERENCES Not applicable.

BIBLIOGRAPHY Not applicable.

Documents

EDS - NFR Checklist