Book Image

Mastering Non-Functional Requirements

By : Sameer Paradkar
Book Image

Mastering Non-Functional Requirements

By: Sameer Paradkar

Overview of this book

Non-functional Requirements are key to any software/IT program and cannot be overlooked or ignored. This book provides a comprehensive approach to the analysis, architecture, and measurement of NFRs. It includes considerations for bespoke Java, .NET, and COTS applications that are applicable to IT applications/systems in different domains. The book outlines the methodology for capturing the NFRs and also describes a framework that can be leveraged by analysts and architects for tackling NFRs for various engagements. This book starts off by explaining the various KPIs, taxonomies, and methods for identifying NFRs. Learn the design guidelines for architecting applications and systems relating to NFRs and design principles to achieve the desired outcome. We will then move on to various key tiers/layers and patterns pertaining to the business, database, and integrating tiers. After this, we will dive deep into the topics pertaining to techniques related to monitoring and measurement of NFRs, such as sizing, analytical modeling, and quality assurance. Lastly, we end the book by describing some pivotal NFRs and checklists for the software quality attributes related to the business, application, data, and infrastructure domains.
Table of Contents (14 chapters)

Business tier patterns


This section describes the business tier solution patterns and their impact on NFRs.

Active/Passive clustering

This pattern warrants that the system as a whole continues to function if part(s) of the system go offline.

Context

Architecting an n-tier architecture where high availability is one of the prime non-functional requirements.

Drivers

Drivers for the active/passive solution pattern include:

  • The system has a required level of availability which must be delivered even in the face of hardware or software failure.
  • The system has to be maintained and upgraded over time. Even with planned downtime, there may be a need to upgrade or fix a system element whilst ensuring the system remains available.

Solution

Provide alternative capacity for your critical system elements by duplicating those elements. Redirect users to the duplicate should the active element become unavailable.

This pattern must be applied equally to hardware and software. Software elements are, perhaps, more prone...