The previous three activities, often all completed in a single substantial workshop involving quite a large number of participants, have created up to 100 architecturally significant requirements (ASRs), 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 ASRs by stakeholders, which could have up to 1,500 cells, this is not an easy question to answer. The next tab in the spreadsheet tool, ‘Stakeholder Views’, is intended to help the team do just that. 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 3 shows how many requirements there are classified under each quality characteristic, and how many there are altogether (63 in this example). 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 requirements that have been classified under that quality characteristic. In this case, this is true, for example, of the Product A team with respect to the Usability, Reliability and Efficiency quality characteristics. Strong Interest has double the weight of just Interest, so a stakeholder who is just interested in all requirements of a quality characteristic will have a relationship score of 0.50. If the stakeholder has no interest in any of the relevant requirements, 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 (as we see in this example with the product teams). Whereas operations might be most interested in security, reliability, efficiency and sustainability (as we see with IT here, 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 requirements, 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 requirements, 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. In this example, we can see that this is a set of requirements oriented towards the needs of product departments, and not their customers.
A filter, that is set in the Tradeoff Analysis tab, allows the user to adjust this ‘heat map’ so that it only considers requirements 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) requirements, compared with the entire set of requirements.