Feature Driven Development

Hi,

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.

Jeff