Want your Digital Transformation to be successful? Pay attention to NFRs

Problem Statement

When it comes to Digital Transformations, agility and speed are very important. However, many clients take shortcuts to improve speed to market. This is very risky and can bring unintended consequences. Certain clients have a policy on Non-Functional Requirements (NFRs) to not modify existing NFRs for existing systems. Only new systems have a requirement to create NFRs. This raises the risk that changes in design that affect existing systems may render current NFRs unachievable. The optimal phase to define NFRs and to identify the critical components to be tested is during the Design phase. In several of my previous projects, I have found that NFR implementation is not being addressed early enough in the process for these clients. This is a major risk to a successful transformation.

Priority is being given to functional requirements, but there needs to be a balance between functional and non-functional aspects of a solution. This article will focus on how to find that balance, the key aspects that need to be considered to achieve success in this area, and how to minimize the risks associated with poorly defined NFRs.

Identify Key Systems

Create a list of identified critical systems having an impact from the NFR perspective, customer experience and other key non-functional aspects, including ability for customers to access their data in a timely fashion. Document which systems are more critical where the customer could lose access to their data.

NFR Recommended Practices

While functional requirements are mandatory in digital transformations, many times NFRs are not. This is a mistake. NFRs define constraints and restrictions that need to be met in order to design the system properly. Addressing NFRs is key to user adoption of any new functionality being made available. User satisfaction is one of the keys for any digital transformation. Hence, making sure NFRs are met is paramount.

It is understandable why NFRs sometimes get overlooked or given less importance than functional requirements. After all, everyone wants to see what is in front of them. NFRs are typically out of sight for the users of the system. NFRs are more than response time and system availability. They include multiple aspects of the system that are easily overlooked. They include:

· Performance

· Availability

· Reliability

· Capacity

· Usability

· Regulatory

· Security

· Industry-specific

· Privacy

· Accessibility

· Compatibility

· Extensibility

· Redundancy

There are many others and they typically referred to as the “ilities” of the system.

Committing to certain NFRs may have an impact on existing applications and may significantly impact the cost of your transformation. It is important to analyze how the NFRs will affect your design and performing a cost benefit analysis is strongly recommended. With the advent of cloud solutions, it is easy to get excited about unlimited infrastructure in the cloud to handle scaling and availability and losing sight of the fact that committing to this blindly can negatively affect your bottom line. Having a good idea of how much infrastructure you will need can significantly reduce the cost of your cloud solution.

How you handle NFRs is dependent upon what type of transformation you are performing. Greenfield transformations will require different handling than Brownfield transformations. Brownfield transformations require analysis of impact to existing systems, even if they are not changing. Brownfield transformations sometimes lose sight of the fact that some design changes significantly affect the behavior of existing systems due to change in data flows and other aspects of end to end transactions. That is why it is critical to review NFRs for feasibility and applicability.

Recommended Actions

The following is the sequence of recommended actions for key systems based on impact to customer experience, regulatory compliance, and other key factors:

· Identify and align existing NFRs for each of the key systems and determine their criticality. An initial assessment on what NFR information is available for key systems and what the impact may be from the non-functional perspective. High priority use cases where key systems are involved should be identified as well. Existing NFRs may have been created based on certain assumptions that may no longer be valid. By reviewing the NFRs, there is an opportunity to determine if the business needs to adjust their expectations based on different business levers, like cost, customer satisfaction, regulatory compliance, and security. Doing this before UAT allows for proper planning and mitigates the risk of negatively affecting the timeline by reducing the probability of surprises. Additionally, process maps should highlight where NFRs play a critical role in the process. They should highlight how batch processes are affected and how real time transactions may impact the end to end flow. They should also highlight processes that are critical to customer satisfaction and user experience. By reviewing the NFRs, there is an opportunity to determine if the technology needs to be adjusted to fulfill the business needs. Timing: Needs to be started as early as possible in the design process.

· Establish a baseline on where key systems stand in terms of meeting documented NFRs. This is needed to determine how application changes impact the current functionality of existing systems. The idea is not to do complete NFR test for existing systems, but to collect information already available that can be used for establishing this baseline. This may include system logs, output from monitoring tools, previous tests that were conducted during the previous deployment, etc. Existing systems may be part of end to end transactions that are introducing new technologies, like microservices and containers. Timing: Needs to be started as early as possible in the design process.

· Project deliverables (Design Documents, Test Plans, etc) need to articulate how NFRs will be met for a particular system and the criteria for meeting the NFRs. These deliverables need to reflect this information. For instance, how to handle fail-over when a server instance fails. How do you ensure that transactions are being retried a certain number of times, etc. Make sure that the deliverables reflect NFRs that have been reviewed as outlined in the previous two bullets. Timing: Include as part of the test plan(s) creation for the priority 1 use cases and as part of Design Document deliverable.

· Centralize and coordinate NFR testing. It is important to have good management of all testing activities to ensure proper alignment with all groups performing testing activities. NFR testing may disrupt functional testing, so it is important it is aligned appropriately. Timing: Starting with SIT.

· Ensure your test environments are set up for NFR testing. The test plan should reflect how NFRs will be validated. There is a lot of work in this area. Timing: Start with prioritizing the NFRs for the key systems. NFRs that will be tested starting with SIT should have NFR testing information added to the appropriate test plans early in the design process.

· Record your NFR tests and store them for future reference as baseline for your next major implementation. Ensure that appropriate tools are in place to perform proper NFR testing and that the tools allow for recording of telemetry that can used to establish an initial baseline of the new functionality. Timing: Tools should be in place while creating the environments necessary for NFR testing. A definite plan should be in place on when they will be available for each appropriate testing phase.

Summary

NFRs are critical to any digital transformation. Without paying enough attention to them, your transformation is very likely to fail. No one wants to use a system that is slow and unreliable, even if it has great functionality and features. Do not let something as critical as NFRs derail the success of your transformation.