# IT:AD:Non-Functional Requirements:Qualities # * [[../|(UP)]] {{indexmenu>.#2|nsort tsort}} * See also: * [[IT/AD/Documentation/NFRD/]] * [[IT/AD/Design/CheckLists/]] * [[Business/Concepts/Quality/]] * [[business/concepts/requirement/]] ##Summary ## Non-Functional requirements specify characteristics of the tool that impact on how well the tool will perform in its duty to add business value, as defined in the [[IT/AD/Definition/Business Requirements/]] and [[IT/AD/Definition/Functional Requirements/]]. ## Qualities ## The classic qualities that add the most value are listed below. ### Short List ### #### Security * Login requirements - factor (single factor, dual factor), access levels, CRUD levels * Password requirements - length, special characters, expiry, recycling policies * Inactivity timeouts – session durations, warnings, termination actions #### Auditability * Audited elements – what business elements will be audited? * Audited fields – which data fields will be audited? * Audit file characteristics - before image, after image, user and time stamp, etc * Audit access integration with remote services, viewability in app or other See: * [[IT/#TripleA/]] #### Performance ###### Responsiveness ###### Application loading, screen open and refresh times, etc * Processing times – functions, calculations, imports, exports * Query and Reporting times – initial loads and subsequent loads #### Capacity * Throughput – how many transactions per hour does the system need to be able to handle? * Storage – how much data does the system need to be able to store? * Year-on-year growth requirements #### Availability * Hours of operation – when is it available? Consider weekends, holidays, maintenance times, etc * Locations of operation – where should it be available from, what are the connection requirements? #### Reliability * *Stability*/*Reliability*: Mean Time Between Failures (MTBF) – What is the acceptable threshold for down-time? e.g. one a year, 4,000 hours * Mean Time To Recovery (MTR) – if broken, how much time is available to get the system back up again? #### Resiliance * ... #### Integrity * Fault trapping (I/O) – how to handle electronic interface failures, etc * Bad data trapping - data imports, flag-and-continue or stop the import policies, etc * Data integrity – referential integrity in database tables and interfaces * Image compression and decompression standards #### Recoverability * Backup frequencies – how often is the transaction data, set-up data, and system (code) backed-up? * Backup generations - what are the requirements for restoring to previous instance(s)? * Recovery process – how do recoveries work, what is the process? * Recovery time scales – how quickly should a recovery take to perform? #### Configurability * Configurable how? On Screen? Config files? #### Testability #### Compatibility * Compatibility with shared applications – What other systems does it need to talk to? * Compatibility with 3rd party applications – What other systems does it have to live with amicably? * *Portability*: Compatibility on different operating systems – What does it have to be able to run on? * Compatibility on different platforms – What are the hardware platforms it needs to work on? #### Maintainability * Conformance to architecture standards – What are the standards it needs to conform to or have exclusions from? * Conformance to design standards – What design standards must be adhered to or exclusions created? * Conformance to coding standards – What coding standards must be adhered to or exclusions created? #### Modifiability * Extensibility (adding features, and carry-forward of customizations at next major version upgrade) #### Usability * Accessibility * Look and feel standards - screen element density, layout and flow, colours, UI metaphors, keyboard shortcuts * Internationalization / localization requirements – languages, spellings, keyboards, paper sizes, etc #### Discoverability * Logical and predictable layout and behaviour #### Deployability * Deployment Packaging, Configuration per target environment * Documentation of deployment process #### Documentation * Required documentation items and audiences for each item, scriptable deployment ### FullList ### * [x] Reliability * [x] Accessibility * [x] Performance * [x] Maintainability * [x] Availability (see service level agreement) * [x] Backup * [x] Documentation * [x] Extensibility (adding features, and carry-forward of customizations at next major version upgrade) * [x] Failure management * [x] Maintainability * [x] Modifiability * [x] Portability * [x] Resilience * [x] Testability * [x] Disaster recovery * [x] Audit and control * [x] Capacity, current and forecast * [x] Deployability * [x] Configuration management * [x]Response time * Usability * Look and Feel * Human * Operational * Safety * Certification * Compliance * Dependency on other parties * Efficiency (resource consumption for given load) * Effectiveness (resulting performance in relation to effort) * Emotional factors (like fun or absorbing) * Environmental protection * Escrow * Legal and licensing issues or patent-infringement-avoidability * Interoperability * Network topology * Open source * Operability * Performance / response time (performance engineering) * Platform compatibility * Price * Privacy * Quality (e.g. faults discovered, faults delivered, fault removal efficacy) * Reporting * Resource constraints (processor speed, memory, disk space, network bandwidth, etc.) * Robustness * Scalability (horizontal, vertical) * Security * Software, tools, standards etc. Compatibility * Stability * Safety * Supportability * Usability by target user community ## List #2 ## Qualities ## * Usability * Look and Feel * Human * Performance * Maintainability * Operational * Safety * Reliability * Accessibility * Audit and control * Availability (see service level agreement) * Backup * Capacity, current and forecast * Certification * Compliance * Configuration management * Dependency on other parties * Deployment * Documentation * Disaster recovery * Efficiency (resource consumption for given load) * Effectiveness (resulting performance in relation to effort) * Emotional factors (like fun or absorbing) * Environmental protection * Escrow * Extensibility (adding features, and carry-forward of customizations at next major version upgrade) * Failure management * Legal and licensing issues or patent-infringement-avoidability * Interoperability * Maintainability * Modifiability * Network topology * Open source * Operability * Performance / response time (performance engineering) * Platform compatibility * Price * Privacy * Portability * Quality (e.g. faults discovered, faults delivered, fault removal efficacy) * Recovery / recoverability (e.g. mean time to recovery - MTTR) * Reliability (e.g. mean time between failures - MTBF) * Reporting * Resilience * Resource constraints (processor speed, memory, disk space, network bandwidth, etc.) * Response time * Robustness * Scalability (horizontal, vertical) * Security * Software, tools, standards etc. Compatibility * Stability * Safety * Supportability * Testability * Usability by target user community ## Resources ## * [Non-functional (quality) requirements](http://en.wikipedia.org/wiki/Non-functional_requirement) * http://leadinganswers.typepad.com/leading_answers/2009/03/nonfunctional-requirements-minimal-checklist.html