The previous three activities, often all completed in a single substantial workshop involving quite a large number of participants, have created up to 100 scenarios, agreed a level of impact for each one, and determined the extent to which up to 15 stakeholders are interested in them. At the end of all this, it would be reasonable to ask the question: Have we got this right?
Given the potential size of the matrix of scenarios by stakeholders, which could have up to 1,500 cells, this is not an easy question to ask. The next tab in the spreadsheet tool, ‘Stakeholder Views’, is intended to help the team answer that question. If the previous activity was completed in the workshop, then reviewing this tab could be the closing activity of the workshop. Alternatively, it might be more appropriate for this question to be addressed by the designer / architect in a separate meeting with the project sponsor.
The image below shows how this tab might look after completing the first three activities in Part 1 of the SARM process:
It is a colour map, where the strength of the colour reflects the strength of the association between a stakeholder (each stakeholder occupies a row in the table) and a quality characteristic in the Quality Model. Row 2 shows how many scenarios there are classified under each quality characteristic, and how many there are altogether (21 in this example). The last two columns show the latency and stakeholder model class to which each stakeholder belongs. The numeric values in the table give a more precise measure of the strength of the relationship, on a scale of 0.00 to 1.00. For a cell to contain a value of 1.00, that stakeholder must be strongly interested in all of the scenarios that have been classified under that quality characteristic. In this case, this is true, for example, of Stakeholder One with respect to the Reliability and Efficiency quality characteristics. Strong Interest has double the weight of just Interest, so a stakeholder who is just interested in all scenarios of a quality characteristic will have a relationship score of 0.50. If the stakeholder has no interest in any of the relevant scenarios, the score will be 0.00.
The table can be read in a number of different ways, each useful in establishing that Part 1 has produced a coherent and complete view of the high-level requirements. Reading across the table, row by row, allows the user to see which quality characteristics are of the greatest and least importance to each stakeholder. Reading vertically from the first column to the last, the user can see which stakeholders are most, or least interested in each quality characteristic. One might expect, for example, for end user stakeholders to be most interested in functionality and usability. Management might have a strong interest in efficiency, while operations might be most interested in security, reliability and sustainability (since they have to keep the system or service in operation safely and reliably). The architect / designer can review this and consider whether the outcome as shown in this table is as he or she might expect. If not, it might suggest that there are either missing scenarios, or that there is a misalignment of project priorities.
Columns J and K show the overall level of interest each stakeholder has across the entire set of scenarios, by strength and their position in the rank order of interest (from first to last) respectively. So it is easy to see which stakeholders are most and least interested overall in the system or service. You would expect to see an alignment between this and the most important stakeholders, with Definitive stakeholders appearing high in the ranking.
A filter, that is set in the Tradeoff Analysis tab, allows the user to adjust this ‘heat map’ so that it only considers scenarios with levels of impact above a specified level. This can be used to test the sensitivity of the information captured when looking at only the most significant (impactful) scenarios, compared with the entire set of scenarios.