Non Functional Requirements

A non-functional requirement is a requirement that specifies criteria that can be used to assess the operation of a system, rather than specific system behaviour. This is in contrast to functional requirements that define specific behaviour or functions. The requirements for implementing functional requirements are detailed in Use Cases. The criteria for implementing non-functional requirements is detailed in a system architecture document.

Typical criteria for determining non-functional requirements are detailed below:

Accessibility How should the system be accessed and who by?
Audit and control What level of action audit should be in place
Availability What tolerance is there for the system being available for use?
Backup What is the requirement for backing up the system and what is the acceptable effect against Availability
Capacity, current and forecast What volumes of the data should be catered for and what is the projected growth of the system over time
Certification Does the system need to be accredited by an external body?
Compatibility What platforms should the application run on e.g. browsers, operating systems.
Compliance Are there regulatory standards or considerations? What laws and regulations apply to the software
Configuration management What are the requirements for source control and build processes? Does the software concern data of a sensitive nature?
Dependency on other parties Are 3rd parties or systems involved in the project and is there a dependency on their systems or deliverables?
Deployment How is the software to be deployed into a live environment?
Documentation What documentation is required to accompany the software e.g. design documents, user guides, installation guides etc.
Disaster recovery How quickly should a system failure be addressed? Does the system need to operate with a hot standby process for both software and data recovery and where will this be located.
Emotional factors (like fun or absorbing or has “Wow! Factor”) What is the guideline in terms of appearance?
Extensibility What is the roadmap for the software? Are there likely to be major evolutions of the software over time?
Failure management Where are the responsibilities for recovery after failure. Who will be involved?
Fault tolerance Operational System Monitoring, Measuring, and Management
Legal and licensing Legal and licensing & patent infringement issues. Should there be a licensing restriction or usage charging mechanism in the software
Interoperability Should the software work with other systems and how. Are there any potential future requirements for interoperability?
Maintainability What are the requirements for software maintenance?
Modifiability How easy should it be to modify the software and what elements should be configurable within the software?
Network If the software is to be operating on a network, how is it configured, LAN, WAN, are there restrictions?
Open source What, if any, is the policy on using open source software?
Performance What are the performance requirements and what is the predicted usage/growth to which the performance requirements must meet
Price Is there a budget restriction that may mean compromise on non-functional requirements
Privacy What sensitive data will the system store and what level of privacy is required for this data. This may also restrict software’s hosting location due to data security laws.
Portability How easy should it be to move the software to operate in different environments.
Quality Are there expectations and tolerances on the number of faults identified and their response & resolution timescales
Recovery / recoverability What are the expectations in terms of timescale to recovery the system for an inoperable situation. Measured by MTTR (mean time to recovery)
Reliability What is the expectation in terms of timescales between failures. Measured by MTBF (mean time between failures)
Resilience How the software should react to failure to continue operation.
Response time How quickly the software should react to an operation e.g. data retrieval
Reusability Are there expectations on code reusability in the software
Robustness The ability of the system to cope with errors
Scalability The ability of the software to cope with data growth and concurrent user growth
Security The level of security required for the system (users & access) and data (encryption). How much protection is required?
Resource constraints What hardware/environmental constraints are there e.g. processor speed, memory, disk space, network bandwidth, etc.
Software, tools, standards etc. Are there expectations in terms of the language, development tools, testing, coding standards, user interface standards etc that must be adhered to?
Stability How likely are the code objects to change?
Supportability How and by whom will the software be supported. What level of documentation, code commenting etc is required. Are there restrictions in terms of accessing the live system and data to replicate & view issues? What levels of support are required?
Testability How complex will the software be to test e.g. will harnesses be required to replicate the interaction with an external system?
Usability How easy should it be to use the software? Is it supporting the processes of experts or should it simplify the process to support novices?
User Friendliness How much support should be provided for the user? Context sensitive help, prompts, info boxes, documented user guides?

These criteria are explored during Discovery phase workshops and will affect the proposed system architecture and scope of the project. Ideally, they should be considered where possible prior to commencing the Discovery phase.

Follow the link to return to the software development pages or contact Dunstan Thomas to discuss your requirements.