Skip to main content

What are the Quality Attributes of Non-Functional Requirements? And How to Maintain the Quality of Non-Functional Requirements

Q1.What are the quality attributes of a non-functional requirement?

Following are the quality attributes of a non-functional requirement:
  1. Functional Suitability
    • Appropriateness
    • Completeness
    • Correctness
  2. Reliability
    • Availability
    • Fault Tolerance
    • Recoverability
    • Maturity
  3. Usability
    • Accessibility
    • Appropriateness
    • Learnability
    • Operability
    • User Error Protection
    • User Interface Aesthetics
  4. Performance Efficiency
    • Time Behavior
    • Resource Utilization
  5. Security
    • Confidentiality
    • Integrity
    • Non-Repudiation
    • Accountability
    • Authenticity
  6. Compatability
    • Co-Existence
    • Interoperability
  7. Maintainability
    • Analyzability
    • Reusability
    • Testability
  8. Portability
    • Adaptability
    • Instability
    • Replaceability

Q2. How can we maintain the quality of non-functional requirements?

Maintenance of the NFRs requires these being measurable. Following steps are required during the software product lifecycle for ensuring the maintenance of the non-functional requirements:

  1. Explicitly list the software quality objectives along with their priorities.  
  2. Performing software quality benchmarking.  
  3. Using checklists on software quality.   
  4. Establishing explicit QA (Quality Assurance) activities. 
  5. Using machine-analyzable software specifications (SS).
  6. Ensuring that the software requirements are testable.  
  7. Using requirements – properties matrix for tracing the non-functional requirement to its specified functional requirement.   
  8. Establishing standards (coding standards), particularly for a structured code.  
  9. Standard compliance checking by using an automated code auditor. 
  10. Performing design inspection and code inspection.

Q3. Are there any tools, techniques or frameworks that help maintain the quality of non-functional requirements?

Various tools, techniques, and frameworks are available that assists in maintaining the quality of not only the NFRs but also help maintain the quality of the functional requirements:
Tool / Technique / Framework
Description
Quality Function Deployment(QFD)
This tool helps maintain the quality of any user requirement through the design of the software product, while also keeping in mind the competition among itself and other companies.
Requirement Properties – Matrix
The matrix maps the required non-functional requirement against each of the functional requirement along with the expected system activity ensuring the execution of that particular non-functional requirement.
This matrix is used throughout the development lifecycle of the software product.
Code Structuredness
This technique is most suitable for maintaining the non-functional requirements within a large scale software product. This technique focuses on good programming practices that ensure accurate implementation of the non-functional requirements within a software product.
Quality Model using ISO 9000 standards
Quality Model consists of all the non-functional requirements along with its sub-characteristics based on the ISO standards. This model can help select a software architecture that supports the desired non-functional requirements of the software system.
SAFe Requirements Model
According to this model the non-functional requirements may be connected to and thus constraint no, some or many backlog items when considering them in agile software development.
The purpose of this model is to provide the stakeholders with scalable software non–functional requirements.
Solution Intent
This tool traces the current and evolving non-functional requirements throughout the development lifecycle.

References:


Labels:

Comments

Post a Comment

Popular posts from this blog

Software Architecture Views and Structures

Description of Views: In the year 1995 Kruchten presented his 4+1 architectural view model consisting of the following five types of views: Logical Development Process Physical Scenario Later with further development and research in the domain of architectural view following new views were developed to represent their respective structures: Views Sub-View of Description Logical None Highlights the functionalities provided by the system to the end-users. Unified Modeling Language (UML) diagrams such as the Class diagram, Domain diagram, Use Case diagram, State diagrams and Activity diagrams can be used to represent the logical view of the architecture. Development None It is also known as an implementation view. It is mainly concerned with the software project management. It represents the system with the programmer’s perspective. Process None It deals with the representation of...
2 comments
Read more

Overview of MISRA C++ (2008)

Introduction Software to Control Autonomous Car MISRA C ++ is a software development standard for C and C++ programming language that aims to facilitate code portability and reliability in the context of embedded systems, specifically those systems programming in ANSI C. Its mission is:  “   To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software ” MISRA - A Brief History In 1998 MISRA targeted only the automotive industry but later released it focus on generic rules for developing safety-critical applications such as: anti-lock braking system  (ABS), and auto-pilot software system etc. No major changes have been made to the MISRA C++ standard after the version released in the year 2008. Every autonomous vehicle developed can only be allowed for commercial or industrial use if each of its hardware and software component adheres to the required standards. ...
1 comment
Read more

How traceability of non-functional requirements is managed throughout the software development process?

1. Requirements Traceability: Requirements traceability is the process of describing and keeping track of a set of requirements throughout the system’s lifecycle. The process assists in managing changing requirements of a particular software product. Requirements traceability of is two types, forward traceability where a particular requirement involved during the design and implementation phases of the software system, and backward requirement traceability where a particular requirement is being traced back to its source. 2. Proposed Solutions for the Traceability of Non - Functional Requirements : The author J. Merilinna [8], proposed a framework supported by a tool to trace the non-functional requirements in both forward and backward direction. The proposed method is based on the context of DSM (Domain Specific Modeling).  The NFR+1 framework involved are used for the elicitation, definition and redefinition of the system’s non-functional requirements. The...
3 comments
Read more