Non-functional Requirements: Difference between revisions

From IHRIS Wiki
(Created page with '''Functional requirements'' specify specific behaviors of a system and are generally defined in the use cases. ''Nonfunctional requirements'' specify ...')
 
(No difference)

Revision as of 11:27, 17 July 2009

Functional requirements specify specific behaviors of a system and are generally defined in the use cases. Nonfunctional requirements specify overall characteristics such as cost and reliability. Use this list as a guideline for determining what nonfunctional requirements are required by the system and to define those requirements.

---

Archival Length of time data need to be retained within the application; level of difficulty to retrieve archived data.

Auditability Ability of the application to show what has happened to it, who did it and when (audit trail, transaction changes, before/after pictures, etc.); includes requirements for effective dating.

Authentication Security requirement to ensure "you are who you say you are."

Authorization Security requirement to ensure that users can access only certain functions within the application (by use case, subsystem, web page, business rule, field-level, etc.).

Availability When the system will be available for percentage of uptime.

Compatibility Adherence to industry standards for inputs/outputs.

Configurability Ability for the end users to change aspects of the software's configuration easily (through usable user interfaces).

Data Integrity Tolerance for loss, corruption or duplication of data.

Extensibility Ability to easily incorporate add-on modules of functionality to the application in production.

Installability Ease of system installation on all necessary platforms.

Integratibility Ability for this application to easily fit in as part of a larger system.

Interoperability APIs required to allow other applications to talk to this application easily. This is concerned only with the structure and ease of use of the APIs, not the industry standard protocols.

Leveragability / Reuse Ability to leverage common components across multiple products.

Localization Support for multiple languages on entry/query screens, in data fields, on reports, etc.; multi-byte character requirements; units-of-measure; currencies.

Maintainability Amount of effort required to maintain and enhance the system.

Multiple Environment Support Need to run on multiple environments on a single server (deployment, system test, user test, etc.).

Operability Easy of everyday operation; amount of qualification and training required for operators to oversee and troubleshoot the system.

Performance Constraints in batch (overnight window) and online.

Personalization Ability for individual users to personalize their view of the application.

Portability Ability to easily move the application to different hardware platforms, operating systems, database management systems, network protocols, etc.

Privacy Ability to hide transactions from internal company employees.

Reliability Confidence in the accuracy of transactions processed in the system.

Robustness Ability to handle error and boundary conditions while running (Internet connection goes down, power outage, hardware failure/replacement, etc.).

Scalability Ability to handle a wide variety of system configuration sizes and requirements.

Security General security requirements (encryption levels over the Internet, hacker-proofing, viruses, etc.).

Technology Any known technology requirements (operating system, programming language(s), database, hardware, other software, etc.).

Upgradeability Ability to quickly/easily upgrade from a previous version of this system to a newer version on servers and clients (upgrade scripts versus manual upgrades).

Usability / Achievability Level of training required for users to achieve their goals with the system.