Architecture Reviews, Requirements and Quality Attributes
The ONS architecture review method has been in use for a couple of years, and while it hasn’t worked flawlessly, it does seem to they way we think at ONS better than ATAM. I presented a paper that describes the method, and the differences from ATAM at the UNECE MSIS conference in Oslo in May this year (you can see both the paper and the presentation here).
I’ve been looking more closely at models of quality attributes, and suspect that the ONS method could come a bit closer to ATAM that we originally thought. ISO/IEC 9126-1 contains a very nice model of quality attributes (pretty good summary here), which it more correctly calls characteristics. It is hierarchical, with just six main characteristics (functionality, reliability, usability, efficiency, maintainability and portability), which are further subdivided into a total of 27 sub-characteristics.
The ONS method makes the connection between quality attributes and requirements via Matrix 1, but the connection is too weak. Recent architecture reviews have proved somewhat unsatisfactory, and I suspect that the root cause is incomplete and poorly specified requirements. By the time you get to the review, no method is going to rescue that situation unless you avoid all references to the requirements and do the risk / trade-off analysis directly against the quality attributes – but then there is the danger that the evaluation criteria are effectively based on a different set of requirements than those created through business analysis, and on which the solution options were based.
So, how to improve the quality of the requirements? I suggest that the quality attributes need to have a much stronger influence on the requirements – influencing the people describing the requirements, and the analysts looking for them (if no-one mentions maintainability during business analyst interviews, it is hardly surprising if it is not among the requirements).
Perhaps this is just the traditional complaint of the architect – “don’t ignore the NFRs” – but I think we should look for a much tighter linkage between requirements and ISO 9126-1, and perhaps develop the stakeholder model around the quality attribute model so that it is quite clear that those who have to run, manage and maintain the system, and those determining corporate strategy, are just as likely to have requirements of the system, as those who are going to use it.
Maybe then, when we reach the architecture review, we will have a set of requirements that is better aligned to the key quality attributes, and the review can be better focused on risks and trade-offs.
Leave a Reply