Non Functional Requirements
Non-Functional requirements are those requirements that are not readily captured in use-cases as use-cases are typically functional (behavioural)in nature.
Also known as 'Supplementary Specifications' they are the URPS+ of the FURPS+ model (Functional, Usability, Reliability, Performance, Supportability), described by Robert Grady (Practical Software Metrics for Project Management and Process Improvement. Prentice-Hall.). The + being requirements concerning design constraints, implementation requirements, interface requirements and physical environment requirements or constraints.
Whereas 'Functional' requirements describe the actions that the system must be able to perform, 'Non-Functional' requirements describe attributes of the system or attributes of the system environment.
Many times there is confusion about some requirements whether they are Functional or Non-Functional, especially frequently we see that re-usable functionality often ends up in the supplementary specifications rather than in some kind of use case that should be 'included' in many others, as a short cut that usually leads to confusion.
We can use this Forum to discuss what constitutes a Non-Functional requirement and how and where to capture it (in formal or informal or Agile or ....... methodlogies)
'U' for Usability
The 'U' in FURPS+ is 'U' for 'Usability' these requirements can be sub-divided into:
* human factors
* look and feel (or aesthetics)
* user interface consistency
* help (online and context-sensitive)
* wizards, fast paths and agents
* end user documentation
* end user and trainer training materials
All things that directly involve user-interaction with the system in a somewhat passive way.
Usability requirements are often collected by following a 'User Centred Design' approach, where the main focus is on the actual Users of the system and get them involved in the system effort as soon as possible, so that we can properly understand their tasks and the ways in which they will interact with the system. Users often explain what they do in a much different way than how they actually do it. Watching them work with a system as early as possible can radically alter the way in which requirements are understood.
Using a 'User-Centred' approach we can better understand the requirements by observing the User at work, video-taping several Users and even 'being' the User.
It is a lot easier to succeed when the Users get directly involved as soon as possible in the process with a major by-product being that it quickly becomes their system and not a system developed for them by people who do not understand what they do.