The Supportability transform - Making non-functional requirements functional

Introduction

We frequently hear the term RASP being bandied about when anyone speaks about architecture or non-functional requirements. Frequently, the S means Scalability (and R- Reliability, A – Availability, P –Performance).

An interesting take on the “S” however has been made by Nagaraju Pappu and Satish Sukumar (of Canopus Consulting) to replace the Scalability with Supportability. It is interesting because S for scalability restricts itself to how an application copes with large no. of users, data growth etc. whereas the term Supportability brings into its ambit everything related to how a good application should be designed including the attribute of Scalability.

Before we delve into what supportability brings into its ambit, let us first understand what problems applications typically face. Right from the beginning of developing an application the focus is overwhelmingly on what the end-users want or what business functions the application must provide – the functional requirements. Depending on the company that has sponsored the application development and/or the company developing the application, important other aspects of an application such as ease of maintenance, ease of management, ease of modification, ease of debugging, ease of integration, ease of testing, ease of determining usage patterns etc. are given short shrift.

This is also the reason why most companies when they float an RFP for application development also mention that the application should have non-functional features such as modifiability, manageability, maintainability, scalability etc. However, these terms remain undefined in the RFP, remain undefined in a software specification, undefined in an architecture document and will remain undefined till the end of the application development project. This results in these non-functional requirements being untestable. Contrast these with other non-functional requirements such as Availability and Performance. These can be tested clearly most times.

Being untestable makes it a point of contention between the project sponsor and the development team on whether these were implemented in the application or not.

This post discusses a way in which this problem can be solved.
Supportability
Supportability is a collection of all those non-functional requirements of an application that have been hitherto considered untestable. These are all those requirements that support the job of the various stakeholders involved in defining, creating, deploying and running the application.

So this would include everything from usability (“must be easy to use”) , scalability (“the application should support growth in concurrent users”), modifiability (“the application should be easily modifiable to add new features”), maintainability, manageability, configurability, upgradability, compatibility, testability and all the numerous “-ility”s that adorn the non-functional requirements section of a requirements/specification document.


If each of these supportability requirements is examined closely a common thread amongst all of these emerges - Each of these features actually enhances the productivity of some stakeholder or the other. For instance, manageability enhances the productivity of remote management personnel, system administrators etc. Maintainability enhances the productivity of the application management team that is charged with maintenance of the application. Testability allows the QA team on a project to test the application better.

The problem remains however, of arriving at a common definition that everyone can agree on whether these requirements were met in the application built or not. The way to solve this is to apply a “supportability transform” which is discussed in the next section.

The supportability transform
Simply put, the supportability transform is a way to define these requirements as functional requirements. Going by the definition of each of these requirements enhancing the productivity of various stakeholders, we can start asking the question of each of the stakeholders.

For instance, if modifiability is the requirement, the most important stakeholders here are the developer who modifies the code to change functionality or add new features and the business user who needs these changes to be implemented with minimal effort and with maximum ease. So if we start with the functions/features the application supports, we can start by asking the business user and the developer of what is it that they want from the application that will help make this easier. The answer a business user may give is that he/she needs a form to be able to modify the business rules associated with the application. The developer might say that the application must be written in a particular manner in order for the application to be easily modifiable. Once we start asking the right stakeholders what this requirement means to them, the answers start emerging about what should be implemented in the application in order for it to be defined clearly. Once these requirements are defined clearly as part of the functionality of the application, these requirements no longer become non-functional requirements. Moreover, once these are defined as functional requirements to be implemented as part of the application, these also become testable.

Another way to look at it is to clearly identify all the stakeholders in an application. The stakeholders frequently forgotten by most requirements definition workshops are the system administrator, the remote management team, the product manager, the CEO, the CFO, the CIO, the developer on the project, the test engineer on the project, the architect, the project manager etc. As we ask these stakeholders what is it that the application should support as features for these stakeholders, the non-functional requirements gradually transform into functional requirements.

Standard supportability features for every application

This section attempts to compile a standard set of features that most engineering/operations stakeholders require out of any application. For each feature mentioned here, the stakeholder whose productivity is benefitted is mentioned and the common supportability requirement bucket that it usually belongs to is also mentioned. Attaching these as images, since I didn't want to muck with HTML tables to put the table structure here.