Before you get too excited, you should know it’s easier to write these for quantitatively measurable qualities (e.g., throughput, latency) and harder for softer qualities (e.g., modifiability, usability).There are two recent books that have a more agile approach to architecting: Lean Software Architecture by Coplien and Bjørnvig, and George Fairbanks' Just Enough Software Architecture: A Risk-Driven Approach. Unfortunately the latter isn't available in any Swedish internet bookstore, but as soon as I get hold of them I will post a review, as I have reviewed other books on software architecture.
28 October 2010
Quality attribute scenarios
Defining a quality attribute, a.k.a. non-functional requirement, is not easy. I know since i did that for a new platform at Volvo. When the verification and validation group comes back and says that it is not possible to verify this as a requirement I can only assume that I did not do a good enough job. But I have to agree with what George Fairbanks wrote in his blog:
Subscribe to:
Post Comments (Atom)
2 comments:
I'm not sure you "did not do a good enough job."
Many non-functional characteristics can't be expressed at all in quantitative form.
And many can be quantified, but in the process, a lot of valuable information will be lost.
So I think you should tell the testers that you are aware that they can't be verified, but ask if they can test with your writing as a guideline.
I'm a software tester myself, and would love to have vague, qualitative requirement (as an appendix?) that make it faster for me to understand what is important about the software.
I completely agree about the value of quality attribute scenarios as means to better understand the system to be verified.
What I aimed for in this project was quality attributes that we could say was fulfilled or not (i.e. something better than just saying the product should be safe or easy to use). My personal conclusion was that I succeeded in that , but it was impossible to verify just based on looking at the architecture (models and description). For many quality attribute scenarios the actual implementation was necessary. So the task of verifying the architecture could not be done when it was requested by the project manager, i.e. long before code was delivered (automotive industry = stage-gate development process, but that's another topic).
Post a Comment