SARM 9.0 introduces some changes in terminology to the process and activities, but the core capabilties of the resulting trade-off analyis remain unchanged. This article explains the changes that have been made, and the reasons for those changes.
Changing the default terminology
Until now, we ‘ve followed ATAM in calling the high-level requirements used in SARM Scenarios. This has not always been easy to explain to stakeholders, as it can get confused with the concept of a scenario describing an entire set of circumstances (as it does in Scenario planning, for example) rather than just a specific requirement. The simple term “requirement” is also not entirely satisfactory, as it has strong association for business analysts with detailed requirements and use cases.
IASA has adopted the term Architecturally Significant Requirement or ASR, and their definition, which goes beyond just thinking about “non-functional requirements”, aligns well to the SARM approach. So by default SARM is adopting this term, using Requirement as a short-hand for “Architecturally Significant Requirement”.
With the removal of the stakeholder model (more on that later), we wanted to underline that the tool works just as well with, or without, stakeholder perspectives. So we’ve renamed the worksheet where the requirements are specified and classified according to the quality model Context, which is exactly what is done in this worksheet – creating the context for the analysis.
What was previously called Solution – Scenario Risks is now simply Solution Risks. And the old Sub-characteristics worksheet is now called Tradeoff Details.
Injecting your own terminology
Whilst it has always been possible to change the quality model, the terminology used to describe it (Characteristic, Sub-characteristic and now Requirement) has been hard-wired into the various worksheets. SARM 9.0 introduces the ability to change this, and have it reflected in the all the worksheets that previously referred to “Characteristics”, “Sub-characteristics” and “Scenarios”. Cells B34 to B37 now allow you to set your own terminlogy for what by default are called Characteristic, Sub-characteristic, Requirement and Impact. So if, for example, you want to set up SARM to adopt the language and model of the Perspective Based Architecture Method (PBAM), then you can change these terms to Zone, Area of Concern, Question and Impact.
Removing the stakeholder model
There was always an attractive symmetry to SARM’s use of a stakeholder model. Just as requirements are grouped and abstracted to a manageable number with the quality model, so stakehoders are similarly abstracted via a stakeholder model.
So why get rid of the stakeholder model, as we have done in SARM 9.0?
Abstraction with the quality model really does help you to “see the wood for the trees”. As soon as you have more than 20 requirements, it becomes impossible to see in once glance where the tradeoffs and conflicts are. The quality model shows it clearly, telling you where you need to drill down to the detail to understand what is going on. And you might be dealing with 100 such requirements, so having them reduced to just 8 or fewer quality characteristics, with an intermediate view by sub-characteristic, is incredibly useful.
The same is not true of the way SARM shows stakeholder perspectives. SARM limits this to 15 stakeholders at the most, because of the necessary effort needed to link each stakeholder to the requirements they care about. A project may have many more than 15 stakeholders, and classifying them in a model is worthwhile. But for SARM, we only want to look at the 15 or fewer most significant stakeholders, and we really want to see each individual perspective. So there is no real benefit in classifying them in a model within the SARM tool.
The result is a simpler SARM without the loss of any functionality. No need to enter stakeholder attributes in a Stakeholder Analyis worksheet. Just add stakeholder names to column headers in the Context worksheet if you want to include stakeholder perspectives in your analysis. If not, leave them blank and move on. And the Tradeoff Analysis worksheet is now 12 rows lighter!
Please do continue to use the Mitchell, Agle and Wood model when looking at stakeholders in your projects. We’ve kept the guidance on this here, but you are no longer forced to use it with SARM, so if you prefer another approach to stakeholder analysis, that’s fine too.
Tell us what you think
The changes introduced here to SARM have been prompted by user feedback. If you have your own suggestions, or if you do or don’t like some of the changes we’ve made recently, please do get in touch.