One strength I saw in the ATAM was identifying the need for relationships between the quality attribute requirements in a project. The book explains this as a Utility Tree, saying that requirements can be classified as a hierarchy (based on a “problem being solved” link). Given that they have worked on more real projects, I would guess that they have experience with what needs to be modeled.

However, I don’t really think a simple tree is sufficient. Certain quality attributes could be diametrically opposed, and a basic graphical display of that would be useful. Maybe a tree to represent “composition of requirement classifications” and an additional (directed?) graph to represent additional architecture-driving relationships. If it could be seen that one “set” of requirements was directly associated with a number of other sets of requirements, it would make sense, then that the focal point of requirements would be the focal point of architecture.

One complaint I have about the CBAM is their mis-use of transfer functions in the Utility-Response curves. They describe evaluation of a quality attribute on a single scale, using four points of reference:

  • worst-case condition – the system will not be usable or marketable below this point
  • best-case condition – the system will not be noticably better if improved past this point
  • current condition – the system, as implemented now, is at some range between worst-case and best-case conditions.
  • target condition – the system, if implemented in terms of the given requirements or a new requirement, will be at this point between the current and best-case conditions.

So where does the transfer function come in? It doesn’t, really. It looks to be just a pretty graph to impress the PHBs. The graphical transfer functions could be done away with, and replaced with tabular data without loss of clarity.