Yes, embedding a Dilbert cartoon is just too easy – but it provides a memorable lesson about why quality attributes, by themselves, are not as good as quality attribute scenarios. Before I bore you, the cartoon:
Perhaps it is important for your system to have security. We could all guess what that means, but we’d all likely guess slightly different things. I might guess it means that bad guys could not retrieve info. You might guess it means bad guys could not alter info. And someone else might point out that there is no currently known way to allow good guys to retrieve and alter info without a dedicated bad guy having some chance of access.
If you are asked to make “high performance” software, work with the stakeholders to turn that into a testable quality attribute scenario, like this:
The system should service 1000 simultaneous users with a response rate less than a second.
Even when you are being careful, it is easy to leave ambiguity. The Software Engineering Institute (SEI) suggests the following template for writing quality attribute scenarios (and they were the inventors of them):
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)
It is certainly easier and faster to just say the system should be “high performance” or “secure”, and if you have easy access to your stakeholders or customers then it is often best to just ask them what they mean and help them to understand any ambiguities you see.
By writing (or talking about) quality attribute scenarios instead of just quality attributes, you are more likely to reduce ambiguity and ensure testability
subscribe via RSS