Non Functional Aspects
NFRs are as important as functional
With functional requirements, there is a mechanism to have clear understanding of needs, validating and delivering those.
Non functional requirements for some reasons are either an after-thought or always end up being lower priority item from the wish list. Those are often termed as technical team requirements. Product team should treat non functional requirements as product requirements and not disown those. A base of an extraordinary product offering can sadly be foiled by ignoring the non functional aspects. Consumer experience may suffer because of non functional aspects.
In the transformation world, non functional requirements play as equal as functional. At times and in cases, NFRs play larger role. The wishes such as product must be secured, performant, easily customizable, most minimum operational expense etc should be clearly understood & spelt out in the product requirements.
It may happen that the functional piece would be built first, but the team would know about the non functional requirements at the beginning. This would enable the team to build the product in an appropriate way. Some of the non functional aspects would be embedded into the product and some of the NFRs would remain outside to be enablers (monitoring, documentation) for the product to be served to the consumers with high class experience.
Important non functional aspects fuelled by great engineering
Security: This is non-negotiable aspect of the product offering. Consumers need trusted platform to do transactions. For customers breach of security, theft or misuse of personal or financial data is not acceptable. This could lead to multiple severe losses. For an enterprise, it could be a financial loss, damage to reputation, legal battle and could take the business down for the said reasons.
Some examples are as below
- All communication should use TLS
- If using credit card or in the payment domain then the system should be compliant with the PCI-DSS standard
- Specific customer data should be exempted for collection
- Certain data should be encrypted or masked
- Source code and infrastructure should under go periodic security scans and tests.
- Need to comply with any specific standards and regulations like SOX (Finance), HIPAA (Health care) or Telecom etc.
- Comply country, continent specific laws & regulations
Performance: Customers using mobile devices are growing a lot. Consumers expect all the functionality on the mobile app and they expect it a lot faster. Performance is one of the differentiating factors among the competitors. Times are gone when consumers would love seeing the progress bar for a long time 🙂
Product applications when go slow there is a loss of business and same is true otherwise. Faster apps snatch business from other competitors, at times with less features and less colorful UI.
For the same reason performance engineering is gaining a lot of importance in the transformations space.
Performance could be deferred but not to long. You should measure performance from the beginning and measure it on an ongoing basis. Performance optimizations may need change of architecture, way of communication, change is code, change in capacity planning hence it is wiser to pick performance epic as soon as the functional built is done.
You must define the expectation with respect to peak load expected, response time during peak and non pick hours. Response time SLA per feature.
Automated Test and Deploy: Speed to market needs the reduction in ideation to implementation duration. When a new product is getting built or and existing platform is getting transformed, there are lot of moving pieces getting built.
It is essential to have comprehensive test suite to validate the product feature. This test suite should be incrementally enhanced with additional features. Manual testing is time consuming and unreliable, especially in case of transformations. Upon verification, quick feedback is needed so the team can fix issues if any.
Same holds true with deployment. Once the build is ready, it should be able to propagate through different test environments to the production swiftly. Each test environment may have different types of verification/certification. Building up environments should be automated as well. Well verified automated deployment is very necessary as it advances the feature to the production environment very rapidly. Once the deployment pipeline is established, then features can move through it reliably, very frequently and within short span of time.
Documentation: Product documentation should be easy, interactive and up to date. While a feature is getting build, a user story for documentation can be linked with it so that documentation gets done and is not left behind. The release of documentation and the product feature should be at the same time so consumers get consistent experience. For API products, there should self test APIs and demos. Documentation can be generated automatically with the help of templates.
Availability/Up time: Applications are expected to be up and running all the time; regardless of the heavy load during peak seasons and frequency of feature releases. Application downtime or even partial unavailability directly results into the business loss. There are many sad stories of applications going down and horror stories of extended downtime when incorrect measures are taken to recover.
High availability needs to be defined and systems should be built observable to identify failures early and substitute mechanisms should be readily available to deploy. There should be measures to test availability in the lower environments by introducing sudden failures and test resilience of the system.
SLAs are established on quality and availability of the service hence it is important to consider this NFR aspect.
Scalable: System should be scalable on demand. It should be able to scale up and down depending on the need. This would ensure that system is elastic and is consuming only needed resources. There is no need to over-provision the capacity (servers). This not only saves the cost but makes system elastic to meet future demands of growing user base. With this, services can be introduced in different locations, continents with almost no efforts.
Incremental Rollout: There should be provision to do incremental roll-outs. This allows pilot roll-out to few beta customers and validate the functionality with them. Upon success, there can be phased roll-out to other customers and to all customers ultimately. There is also a possibility that depending on the business model, customer can subscribe to only a set of features.
This can provide an opportunity to provide range of customized offering with mix and match of features. Essentially it prevents from potential failures of big bang release approach and a flexible feature offering model.