Mastering Non-Functional Requirements

Sameer Paradkar

• Publisher: Packt Publishing
• Year: 2017
• ISBN:
  9781788297899
• Edition: 1
• Topic: Computer Science
• Subtopic: Programming
• Index: Computer Science

This book covers the most critical 24 NFRs that are applicable to IT applications and systems.About This Book• Explains three stages of nonfunctional requirements, that is, analysis, architecture, and assessment• In-depth knowledge of NFR framework and taxonomy that provides guidance around the modelling phase for the NFRs• Coverage of 24 critical and pivotal NFRs, including the analysis, architecture, and assessment.Who This Book Is ForThe primary audience for this title are the gamut of roles starting from IT consultant to chief architects who are responsible to deliver strategic, tactical, and operational engagements for fortune 100 customers worldwide. Nonfunctional requirements are the key to any software / IT program. They cannot be overlooked or ignored. The book provides a comprehensive approach from analysis, architecture, and measurement of nonfunctional requirements. The book includes considerations for bespoke (Java, .Net, and COTS applications). These are applicable to IT applications from various 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. The audience for this book include business analysts, enterprise architects, business architects, solution architects, technical architects/designers, domain/security/integration architects, software developers, support engineers and test engineers, technical project managers, project leads/technical leads/technical project managers, and students from the computer science/IT streamWhat You Will Learn• Learn techniques related to the analysis, architecture, and monitoring of NFRs• Understand the various tools, techniques, and processes in order to improve the overall quality of the desired outcomes• Embrace the best practices of architecting, metrics, and success factors for NFRs• Identify the common pitfalls to be avoided and the patterns to leverage• Understand taxonomy and framework for NFRs• Learn the design guidelines for architecting applications and systems relating to NFRs• Abstract different methodologies to analyze and gather NFRsIn DetailNon-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.Style and approachThe book takes a pragmatic approach, describing various techniques related to the analysis of NFRs, the architecture of NFRs, and assessment of NFRs.

Architectural Patterns and its Impact on NFRs

As a software architect or designer, you should be able to read, understand, and apply these models in the context of engagement requirements. One would able to determine if a particular pattern applies to the context in which you are architecting and whether the stated problem exists in your proposed system. You can then follow the pattern and apply it in your particular context.

This is not about a particular technology specification, such as Microsoft's .NET, Oracle's JEE, or a particular product set, such as the Oracle Application Server. This is a conceptual view of systems that we're interested in and how architectural components of the system are arranged. Where appropriate, we have described how a particular technology, platform, or product supports the general concepts. This includes the idea of the relative cost of different solutions since, as a software architect, you will almost certainly become involved in brainstorming at the start of the project cycle when the initial architecture is defined.

This chapter covers the following key topics:

• Patterns and techniques related to architecting NFRs
• Understanding drivers, solutions and the impact on different NFRs
• Metrics, KPIs and methodology for architecting NFRs

Core architecture patterns

This section describes the core architecture patterns and its impact on NFRs:

Component-based architecture

To create a good starting point for for a scalable application architecture, a typical system may require a product catalog, registration and personalization, online ordering for the e-commerce domain and various information-based applications, such as a retail outlet finder, and online troubleshooting. Each of these must be logically separated to some degree. As part of the separation, each could be implemented on its own hardware as a set of 'collaborating semi-autonomous applications'. However, they must all combine at different times and in various ways to deliver a 'seamless' experience for the end user.

Context

Creating a business application requires many different types of functionalities, as well as high levels of non-functional characteristics, such as availability, manageability, and performance.

Drivers

Drivers for the component-based architecture solution pattern include:

• Repeated interactions between separate applications can be costly
• Different applications scale at different rates
• Each application will need to be managed separately, which adds greatly to the management overhead of the system
• The interactions between many different applications can create a system that is complex and challenging to maintain
• Different functionality could be delivered by various applications, but each one is then a single point of failure

Solution

Adopt a component-basedarchitecture and group all core system functionality in a single application. Internally partition the application according to the preferred logical architecture. By adopting a collaborating semi-autonomous application architecture, outlined in the previous section, we would end up with a complex architecture consisting of several separate applications. Adopting a component-based architecture means that we lump all this complexity into a single application.

Impact on NFR's

This lists the impact on NFRs of the component-based solution pattern:

NFRs	Description
Availability	The application of this pattern does not in itself improve the availability of the system. However, application server architecture lays the foundation for a highly-available system.
Performance	Performance is likely to be significantly improved. Whereas we had all the semi-autonomous applications collaborating (using some form of inter-process or inter-server communication) to render pages or perform complex functions, now we have a single application, although parts of this may still require inter-process communication, depending on implementation choices.
Scalability	The application of this pattern does not in itself improve the scalability of the system. However, application server architecture lays the foundation for a highly scalable system.
Security	Security is marginally improved due to having only one application and one database to worry about securing.
Manageability	Manageability is significantly improved: as earlier we had many applications to manage, now we only have one. Even when we add more complexity to the architecture to achieve scalability, and so on. Application server architecture lays the foundation for a more manageable system.
Maintainability	Because all the logically separate software 'modules' are part of the same application, we don't have to worry about complex communication mechanisms. However, we have not lost the benefits of having well-defined sets of functionality which can, potentially, help to isolate bugs. On the whole, maintainability is improved.
Flexibility	This type of system architecture is flexible as we have a partitioning, which gives us flexibility.
Portability	Not affected.
Cost	Application server architecture provides a foundation where manageability, performance, availability, and scalability can be addressed more easily (and therefore more cheaply). Running the application in the .NET framework or on a JEE application server can potentially reduce costs; the cost of purchasing the infrastructure can easily be offset by the cost of building all the functionality pro...

Table of contents

• Title Page
• Copyright
• Credits
• About the Author
• About the Reviewer
• www.PacktPub.com
• Customer Feedback
• Preface
• Understanding NFRs
• Taxonomy and Framework for NFRs
• Methodology Eliciting - Non Functional Requirements
• Solutions Addressing NFRs
• Architectural Patterns and its Impact on NFRs
• Sizing, Measurement and Monitoring
• Understanding Pivotal NFRs and Closing Thoughts