Deriving and Documenting Nonfunctional Requirements

Hello Jeff:

I have proposed the use of FDD approach for a project in my current organization. Moving from a traditional requirements development process I will appreciate if you can provide some details on the Non Functional requirements development process using FDD.


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Jeff De Luca's picture

A Contractual Issue


I see non-functional requirements as a contractual issue and they should be addressed at that stage. Non-functionals are things like usability, performance, reliability, and so on. Thus in the contract - the statement of work - in the acceptance criteria section it must be spelt out and agreed how the non-functionals are defined (a crisp, clear, agreed definition) and then how they will be measured. e.g. what does "usability" mean? and then how do we agree to measure it?

Remember, the acceptance criteria is the clients to write and yours to agree. So, let's use a simpler example - performance. You need to have the discussion with the client to get a crisp, clear definition of what is meant by performance. They might say an end-user response time of less than 2 seconds. Ok, so then you have the discussion with them about how that is going to be measured.

Most apps these days are web apps of some sort (browser delivery) and integrate with some form or number of backend systems. So, you have a discussion along the lines of "well when you instrument the system such that we isolate the load of other apps on the backend, the network load and latencies, the version of the JVM (assuming java), the render times in the browser (which can vary greatly even from one version of IE to the next) and so on. If you can instrument all that out, then sure we can agree a sub two second path through our PD layer."

The point of all this is to get them and yourselves back to a position of reasonableness. Because for line-of-business style development that's what is needed. Of course if this is safety critical software or man-rated software then what I'm saying does not apply and such instrumentation requirements, amongst other concerns, are veyr likely to be apppropriate.

At the end of the day, measurement of non-functionals is a risk to you if you don't get the client to a position of reasonableness in understanding the issues to do with non-functionals, and then reflect that common understanding with language that works for both of you in the contract. If you don't, you are leaving yourself open to all sorts of potential non-acceptance claims if someone decides they want to be difficult (or silly).

Now, how do non-functionals affect a construction project? Mostly, they affect the architecture. e.g. if there are important non-functionals in the RAS area (reliability, availability, serviceability) then you're going to need a consistent logging/tracing strategy and implementation across the codebase, then for either archiving or wrapping the log files, then how they will be accessed and diagnosed, etc. etc.

If there is a significant amount of this need, then you use that knowledge in your estimating. You still use a client-valued PD features list but you understand that many (or all?) features have to also implement the logging. This work is amortised across the features.

That's a rushed reply but if you can't follow any of it please ask again.


Fixed scopes?

Sometimes (within the SMB market and/or within the context of new/innovative technologies) the NFR-s are informal and spanned thru the lifecycle of the project. This could be due to the lack of time or due to the lack of experienced IT staff/knowhow at the customer side or even due to the lack of experience at the developer side.

In such cases we start from informal NFR-s. Then based on these and money the infrastructure software/technology (RDBMS, J2EE, portal, CMS, etc.) is selected. Finally we hope that the customer won't require such NFR-s that the platform doesn't support:)

This may be a bad practise but is there a better one? In other words can we always require definitive NFR-s? Should we drop such projects where this is impossible?

BTW. there's an interesting arcticle about project scoping in Martin Fowler's bliki: ScopeLimbering