NFRs for system replacements

An opportunity to revisit what's important

As software architects, we tend to write about non-functional requirements a lot; particularly about how they should be defined and challenged because of the influence they have. One of the reasons for talking about NFRs a lot is that, in the majority, project teams don't give them the attention that they should. And here's a great example that's slightly different from the story where none of the NFRs were defined.

As is the case in most organisations, technology has a limited lifespan. Perhaps the business evolves, the technology becomes harder to maintain, etc. Whatever the reason, many organisations regularly look at replacing their existing systems with solutions that are shinier and more buzzword compliant.

In one of these cases, an organisation put together a 125 page specification for the replacement system detailing exactly what the system should do along with some details of the non-functional requirements. However, out of those 125 pages, only 1 of them featured the NFRs, and they can be summarised as follows.

  1. Performance : the system must be fast.
  2. Scalability : the system must be able to support 100 messages per second.
  3. Availability : the system must be available 24x7.
  4. Security : only certain individuals are permitted to access the system.

Credit where credit is due ... at least some thought was put into the non-functional requirements and conversations to explore those requirements aren't starting from scratch. But on the other hand, those requirements are meaningless!

I want to end this post on a positive note, so let me contrast this story with another replacement project that I've been involved with recently. In this instance, the team *had* thought about the non-functional requirements and had detailed definitions for what they should be. This is excellent, particularly considering that the non-functional requirements surrounding the current implementation are vague in nature. System replacements are an opportunity to revisit what's important, and that includes the non-functional aspects too.

About the author

Simon is an independent consultant specializing in software architecture, and the author of Software Architecture for Developers (a developer-friendly guide to software architecture, technical leadership and the balance with agility). He’s also the creator of the C4 software architecture model and the founder of Structurizr, which is a collection of open source and commercial tooling to help software teams visualise, document and explore their software architecture.

You can find Simon on Twitter at @simonbrown ... see for information about his speaking schedule, videos from past conferences and software architecture training.

Add a comment Send a TrackBack