Note that all blogs have been migrated to georgefairbanks.com.

Dilbert on quality attributes, and what you should know about quality attribute scenarios

Feb 14, 2010 | George Fairbanks

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.

Quality Attribute Scenarios

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):

Quality Attribute Scenario Parts

• Source: Who/what initiates the scenario
• Stimulus: The event that initiates the scenario
• Environment: The system or environmental conditions (e.g., normal operations, shutting down)
• Artifact: Which part of system, or whole, is involved
• Response: What noticeable event happens as a result of stimulus
• Response Measure: Quantifiable, testable measurement

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)

Evaluation

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

References

• The SEI book on architecture that covers QA scenarios in detail: Software Architecture in Practice (2nd Edition) by Len Bass, Paul Clements, and Rick Kazman
• My book covers them too: Just Enough Software Architecture