Kill NFR – The Merrily Used Technical Jargon

I consider “NFR” (Non Functional Requirements) a badly abused and mistreated term by numerous of IT & ITES companies & System Integration Services Providers; sometimes even by ISVs who build industry grade packaged software products and call them IPRs.


A requirement is a requirement. Functional or technical or process or policy or governance or cyber security oriented – not withstanding the nature or categorization. Fathom this, can a car be built as a functional product without worrying about the safety aspect of the thickness of the brake rotor or for that matter, without considering the non functional aspects of the aesthetics and ergonomics? If the car (automobile) is too hard and tangible as an example to take, let’s take the example of something intangible, like fragrance of a flower garden or the culture of an organization. Both need to scale. Both need to sustain. Both need to be spread wide. Both need to bring a zero moment of truth. Both need to serve the purpose of investment of time, effort and money resources and generate the outcome for which these are being built. The expected return – that is. They have a purpose to serve.

If we say that we build a rose garden in say a 100 square meter of a land patch in an evening leisure valley garden where the citizens & folks come for an evening stroll and relaxation after a hard, long and stressed days of work & also catch up with their social connections and in the process also get some physical exercise by walking; and we procure the best variety of the rose grafts saplings from the original most authentic source, and we put the best gardeners to plant the saplings after preparing the earth well, tilling, de-weeding, nourishing with right manure and moisture, planting in the right season, etc. and all this resulting in beautiful healthy flowers and outstanding appeal, but no fragrance? How would that feel?


Now, let’s take the culture of an organization. The top leader of the company articulates the clear mission & The timeless vision. The value system is defined clearly by the leader around (1) Follow the process, (2) be ethical & integrity first, (3) reward and acknowledge meritocracy, (4) customer centric & (5) care for people, teamwork & be collaborative; clearly by the leader. Then the Strategy to build this culture to is well defined, the top 50 to 500 next level of leaders, the execution manager, understand that well and practice the defined value system and implement the strategy. All is good till the time organization is small & nimble and people know each other. The degree of separation between the top layer and last layer in the structure is narrow and the width & geography of operation is small.

The building of the culture can be personally monitored by the leader, reviewed, felt and seen at work and fine tuning is easy to carry out. Now let’s get this to scale to say a 100,000 people, a country wide network of operation, a width of comprehensive products, sales as well as services and fulfillment teams, multiple layers to achieve execution of primary purpose of the organization’s existence (which is profitability and return on stakeholders investment & achievement of objectives), wide span of controls, varied time zones, individuals belief and value system, individuals background of upbringing, individuals needs and aspirations, etc. and suddenly the culture starts to morph itself into zillions of sub cultures and some times a completely distorted version of the envisaged original emerges. To the extent that even the basic sales process is forgotten.

Meritocracy is overtaken by the monthly and quarterly incentives, the team work and collaboration is dwarfed by the escalations and dysfunctional conflicts and then it will take million times the effort to rebuild the desired culture, a lot longer and painful process of rebuilding. That will require lots of change: change of people process strategy structure and much more.


Similarly, when a functionally rich and strong feature based software solution is built ignoring the needs like regression, referential integrity, quality of service of the components of the sub-system and modules, response time, TPS ( defined transaction per seconds – @ design level), retransmit and network management between the client and server or infra-components, break-point of scalability at design level, authentication, encryption, memory usage and memory abusage (yes a new term), payload optimization, component deployment architecture, high availability, DR/BCP, DNS, IPv6, partitioning of the data objects, cloud native ( what is that ?) etc., what does one expect to get? A boutique & cute system solution which will work very well till the time someone says that I now need 30% cost to income ratio reduction and 30% increased revenues vis-a-vis the previous solution or system or process.


And why are these crucial elements ignored, because these are so called NFRs, We Shall Worry About Them Later!  We shall do a load test later and find out the KINKs and remove them. We shall deliver them after the employee launch. We shall build these when the soft launch is successful. Too late. This is a recipe for disaster. You can forget scale with this approach. We are only kidding ourselves with this strategy and approach. The system can’t be built this way. The cookie will crumble before you get to taste it. We spend months and some times with external consultants paid millions of dollars to study the “functional specifications “, then we spend months to documentation and sign off and then we do dozens of walk through and check points on progress, ignoring the so called poor NFRs. The ITeS entity is always running behind schedule (thanks to novices deputed), the poor project manager loose her voice & the project sponsor or business sponsor has a lot at stake to deliver on timelines to worry about NFRs. The ITeS generally has the last laugh. They get away with 25% operational gross margin at minimum, and if this happened to be a T&M billing arrangement, welcome to the party!!


You see, we have no time for the OEM/ISV platform version upgrade, this is of no relevance, does not matter we have to test this twice after re-porting on upgraded base OS or most recent optimized for performance platform version of the OEM/ISV post completion of original scope(no matter if it does not deliver the promise) & post initial launch, that is because we will get double the opportunity to retrofit the CSMs/CRs, more money, prolonged engagement, we are in this for long term, etc. you know why, because we are your partners, because we also have to worry about Wall Street, and next quarter, and forecast and.,… You don’t get it. It is not in ITeS interest to Do It Right The First Time.


Another flavor of NFR is an animal called Purging – purge the stale or unused data. May be you are familiar with archiving. Well, these both achieve the same end result with respect to performance and scalability and response time of the production system. In my lifetime, 9 out of 10 systems going LIVE are devoid of purging functionality on day Zero, you know why? Ah.. this is NFR! And if the technology manager of the customer insisted at the risk of getting reasonably questioned for being stubborn and potentially running the risk of being accused of resisting for the sake of resistance, someone very clever in the steering committee will say, well, where is the data to purge? Why worry now. Yeah, we got a lot of time babe…


Another very hilarious but simple concept is that of REFSTAN – reference system trace audit number. You are wondering that I have gone a little berserk now. Please think again. In an automated system, this Stan is the only savior against duplicate processing, tracking of missed processing, primary key for reconciliation, etc. It is the unique identifier. It is also sometimes the only weapon to protect customers against the fraud and the dark web manipulations or even against a day light financial crime by miscreants gaming the modern day API based open system in the online world.


I think my fellow CIO & CTO & consumer side of the IT colleagues get my message & I should stop pushing now. At least we should build a culture of making the use of term NFR a taboo within our technology teams.


I think we should shoot the dxg called NFR.

(Image Courtesy:

Categories: Management

About Author

Orange Themes

Munish Mittal

Munish Mittal is Group Head - IT & CIO, HDFC Bank....

Read more

Write a Comment

Your e-mail address will not be published.
Required fields are marked*


Recent Comments