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:

Dilbert.com

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

About

George Fairbanks is a software developer, designer, and architect living in New York city

Contact

gf-web@georgefairbanks.com
124 W 60th St #37L
New York, NY 10023
+1-303-834-7760 (Recruiters: Please do not call)
Twitter: @GHFairbanks