What are non-functional requirements?
Non-functional requirements can be defined as those set of requirements that provide the eco-system for the functionality to effectively work better. The plan is to implement the functional requirements as a part of system design. Plan to implement non-functional requirements are detailed in the system structure, as they are generally architecturally meaningful requirements.
Non-functional requirements classification categories
Security:Imagine a case where all your bank data can be accessed by anyone keying your account number if they had information about it to then withdraw cash from your account. The measurement can be expressed in a variety of ways like an effort/skill level/ time to break into the system.
Reliability:Requirements for program frequency fails. Often expressed in the MTBF measure (mean time between failures). It must be the definition of a patent failure. Also, do not confuse reliability and availability which is another type of conditions altogether. Be sure to specify the consequences of the program failure, and how to protect against failure, and develop a strategy to detect the error, and a strategy to correct.
Maintainability:This refers to all those requirements that relate to the ease with which an end user might be least affected even during the course of a maintenance activity. For example when banks carry out certain back-end maintenance activity the users might receive e-mails a day or two in advance informing the users that some back-end activities might be carried out as a result of which the net banking users might experience some issues though not seriously affecting them. This can be classified under maintainability.
Scalability:Imagine your organisation growing or anticipated to grow over the next 15-18 months. Then an additional number of users shall be added without too much of fuss round it. If this is possible without much of hue and cry then scalability can be defined as the property of a system to handle increase or decrease of workloads. This shall not cause appreciable strain on the system resources.
Usability:Requirements on how difficult it will be to learn and operate the system. Often it expresses requirements at the time of learning standards or the like.
Efficiency:This refers to addressing to capture if the proposed solution can deliver an acceptance performance taking into account the time to perform activities and resource utilisation levels.
Transferability:In case you are in the process of getting a solution delivered in a particular environment. Is this solution easy to be installed and uninstalled to be moved onto another environment without much hassles. This is referred to as transferability.
Do’s and Don’ts of non-functional requirements
·Identify agents, whenever useful
·Discover relationships between definitions of NFRs
·Discover relationships between solutions to NFRs
·Refine definitions as many times as needed
·Refine solutions as many times as needed
·Safeguard against conflicts
·Discover operationalization as reasons for conflicts/synergies
·Determine strengths of contributions
·Justify strengths of contributions
·Discover solutions from requirements
·Discover requirements from solutions
·Consider use of multiple solutions
·If necessary, quantify
·Evaluate, …subjectively, …objectively
·One definition fits all
·One solution solves all problems
·The contribution is such and such, since I say so
·Refine the definition only once
·They are falling down from the sky
·Dissociate from FRs
·May be more important than FRs, but should consume less resources
·You name it; our system does it
·No quantification, no existence
·Everybody needs the same
·Be only pessimistic
·Asking why “+” reveals ignorance
·Beg the question
·Evaluate & only evaluate
·Brainwash nothing but objectivity.