Capturing the needs of internal/external customers and consolidating them is an activity that breaks down into 3 stages:
1. identify and organize the stakeholders of the system in the form of hierarchical diagram(s) and an environment diagram which specifies the interfaces/interactions of these stakeholders with the system considered,
2. frame the request of the stakeholders of the system by seizing the objective which motivates the development of the given system, and by succinctly describing the operational, functional and technical scope of the target system and the main performance indicators to be achieved,
3. capture the needs of the stakeholders in the system by starting by capturing the “raw” needs of the stakeholders, as expressed by the latter, from the available sources of information (interviews, documents, etc.), then by formalizing these raw needs using a standard statement of needs framework and finally prioritization of formalized needs.
The architect identifies the external perimeter to be taken into account and specifies the missions of the system as well as the objectives to be achieved. It formalizes and prioritizes all the needs of the stakeholders by guaranteeing their unambiguity and their exhaustiveness.
Among the main pitfalls:
• Organizational issues may arise when the capture of needs carried out by the architect comes into conflict with the business activities (BU or Business Analyst),
• Wanting to go too far in modeling the environment. To avoid this, one must constantly think in terms of value and therefore see what has a substantial impact on the interest system. Knowing the company’s business processes makes it possible to better assess the value,
• Not consulting the stakeholders of certain life phases (development, maintenance, etc.),
• The main stakeholders are not aligned on the defined perimeter of the system (this often happens because we do not take the time to make this effort).
Here are some good practices to consider:
- Do not let the organizational aspect become the main driving force behind defining the scope. This avoids biasing the choice of architecture at this stage,
- Make the value understood: the architect brings an aspect of risk and value analysis to where business analysts focus on coverage and consistency. One can proceed either by a sharing of pains (analysis of irritants, problems, anything that prevents objectives from being achieved) or by a demonstration of the contribution of a methodology,
- Ensure the good level of knowledge of the stakeholders involved in the validation of the use cases and the good level of responsibility (in the decision-making sense) vis-à-vis the potential impacts. This is true for all architectural activities,
- Do not slow people down in expressing their needs: if they express solutions instead, they should be noted and escalated as needed (5 Whys method, for example),
- Care must be taken to integrate the constraints/expectations of the security and cybersecurity teams…
We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:
“ We challenged the existing deliverables by the teams. This naturally led to the emergence of the need to set up a new methodology for capturing needs, which we did by supporting employees through training.
“ We make very short loops between black box and white box in order to highlight the implications of the needs on the constraints induced in the architecture.
“ We prepare the two black box and white box visions, and we put the elements that are more in the order of the possible solution in the white box part before going back up if necessary.
Your comments will be considered by the members of the Cercle at the next monthly meeting.