Non-functional means it doesn't work!
Architects are usually quite pre-occupied with ensuring that architectural guidelines and requirements are adhered to during development yet, always struggle to justify them. One of the many attempts made by architects to provide these guidelines is the software architecture document. Simon Brown blogs about another attempt that is probably doomed. Just looking at the document structure, the non-functional view is 4-5 times larger than the functional view.
What does the customer think non-functional requirements mean? No, it's not just semantics. I vividly recall an RFP-response drafting session I was a part of, many years ago. This was the first time I had participated in a fairly large team responding to a multi-billion dollar opportunity. I had finished up one sub-section, and handed it over to my boss. Without raising his head, he took the doc and with his red pen, crossed out every single instance of "non-functional" and handed back the draft to me and said, "The customer doesn't want to pay for something that doesn't work."
Of course, in geek-speak, functional and non-functional have a very specific meaning. In standard, workaday English, functional means something works and non-functional means something doesn't work or is broken. Why then, do we architects pay so much attention to designing software that doesn't work?
If we want all of those architectural "ilities" to be accounted for and truly guide the design/construction of systems, we need to immediately start doing 2 things:
1) Start calling them technical requirements and/or constraints.
2) Directly map them to functional requirements by defining the operational characteristics the customer wants each feature to provide.
Every, single functional requirement should explicitly be able to describe just how much of each "ility" needs to be built, thereby preventing over/under-engineering. This embeds the success measurement criteria for every, single feature!
Maybe we need to start talking about measurement driven requirements (MDR)?
Posts
3 comments:
Good luck getting that to happen. We tried that with the IIBA's BABOK and the resistance from the technical community to adopting any other term forced us to give up. To be honest I agree with you, but non-functional is just too deeply ingrained as a term.
I'm under no illusion that non-technical people understand "non-functional requirements", system qualities, etc. They don't, and furthermore, getting them to *define* those is almost impossible in many cases. But that's one problem. I'm trying to tackle the other (easier?) problem of when technical people don't even think about NFRs. First things first, we need technical people to understand why NFRs are important. Then, once they appreciate this, they can help the non-technical people define them. That's the theory anyway! :-)
Eloquent name for "non-functional" is quality attributes. I consistently use that terminology with my clients and build their understanding by creating scenarios that demonstrate how a system should perform.
Post a Comment