Understanding Both Requirements
A functional requirement defines a function that a system or system component must be able to perform. Probably the easiest way to explain ‘non-functional’ requirements is that they specify all the remaining requirements not covered by the functional requirements. Non-functional requirements specify the system’s ‘quality characteristics’ or ‘quality attributes’. Requirements also known as quality. Two products could have the same functions but their attributes can make them entirely different products. A Rolls Royce has more or less the same functionality as a Lada but many different attributes!
In terms of the system under test, the following attributes are the main areas of attention:
- Performance Requirements - High level speed of transactions for peak and expected growth of business volumes. e.g. throughput, response times.
- Reliability and recoverability - How reliable is the system is supposed to be and can it recover if it fails in any way? How correct/accurate is the data?
- Security - The prevention of unauthorised access to programs and data.
- Usability - How easy it is for a person to learn, use or interface with the system.
- Interoperability - The ability for the system to run in different operating environments and with different components.
- Data Migration - Transferring data from the legacy/incumbent system(s) to the new system.
We’ve created a questionnaire to assist in the capture of non-functional requirements and requirements in software engineering. We’ve attempted to make it usable and understandable by non-technical system users and stakeholders but they might need to be guided by a member of the IT team or development team.
If you need support with this, we can help. This functional requirements document can then be used to write the non-functional requirements – it does not, in isolation, form a requirements specification. It is not a complete list of questions but will form a good starting point and other relevant questions should be added as required. The NFR ID column is used to create a cross reference to the requirement that either already exists or get created in the requirements management tool.
Definition of subjective terms such as ‘significant’ or ‘substantial’ should be made in order to make a requirement specific to the business and system in question. Definitions could be in monetary or other objective term. The difficulty with purely qualitative requirements is that they are neither measurable nor testable. Ideally all non-functional requirements need to be specified in a way that makes them understandable by all of the stakeholders.
Please note this questionnaire does not form a complete set of the questions required to define all NFRs and must be added to or adapted as required.
What next?
nFocus have identified a number of challenges when implementing changes to improve non-functional testing. To help, we have a range of award winning services with information available below. Contact us if you would like to know more about product feature, user stories and how system works.
.png)
