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 100 high-level requirements. In SARM we call these scenarios, in order that they are clearly differentiated from the more detailed requirements that will be needed for implementation. The limitation of 100 is deliberate – if you think you need more, then you are probably working at a level of too much detail. 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 scenarios, 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 scenarios that have been captured so far, and identify which sub-characteristic is the dominant one reflected in each scenario. The facilitator can then go back through the complete list of sub-characteristics, and identify any that are absent from the scenarios. 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 scenario, perhaps simply assuming that it will be taken on board by the project team later. The participants should be invited to create an additional scenario that reflects the significance of that sub-characteristic, adding to the original list of scenarios. By the time that you have gone through the list of sub-characteristics, you may find that the number of scenarios 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 scenarios 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 ‘Scenarios & Stakeholders’ 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 scenarios as they are documented on paper.
At this point, the workshop has identified a set of scenarios that have been classified according to the quality model, and the participants are happy that all of the significant characteristics are represented among the scenarios, 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 scenario and assign an impact value.
The Impact represents the impact in the event that the solution finally implemented fails to satisfactorily achieve a given scenario. Participants are invited to discuss and agree a value from among Negligible, Minor, Moderate, Major and Catastrophic. This is one of the two dimensions of the SARM Risk Model – you can read more about this here.