Non-Functional Requirements Checklist

Business Analysis Non-functional Requirements Requirements Determination
Capability Checklist Process
NON-FUNCTIONAL REQUIREMENTS CHECKLIST

Amendment History - Document Status (e.g. Draft, Final, Release #):
CR# Document Approval Modified By Section, Page(s) and Text Revised

(optional) Version# Date
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
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
Business Analysis Capability Non-functional Requirements Checklist Requirements Determination Process
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 Description Example
Category
Audit-ability These requirements address the need for the Example 1:
product to be auditable. They may consider or Record in the database row the EDSNET
specify: id of the last person to update that row.
• Who will perform the audits
• Standards to be applied Example 2:
• Frequency of the audits The client is responsible for validating that
• How non-compliance issues will be handled authorized personnel performed all
• Fault and failure recording and tracking updates.
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
Availability These requirements define when the product is Example 1:
available. They may consider or specify: Routine system maintenance is conducted
• System up-time every Sunday, between 1:00am and
• Defined maintenance window 3:00am EST. The application is not
• Dependence on other systems available to users during this time.
• Restore and reactivate procedures
• Alternative processes and fail-over plans Example 2:
• Cost of availability (cost per transaction, The application is available to receive
including support) electronic shipping requests every 5
• Cost of unavailability (cost of impact to minutes between 5:00am and 6:00pm EST,
Monday through Friday.
client)


Category
Backup and These requirements address plans and provisions Example 1:
Restore for backup and restore operations. They may Production services staff performs data
consider or specify: backups on database server #3 daily, at
• Named items for backup operations (data, 1:00am EST.
programs)
• Responsibilities for performing backup and Example 2:
restore operations Daily data backup files are packed and
• Storage medium transported to secret location #1 by
• Volume Moving Company, every Friday between
• Storage location (on and off site) 1:00pm and 3:00pm EST.
• Frequency and timing of backup operations
• Data retention Example 3:
File restoration requests are submitted on
• Hot backups
Form 123 to the production services
• Transportation to storage facilities
supervisor.
• Facilities
• Handling
• Cataloging
• Security
• Retrieval
• Procedures to request restoration
Capacity These requirements address the system load at any Example:
given time. They may consider or specify: The network will accommodate 45
• Memory simultaneous users.
• Database size
• Throughput
• Number of users
• Number of transactions processed
• Rate of growth
Computer See “Hardware”
Resources


Category
Conversion These requirements address the need for the Example 1:
product or product components to undergo one- The application is converted from VB6 to
time or ongoing transition activities. They may Oracle Forms 9.0 with no change in
consider or specify: business functionality.
• Ongoing file format conversion for interface
with another application Example 2:
• One time file format conversion for data loads All customer transmitted purchase requests
• Data migration are translated to input specifications
• Special data validation and conversion defined for program ABC123.
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
Data Integrity These requirements address the integrity of data. Example 1:
They may consider or specify: Replicated database synchronization
• Timeliness (how current must information be) occurs every 5 minutes.
• Database replication
• Process sequencing Example 2:
• Language translation Data attribute values are verified against
• Accuracy (specific values, free text) the data dictionary to ensure they do
• Data quality indeed contain the expected values or
NULL values, if applicable.
• Referential integrity
• Content
• Format
• Robustness
Data Retention These requirements address the need to retain data Example 2:
after it is no longer considered active. They may Database log files are saved for 20 years
consider or specify: from date of archive.
• Archiving procedures
• Backup and restore operations
• Purges
• Shelf life
• Storage medium
• Volume
Deployment See “Installability”


Category
Development These requirements address special arrangements Example 1:
Environment made in the development environment in support of Each member of the project development
the project. They may consider or specify: team receives a licensed copy of MS
• Hardware FrontPage 2000.
• Software
• Licenses Example 2:
• Responsibilities for research, purchase, and A copy of the production database resides
ownership of hardware, software, and licenses in the development environment, with
• Developer training capacity to store 3000 client part numbers
• Relocation and associated attributes.
• Facilities
Example 3:
• Additional phone lines
All project developers and testers will have
• Security
full read/write access to the development
• Server database.
• Network
• Database
• Memory
• Compilers
• Test data source
• Special testing requirements
Disaster See “Recoverability”
Recovery
Documentation These requirements address specific documentation Example 1:
provided as a project deliverable. EDS delivers all source code produced for
They may consider or specify: the project to the client on final client sign-
• Target audience or recipient off of the project.
• Architecture diagrams
• Technical manuals Example 2:
• User instructions (format and content) EDS provides a hardcopy, user instruction
• On-line help facilities manual at system implementation.
• Multilingual capabilities
• System overview documents
• Data models
• Code
• Client documentation standards and templates
• EDS documentation standards and templates
Economics These requirements address economic Example 1:
specifications for the project. They may consider The new load procedure reduces
or specify: processing time by 5% over the 2001
• Minimum profit increase average processing time.
• Minimum cost reduction
• Budgetary limits on development or operating Example 2:
costs The ongoing system support costs will not
• Maximum cost per transaction exceed $50 per user per month.
• Maximum cost per user


Category
Efficiency These requirements address product efficiency in Example 1:
the sense that there are no wasted or duplicated Completion of batch job ABC triggers the
effort and minimal planned delays. They may start of batch jobs DEF and GHI.
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
Error Handling See “Robustness”
Exception See “Robustness”
Handling
Expandability See “Scalability”
Extensibility See “Scalability”
Fail-over See “Recoverability”
Flexibility See “Scalability” and “Usability”
Hardware These requirements address specific hardware Example 1:
considerations for a project. They may consider or Only HP servers are installed.
specify:
• Named vendors or products Example 2:
• Existing vendor contracts All desktop computers are IBM PC
• Existing purchase agreements compatible.
• Existing hardware
• Hardware / Software compatibility
• Infrastructure and installation compatibility
• Size parameters
• Client technical direction
Information See “Data Integrity”
Infrastructure These requirements address the infrastructure Example 1:
necessary for the development, operation, and The client is responsible for ensuring all
support of the product. They may consider or utilities and phone lines are installed in the
specify: new warehouse by August 1.
• Accessibility to facilities, equipment, or system
• Utilities (electrical, water, climate control) Example 2:
• Electrical backup (generators) The client provides a secured room for
• Phone lines network hardware.
• Network services
• Performance requirements
• Support requirements
• Physical environment
• Existing infrastructure


Category
Installability These requirements address the ease with which the Example 1:
product is installed in the user’s environment. They Telephone connections are installed and
may consider or specify: maintained by the local telephone service
• Responsibilities provider.
• Timing of installations
• Locations Example 2:
• Number of installations The firewall is installed and tested by
• Dependencies in the installation schedule network services before the application is
• Required infrastructure delivered to the end users.
• Hardware / software version compatibilities
Example 3:
• Installation guides (format, content,
The client software installation instructions
multilingual requirements)
are written for the Windows 98 and
• Installation procedures (automated or manual)
Windows 2000 environments.
• Installation package (instructions, CD,
downloads) Example 4:
• Procedures for installing patches and upgrades Client software installation instructions are
• Product release or upgrade schedule available in English, German and Spanish.
International Use These requirements address special issues Example 1:
associated with the developing, implementing, and All licensed software is purchased in the
supporting an application or system that is used country where it will be used.
internationally. They may consider or specify:
• Customs regulations Example 2:
• Security All installers have passports and visas to
• Transportation Brazil.
• Language translation
• Special character fonts Example 3:
• Communication All program specifications will be written
in English.
• Fees (taxes, duties, tariffs)
• Local contractors
• Responsibilities
• Licensing
• Encryption
• Work permits
• Passports and visas
• Export compliance


Category
Interoperability These requirements address the need for the Example 1:
product to interface with other applications or Payments are uploaded to mainframe job
systems without interfering with the operation of ABC123 at 3:00am each Friday.
those other applications or systems. They may
consider or specify: Example 2:
• Named applications or systems with which to MQSeries is used to transmit invoices to
interface the customer’s accounting system.
• 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
Learnability See “Usability”
Legal These requirements address legal constraints that Example 1:
are not covered in the functional requirements. The application complies with U.S. Export
They may consider or specify: Compliance laws.
• Laws
• Government regulations and standards Example 2:
• Labor contracts Local building inspectors inspect all wiring
• Supplier contracts installations.
• Intellectual property protection
• Copyrights Example 3:
• Patents The client assumes full ownership of
source code created as part of the project.


Category
Maintainability These requirements address the ease with which the Example 1:
product accepts repairs or adapts to new All hardware problems are reported to and
functionality. repaired by company ABC.
These requirements address the process by which Example 2:

problems are reported and resolved. The client-support telephone line is
operational 24 hours a day, 7 days a week.
They may consider or specify:
• Defined maintenance window Example 3:
• Maintenance across time zones Anti-virus software is upgraded
• Procedure for emergency fixes automatically on every PC on the network.
• Meantime to repair
• Support logistics (on-site, remote help desk) Example 4:
• 3rd party service contracts ABC Solution Centre coding standards are
• Process for problem reporting and escalation used for all in-house developed software.
• Procedure for logging and tracking defects
• Root cause analysis of defects
• Product release or upgrade schedule
• Change request process
• Support responsibilities
• Client business 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
Model Office These requirements address special considerations Example 1:
Environment for the model office environment in support of the Software and hardware in the model office
project. They may consider or specify: environment duplicates the production
• Database environment.
• Memory
• Data Example 2:
• Server A copy of the production database resides
• Network in the model office environment.
• Hardware
• Software Example 3:
EDS purchases and owns all software
• Licenses
licenses for software used in the model
• Responsibilities for research, purchase, and
office environment.
ownership of hardware, software, and licenses
• Software version compatibility
• Security
• Special testing requirements


Category
Operation These requirements address special considerations Example 1:
Environment for the operation and ongoing support of the BMC Patrol is used to monitor the
delivered product. They may consider or specify: production servers.
• Number of users
• Database size Example 2:
• Memory An alert is triggered when the CPU
• System availability utilization of the application server or
• Event/job/process scheduling database server exceed 85% utilization.
• System dependencies
• Support and change request procedures Example 3:
Critical batch cycles are monitored to
• Problem escalation procedures
completion.
• Roles and responsibilities
• Hardware Example 4:
• Software In the event of the unavailability of the
• Licenses Web server, application server or
• Responsibilities for research, purchase, and monitored Web pages, an alert is provided
ownership of hardware, software, and licenses to the production support staff.
• Support contracts (hardware, software)
• Documentation Example 5:
• Monitoring procedures The following environment is required to
• Alarm or action triggers support the system Web pages:
• Response to triggers • Windows 95, Windows 98, Windows
• Training and certifications NT, Windows 2000, Windows XP
• Location • Internet Explorer 5.x or above
• Security • Netscape 6.x or above
• Procedures to change runtime control or • Optimized for 800x600 resolution
schedule parameters
Packaging and See “Installability”
Distribution


Category
Performance These requirements address system performance. Example 1:
They may consider or specify: The maximum response time during the
• Data throughput peak processing period of 10:00am to
• Response time for transactions (real, 3:00pm EST is 3 seconds.
perceived, expected)
• System capacity Example 2:
• Speed and accuracy of processing The network services staff monitors the
• Network latency (local, national, and network load for 2 weeks after
international usage) implementation.
• Network routing options
• Line speed Example 3:
In China and Brazil, there is a 5 second
• Load distribution based on activities, events,
delay due to network latency.
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)
• Historic metrics
• Complete system operation (security, servers,
databases, and network)
Physical These requirements address the physical Example 1:
Environment environment in which the product must function. The user interface workstation is located
They may consider or specify: outside on loading dock A4.
• Location (indoors/outdoors,
office/factory/warehouse) Example 3:
• Number of locations All network servers are installed in room
• Diversity of locations B-16, which is 5x5x9.
• Temperature and climate constraints
• Dimension constraints
• Weight constraints
• Stability/mobility
• Safety
• Durability


Category
Portability These requirements address the ease with which the Example 1:
product is implemented on or migrated to other The application runs on the following
platforms or operating systems. They may consider software platforms:
or specify: • Operating System: Sun Solaris or HP
• Named platforms on which the product must UX
function • Web Server: iPlanet
• Platform-dependent languages or utilities • Application Server: BEA WebLogic
• Ability to migrate to other platforms Server
• N-tier architecture • Middleware: JDBC or MQSeries
• Client technical direction • Database: Oracle 8.0
• Existing client platforms
Pre-Production See “Development Environment” and “Model
Environment Office Environment”
Privacy These requirements address data sensitivity and Example 1:
confidentiality. They may consider or specify: Memos address to XYZ project team are
• Degree of sensitivity (personal) marked “EDS Private”.
• Degree of confidentiality (EDS Private, EDS
Internal Use Only) Example 2:
• Web site privacy statement The EDS Policy team reviews the
• EDS privacy policy application Web site privacy statement.
• Client privacy policy
• Ownership
• Distribution
• Security
• Encryption
Procedures These requirements address the processes, methods, Example 1:
procedures, or standards that will be followed in the The application is developed in accordance
development and support of the product. They may with EDS GSMS 2.0 processes.
consider or specify:
• Client policies Example 2:
• EDS corporate or local methods and processes The system is certified acceptable for
• Industry standards implementation on GM-Online.
• Certification to client or EDS standards
• Named tools Example 3:
• Templates The application is modeled using Rational
Rose
• Coding standards
• Testing standards
• Documentation standards
Processes See “Procedures”
Production See “Operation Environment”
Environment


Category
Recoverability These requirements address the ability to recover Example 1:
from unexpected interruptions, including: All application components are restored
• Power failures and functioning within 48 hours.
• Product failures
• Lost data Example 2:
• Sabotage Emergency lighting will activate
• Acts of nature automatically in the event of an electrical
• Acts of war, terrorism, or vandalism power failure.

• 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
Redundancy These requirements address the ability to replace a Example 1:
failed component with another component, that is, A second application server is installed for
the degree of availability, or fault-tolerance, of the automatic fail-over operations.
system or infrastructure. They may consider or
specify: Example 2:
• Duplicate components The system platform has the following
• Automatic fail-over redundant components:
• Transaction level integrity • Routers
• Replicated database • Firewalls
• Content switches
Reliability These requirements address the acceptable defect Example 1:
rate or failure rate of the delivered product. They No more than 2 severity level 1 defects are
may consider or specify: reported in a calendar month.
• Degree to which the product performs to
expectations Example 2:
• Anticipated frequency or timing of failures The application runs with no system
• Expected cause of failures outages 99.5% between 7:00am and
• Acceptable recovery time (downtime) 5:00pm EST.
• Mechanism for recording and tracking faults
and failures
Reproducibility These requirements address the ability of the Example 1:
product to be re-created or replicated. They may The system build disk is protected as read-
consider or specify: only.
• Actions to make illegal reproduction difficult
• Procedures to reproduce a product for Example 2:
replacement Application executable files are
• Procedures for installation at additional user downloaded from the project Web site.
sites


Category
Resource These requirements address responsibilities for Example 1:
Management acquisition or monitoring of personnel and An experienced MQSeries developer is
equipment for the development, operation, and assigned to the project.
support of the product. They may consider or
specify: Example 2:
• Lead time on equipment orders and installation All hardware is delivered within 6 weeks
• Training requirements of ordering.
• Specification of special skills
• Ordering, installation, and maintenance, of
equipment
• Budget constraints
• Supplier contracts
Responsibilities These requirements address the need to associate Example 1:
people to the tasks for which they are responsible. The client purchases and owns all software
They may consider or specify the task to be licenses for end users.
performed with these responsible parties:
• Individual persons Example 2:
• Roles Company ABC is contracted for all
• Teams hardware installations and hardware
• Groups support.
• Job functions
• Organizations
• Clients
• Government agencies
• Suppliers
• Sub-contractors
Reusability These requirements address the ease with which the Example 1:
product or a product component is reused, or The application uses the insurance claims
converted for use, in the same project or another validation framework, version 2.5.
project.
Example 2:
All classes defined for the application
become part of the enterprise class library.
Robustness These requirements address how the product will Example 1:
respond to The fail-over procedures require the
• Data exceptions system to automatically switch operation to
• System failures server B when server A goes offline.
• Hardware failures
Example 2:
All system failures will be logged in the
SIM tool and tracked until resolved.
• Alarms and triggers Example 3:
• System response Data validation error messages are
explained in detail in the user help facility
• Levels of severity
• Organization policies and processes for such
events
• Fault and failure recording and tracking


Category
Scalability These requirements address the ability of the Example 1:
product to adapt to new technologies and to The number of users on the network
changes in post implementation metrics. They may increases 3% every 6 months to a
consider or specify: maximum of 500 users.
• Ability of the product to accommodate
product upgrades and new functionality Example 2:
(product releases) New product releases are scheduled for
• Change in throughput every 3 months for 24 months.
• Change in the number of users
• Change in the number of transactions Example 3:
processed The database grows by 2% per year
• 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)


Category
Security These requirements address data security in terms Example 1:
of access restrictions placed on users and other Only the team technical leader has
systems. They may consider or specify: program check-out/check-in authority.
• Privacy
• Industry standards Example 2:
• Data, screen, or application level controls Magnetic key cards to room A12 are issued
• Data transmission protocols to all project team developers.
• Encryption
• Remote access Example 3:
All project team developers are granted
• Multi-system access
read-only access to all programs in system
• Password control (including constraints for
ABC.
password content, re-use, and frequency of
change)
Example 4:
The client’s sales manager signs the
system access requests for all sales
These requirements address software security from
personnel.
unauthorized access and modification to programs.
• 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
Serviceability See “Maintainability”
Software These requirements address specific software Example 1:
considerations for a project. They may consider or The client will purchase and own all 3rd
specify: party software licenses.
• Named vendors or products
• Existing vendor contracts Example 2:
• Existing purchase agreements MS Office 2000 will be installed on client
• Existing software workstations built after January 1, 2001.
• Hardware / software compatibility
• Software version compatibility
• Patches
• Licenses


Category
Standards See “Procedures”
Supplier These requirements reflect any standing contracts Example:
Contracts with suppliers held by either EDS or the client, Data modeling software will be purchased
which offer exclusive rights to opportunities through the EDS agreement with Rational.
associated with the project. They may consider or
specify:
• Labor agreements
• Client owned subsidiaries
• Staff augmentation
• Purchase agreements
• Support agreements
• Product licenses
Support See “Operation Environment”
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 EXAMPLE 1:
result of the project. All project developers will attend the 1-day
MQSeries training workshop prior to
These requirements address training to be provided joining the team.
to the project team in support of project activities.
Example 2:
They may consider or specify: The application deployment team provides
• Training provider 1 session of an end user workshop, at the
• Types of training (end user, technical, vendor) client site, for a maximum of 10 users,
• Cost during the week prior to system
• Budget allowance implementation.
• 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


Category
Usability These requirements address the ease with which a Example 1:
person uses the product. They may consider or The user interface screen uses the attribute
specify: navigation sequence defined for the ABC
• Productivity level of the end user (anticipated application.
error rate)
• User’s experience level (novice or highly Example 2:
trained) The monitor and keyboard are on a work
• Diversity in user skills surface that supports operation by persons
• Minimum / maximum level of training or while standing, who are less than 5 feet
support required tall.
• 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
User Interface See “Usability”
Vendor See “Supplier Contracts”
Contracts
REFERENCES
Not applicable.
BIBLIOGRAPHY
Not applicable.


Non-Functional Requirements Checklist

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Non-Functional Requirements Checklist

Enviado por

Direitos autorais:

Formatos disponíveis

Business Analysis Non-functional Requirements Requirements Determination

Capability Checklist Process

NON-FUNCTIONAL REQUIREMENTS CHECKLIST

CR# Document Approval Modified By Section, Page(s) and Text Revised

This document is intended to serve as a checklist of non-functional requirements to be

These requirements address the need to trace or log

Saved 21 July, 2008 EDS Internal Page 2 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 3 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 4 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 5 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 6 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 7 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 8 of 18

Non-functional Description Example

These requirements address the process by which Example 2:

Saved 21 July, 2008 EDS Internal Page 9 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 10 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 11 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 12 of 18

Non-functional Description Example

They may consider or specify:

Saved 21 July, 2008 EDS Internal Page 13 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 14 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 15 of 18

Non-functional Description Example

These requirements address physical security

These requirements address how authorization is

Saved 21 July, 2008 EDS Internal Page 16 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 17 of 18

Non-functional Description Example

Saved 21 July, 2008 EDS Internal Page 18 of 18

Você também pode gostar