(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