Engaging without non-functional requirements

Neither party will win

In The influence of non-functional requirements, I wrote that putting together a ballpark cost for a software project is near impossible if you don't have any information about the non-functional requirements. Something I've witnessed recently is a situation where two organisations are engaged with each other on a software project with no understanding of the non-functional requirements.

In one case an organisation purchased an off-the-shelf product and another was a bespoke build. With the latter, the organisation in question needed a software project delivered and had a fairly good idea of exactly what they wanted, engaging a third party to bid for the work. To ensure that everybody had a mutual understanding of the problem, an initial scoping exercise took place, during which the third party was able to understand more about the business domain, clarify some of the ambiguities and put some initial thoughts around the architecture and design of the system.

Having seen some of the output from the initial scoping phase, it's clear that the bidding party had a good understanding of what the system should do and had even started identifying candidate technologies for the delivery phase. The thing they hadn't done, however, was to get to grips with the key non-functional requirements. Details on performance, scalability, availability, etc were all absent. From my experience of the business domain, I know and feel confident in saying that the non-functional requirements will make or break this particular system. Not having them specified is a lose-lose for both parties involved.

  • Buyer : Without specifying their non-functional requirements, the buyer leaves themselves open (contractually) when the software functions but doesn't perform/scale/etc as expected. This isn't good for their business and, ultimately, they don't get what they want and expect at the cost they were quoted.
  • Bidder : Not asking about the non-functional requirements raises doubts about their experience, capability and understanding of the problem domain. Also, how much risk is the bidder exposing themselves to by commencing without these key details?

My advice is simple. If you're going to engage on a software project, regardless of whether you're using an internal or external team (particularly if using a fixed price model), you simply *must* define the key non-functional requirements as early as possible. Failure to do so will mean neither party will win.

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 simonbrown.je for information about his speaking schedule, videos from past conferences and software architecture training.

Re: Engaging without non-functional requirements

Being bloodied with NFRs at the moment, I would go as far as to say that if you don't know what the NFRs are for your system, you haven't done your job properly.

For me, the real pain with NFRs is that the customer does have a set, even if they don't realise it, and that set is usually:

"The system will respond instantly and will scale to as many users as we choose to put on it. Oh, and it won't loose a single byte of data even in the event of a nuclear strike".

As an architect, your job is to adjust this to a more reasonable set. Doing so is painful, but is a lot better than doing so after you have built the system....


Re: Engaging without non-functional requirements

I couldn't agree more - you've not done your job if you don't have the NFRs sorted out.

Re: Engaging without non-functional requirements

Oh, as an aside, this is why we recommend a BA/TA team whenever a new software system needs to be scoped. You need to cover all angles.

Re: Engaging without non-functional requirements

The system is set to doom if NFR's are not taken care of.

Re: Engaging without non-functional requirements

I agree ... and I wish that more software teams would proactively think about the NFRs before they started writing code.

Re: Engaging without non-functional requirements

Documenting NFRs is also crucial. Usually they are included in Architecture document or requirements document. However, in projects which use little or no documentation, passing on this information to the developers is a real challenge particularly in the application maintenance phase.

Add a comment Send a TrackBack