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 lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, helping teams to build better software. His client list spans over 20 countries and includes organisations ranging from small technology startups through to global household names. Simon is an award-winning speaker and the author of Software Architecture for Developers - a developer-friendly guide to software architecture, technical leadership and the balance with agility. He still codes too. You can tweet Simon at @simonbrown.

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.