Manage NFRs as Rigorously as Functional Requirements—6 Steps

Technology officers are consumed by issues such as scalability, security, databases and operational issues, yet few have a structured and systematic approach to manage NFRs. 

(Image source: Shutterstock.)

When I often talk to CIO/CTO, the conversation is almost always about NFRs such as scalability, security, databases and operational issues like availability of an application or infrastructure. Yet, many do not have a structured and systematic approach to manage NFRs.

In this article, I will provide a summary of how to manage NFRs with the same rigor and structure as business analysts and product owners manage functional requirements.  Here are 6 simple steps for managing NFRs:

  1. NFRs are very important and everyone on a given project has a role to play. This includes CTOs/CIOs and business folks who own the project. The roles must be understood from the beginning and communicated explicitly as part of the project. Create a responsible, accountable, contributing or informed (RACI) party chart regarding what is owned by whom. This can be achieved by creating a simple RACI matrix between various roles on the projects namely scrum master, project owner, business analysts, enterprise architect, solution architect, tester, support engineer etc.
  2. Focus on the conceptual architecture. Identify all the dependencies between entities in play. Dependency can be defined as: data needs to be considered between the two entities; integration pattern/solution that exists between the two entities (batch, Real time); operational readiness (in case a dependent entity is out of service); or resting requirements between two entities. An entity can be defined as an application, API, web service, sub-system or even a container. For valid dependencies develop requirements for the following:
  3. Data Considerations: This is where you would consider questions such as data environment/usage, performance needs, size, type of database, vendor, backup, recovery, security, access, reporting, storage and data models. Data and solution architects should be involved earlier in the project so they can flesh out detailed data requirements for each dependency.
  4. Operational Considerations: This is most important part and often overlooked until it becomes a problem. Involve your support engineers and organization earlier in the development and architecture review process. They will be able to address all relevant operational need for the given dependencies such as service level agreement, system documentation, batch job schedule, error handling, deployment considerations and much more.
  5. Integration Considerations: When considering integration requirements between two dependent entities, business analysts and solution architects should work closely with enterprise architects in defining how entities will interact such as; interfaces, APIs, single sign-on (SSO), volume of data, frequency of data, format, scalability and performance.
  6. Testing Considerations: Due to time constraints and other execution related issues, testing is often squeezed to minimal time. However, I argue that if testing requirements are considered earlier in a project then time can be optimally utilized in the end. When considering testing between entities develop plans to test load, perform regression and scale.

There are many other NFRs that a project must consider such as application and infrastructure environment and network impact. These requirements can also be captured within these six steps.  However, the purpose of this article is to provide a structured approach to consider NFRs within a project.  This approach can be easily extended to include other or any NFRs.  When it comes to NFRs, do it often and do it early!

An Insurer’s Path to Cloud Enablement: 4 Steps to Get You There

Alok Mehta // Alok Mehta is a veteran financial services technology leader who most recently served as GCM Grosvenor Capital Management’s Chief Technology Officer between 2015-2019. Mehta was responsible for overseeing the strategic implementation of technology and information systems for the firm. Mehta has held senior technology in the insurance industry, including CTO at Continental Assurance Company, and Chief Architect at Allstate. He began his career at American Financial Systems as a Senior Consultant from 1990 to 1995 and later became Chief Technology Officer of the firm from 1995 to 2005.

Leave a Comment