Why do we care for Non-Functional Requirements?

What exactly is a Non-Functional Requirement?

The “non-functional requirement (NFRs) – in software system engineering, a software requirement that describes not what the software will do, but how the software will do it. For example, software performance requirements, software external interface requirements, design constraints, and software quality attributes”. Non-Functional Requirements (NFRs) play a strategic role in ascertaining the achievement or disappointment of a framework. Hence, the specification of Non-Functional Requirements is considered to be one of the most critical and sensitive software development activities that require utmost care and precision by Software development companies.

Different Types of NFRs

Non functional requirements list top software development companies, outsource development, IT software development company
Figure 1: List of NFRs [1]

There is an exhaustive list of 114 NFRs in various types of systems and application domains as shown in Figure 1.

Complexity Factor in Non-Functional Requirements

It is impractical to concentrate on each NFR during development and testing as they are subjected to complex shared mutual connections. Subsequently, there is a need to settle for the best possible compromise choices among the NFRs so that critical NFRs can be handled successfully.

Generally, projects suffer because of improper determination and documentation of non-functional requirements as there is a lack of empirical studies available for analyzing the contribution of non-functional requirements towards product success. Thus, before designing a software product, it is extremely necessary to understand the precise NFRs of the customer and document them into an acceptable format to systematically execute software development activities [2]. Even Top Software Development Companies find it challenging to peel away and outsource this analysis and documentation of NFR.

Implementation Approach

For the development of quality software, it is indeed necessary to specify both functional and non-functional requirements for the proposed software especially for those who program it. Therefore, it is required to model the non-functional properties of the system both informally and formally.  The standard Use Case diagram can be extended with new artifacts as mentioned by researchers [3] to model NFRs. These extended artifacts help to include levels of detail (of NFRs) for the system engineers in system development. To promote correctness, viability, traceable and visibility to different classes of users these critical NFRs are required to validate by some mathematical model like Reference Model [3].

The following set of questions taken from the Pressman can be used for validating NFRs as these characteristics can be considered as desirable for the functional and quality requirements for a set of product requirements. These characteristics can help us to decide the degree to which these characteristics need to be satisfied while specifying NFRs in the SRS document.

Q1. Does each requirement have a cause?

Q2. Is each requirement practicable?

Q3. Each requirement is testable once put into execution?

Q4. Is each requirement restricted and definite?

Q5. Do any requirements have interdependency on other requirements?

Q6. Is the requirement observable to the goals of the system?

Q7. Is the requirement is confined in quantitative terms?

Q8. Are requirements stated undoubtedly? Can they be misapprehended?

Such systematic treatment of NFRs helps to trace the progress made at each phase of software development. The use of cognitive dimensions can provide additional insight into the perceived usability of the different formal and informal models for NFRs.

Case Study

During the penetration testing at the customer site for the product based on Health Care Services, developed at AgBe Technologies, some issues related to security vulnerabilities (NFRs) were identified. Issues include Rate Limit not implemented on sending login and on sending Forget Password, Predictable values of Ids, Personal Information Disclosure during communication between parties, and Insecure Direct Object Reference.  Though these were minor issues once the product moved to the maintenance phase, it becomes challenging for the start-ups in terms of time and effort.

Such issues can easily be resolved during unit testing if the critical NFRs were analyzed at an early stage of development and documented in a way (by assigning stories) so that issues should not be ignored by the developer and tester [4]. Contact Us

Conclusion

Non-Functional Requirements (NFRs) represent a vital idea that maneuvers an essential role in determining the success or the failure of a software framework product. Hence it will be ideal to spend effort and resources while identifying and modeling NFRs, instead of incorporated them straightforwardly amid execution. A definitive objective of further research on Software Engineering should be to build up a procedure model and formal model that viably distinguish critical NFRs from the rest and then oversee potential clashes among them amid prerequisite investigation/analysis and development stage. It helps us to ensure that the most critical non-functional requirements (NFRs) are addressed immediately in case of an occurrence of constrained resources.

References:

More
articles