Software Best Practices

Nick, I agree, it is a bad idea to force requirements out of somebody. There is a very high probability that those "requirements" will change. The fun part of being a requirements analyst is to create a way to have the customer think through their problem enough to discover their own requirements along side you. That is one of the reasons prototyping and incremental development can be handy here.

Beside those, the only other real techniques I have for non-functional requirements are fit criteria and task analysis. Maybe gist, maybe just asking "do you need to be concerned about X" where X is some generic non-functional category. I was just wondering if there were something more.

FYI, Steve McConnell's latest book is Software Estimation, Demystifying the Black Art and it does contain the statistics you mention.

WOW. This IS interesting. I was recently hired into the architecture group of the company I am working for now. This was my first problem, and I had to think long and hard about it.

Six Sigma is defect based, and describes any defect as "anything that would lead to customer dissatisfaction"

We expanded it to three areas of quality:

Quality of Conformance (does the system function in the way we understand the requirements?)

Quality of Features ( do the features make sense?)

Lack of Defects (crashing etc)

This is working so far. Thanks!