“But the user didn’t specify that requirement…”

screen showing code

Top non-functional considerations for software developments – Part 1

Tier 2 Consulting helps organisations create custom software for web, mobile and enterprise applications – often including integration with 3rd party products and services.

For custom software development, the functional requirements should, in the main, be driven by customer needs and objectives. But there will be requirements that as professional software developers we should throw into the mix as well. We can’t expect users to specify absolutely everything.

This post focusses on non-functional requirements (NFRs). Quite simply, NFRs govern the quality of your platform; they define how well it will exhibit behaviour and also provide benefits in many areas, such as security, reliability, user experience and maintainability. Done right, they can significantly reduce overall total cost of ownership of the solution.

In this article, Paul Thorp, Tier 2’s Software Development Manager, lists his top NFR considerations for custom development projects:

Security

Web applications should conform to OWASP Top 10 guidelines for mitigating the most critical application security risks.

In an era in which information security is becoming increasingly important, we should ask whether simple authentication (e.g. username / password) is sufficient, or if enhanced levels – such as 2-factor authentication (2FA) – are required.

Web User Interfaces

Web applications should be designed and tested to work in all supported versions of major browsers

Web applications should be built with a responsive design, and adapt to differing resolutions – desktop / tablet / phone

Web applications should conform to the W3C accessibility guidelines

Web applications should handle errors in an appropriate manner and broadcast messages accordingly to inform the user

Design Considerations

Sensitive strings in configuration files should be obfuscated e.g. database passwords

Web applications should ideally be as stateless as possible: where state is required and data is stored in the session, it should always be serializable to support http session replication if required

Integrations should be designed for maximum deployment flexibility e.g. one integration per bundle, ability to deploy multiple versions etc.

Configuration and internationalisation should be done outside the application

Environment-specific configuration should be stored with source code

Applications should allow for multiple simultaneous deployments to support potential clustering / containerisation – so that means no singletons or local storage (caching / id generation / indexing etc.)

Applications should allow for simultaneous deployments of different versions to support A/B, Blue/Green and Canary deployment strategies

Deployment Considerations

Applications should allow for multiple simultaneous deployments to support potential clustering / containerisation – so that means no singletons or local storage (caching / id generation / indexing etc.)

Applications should allow for simultaneous deployments of different versions to support A/B, Blue/Green and Canary deployment strategies

Application deployment platforms should be compatible with standard web frontends / load balancers e.g. Apache, NGINX, F5 etc.

Application deployment platforms should be compatible with standard monitoring tools/frameworks (e.g. JMX)

If you have any further queries in regards to NFR’s Paul and the Tier 2 team are always happy to help. Contact us today for answers to all of your software development queries.