This activity aims to define the uses of the system. This can be done in 2 steps:
1. We first synthesize all the life phases of the complex system in a life cycle diagram,
2. We then identify the possible use cases of the system, associated with the different life phases, then we describe their dynamics using operational scenarios. We introduce the concept of exchange flow, which is very important. This highlights the expected behaviors of the system, seen by the stakeholders, in each of the use cases described.
The architect performs both static and dynamic analysis of the black box of his system of interest in order to define how the complex system is used by its stakeholders and the behaviors it must achieve as seen by stakeholders.
Among the main pitfalls:
- Seek to go too far in the analysis (aim for the impossible exhaustiveness) instead of focusing on the essential use cases,
- Focus on use cases where teams are ultimately most comfortable (core business),
- Forget dysfunctional use cases (i.e. only deal with nominal cases) or also detail them too much (at the risk of drowning out the cases that carry the most value).
Here are some good practices to consider:
- Choose a tool adapted to the semantics of the stakeholders and the maturity of the project phase,
- Aim for completeness in the list of use cases and interactions but only describe in the form of scenarios the use cases identified as “essential” according to value criteria (from a customer point of view) versus risks (in-house),
- Agree with stakeholders on the scope of responsibility for dysfunctional use cases deemed “essential”,
- Time-boxing and reflection on the overall coherence of the architecture through an iterative practice,
- Sort & factorize the scenarios according to the expected behaviors of the system.
We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:
“ We classify use cases into 4 categories:
• high value and low risk: we take care not to dwell on them because they are well known and mastered,
• low value and low risk: there may be a discussion with the customer but we do not go into the details of these use cases,
• high value and high risk: this is where we or our clients are least comfortable, but it is precisely where we must put the effort,
• low value and high risk: the objective is to negotiate or challenge the associated customer needs
“ We apply the principles of frugality (voluntary limitation of the time allocated to the activity compared to the estimated time) to stimulate productivity: this forces us to go naturally to the essentials,
“ We produced comic strips to help the client clearly visualize the proposed uses for certain scenarios.
Your comments will be considered by the members of the Cercle at the next monthly meeting.