This activity typically takes place in a substantial workshop, ideally a collaborative one involving representatives from many of the key stakeholder groups. When considering invitees, look carefully among those that have Urgency – they will have strong views on what they want out of a solution, even those that lack Legitimacy – this might be your chance to ‘bring them into the fold’.
The aim of this activity is to articulate up to 200 high-level architecturally significant requirements (ASRs). Whilst many architects associate these with “non-functional requirements” and “non-functional quality attributes” you should also think about requirements that relate to functionality but are critical to the success or failure of the solution and also constraints. Some models, such as the one in PBAM, go further and include the wider IT and business environments and trends among the areas of concern you should consider. See here for further information on ASRs. The limitation of 200 is deliberate – if you think you need more, then you are probably working at a level of too much detail (indeed we recommend that you try to aim for no more than 100). The workshop will need a facilitator, and it works well if it begins with an invitation to participants to describe ‘what a good solution would look like’. Responses can be turned into ASRs, described with one or two sentences, and written up on flip-chart paper.
Once the number of new ideas has begun to dry up, it can help to turn to the Quality Model, perhaps distributing a sheet to participants that describes the quality characteristics and sub-characteristics of the model (you might find this example sheet useful). The participants can now review the ASRs that have been captured so far, and identify which sub-characteristic is the dominant one reflected in each ASR. The facilitator can then go back through the complete list of sub-characteristics, and identify any that are absent from the ASRs. Ask the question:
Is this sub-characteristic important to our solution, or is it not relevant?
If the former, then the group has missed out an important ASR, perhaps simply assuming that it will be taken on board by the project team later. The participants should be invited to create an additional ASR that reflects the significance of that sub-characteristic, adding to the original list of ASRs. By the time that you have gone through the list of sub-characteristics, you may find that the number of ASRs has now doubled. And you can be pretty confident that you’ve together explored the solution “in the round”, from many different perspectives.
It is quite common for the early ASRs to focus around the visible functional characteristics of the solution, leaving out the less obvious “non-functional” characteristics, such as Security, Reliability and Efficiency. SARM’s default quality model is a simple one, but you can choose to adopt an alternative one, such as ISO 25010, if you are licensed to use it. See here for some guidance on how to change the quality model in the spreadsheet tool.
Whilst you will eventually need to put the outcome of the workshop into the spreadsheet tool (the ‘Context’ tab), it is suggested that the workshop should focus on using flip-charts or whiteboards, rather than watching someone enter data into a spreadsheet via a projector. But you can save time if you have someone in the room who can sit in the corner and enter and classify the ASRs as they are documented on paper.
At this point, the workshop has identified a set of ASRs that have been classified according to the quality model, and the participants are happy that all of the significant characteristics are represented among the ASRs, the whole amounting to a good description of ‘what a good solution would look like’. The final task for the participants is to revisit every ASR and assign an impact value.
The Impact represents the impact in the event that the solution finally implemented fails to satisfactorily achieve a given ASR. Participants are invited to discuss and agree a value from among the Impact descriptions in the Risk Table. This is one of the two dimensions of the SARM Risk Model – you can read more about this here.