The analysis of the customer’s needs and their translation into requirements that breaks down into 2 main stages:
1. Prioritize the needs of the actors of the system by defining beforehand, in close interaction with the leaders of the project of evolution of the system concerned, explicit criteria of value and risk, to bring out the highest priorities that are appropriate to consider,
2. Decline the needs into system requirements by first formalizing the functional and technical requirements of the system by adhering to a standard requirements statement framework, then organizing them into hierarchies of functional requirements and technical requirements by guaranteeing their traceability with the needs.
The architect defines a list of prioritized needs in order to maximize the value/risk ratio of the system. It is the basis of a hierarchy of needs in functional and technical requirements, which is accompanied by the maintenance of both internal and external traceability according to needs
Among the main pitfalls:
- Operate in all or nothing mode without prioritization of values and without any hindsight,
- Wanting to go too far in writing and breaking down requirements. System architecture is then perceived as a long, laborious process without added value,
- Cover the field of stakeholders without going to consult them,
- The absence of a decision maker who bears the responsibility of deciding the value. It is not the role of the system architect to do this alone.
Here are some good practices to consider:
- Train teams and communicate at the start of each project on the pragmatic nature of the deployment of architecture methods and the search for value.
- Include assisted “tayloring” in the architecture process by allowing projects to adapt the approach in a guided manner to their contexts. It is interesting, for example, to distinguish the type of architectural work “we start from a blank sheet” from that which rather aims to modify an existing one. This tailoring must be accompanied by the implementation of a set of criteria (e.g. reuse, innovation, level of complexity, impact on the existing architecture, maturity of the teams, customers, organization, etc.).
- Have a pool of experienced architects (both on the method and business aspects) who support the teams. This requires the implementation of constructed pathways, based on an assessment of the profile and appetites and which progressively increases professional knowledge (e.g. immersion course in the professions). It is therefore necessary to clearly identify which are the most critical professions. Above all, a strong HR policy is needed.
We have compiled here several verbatim statements from project managers or system architects from different companies, which echo this phase:
“ We put time constraints in place to complete the black box architecture, which naturally forced the teams to adapt the level of details of the deliverables.
“Taking the time to communicate on the “success stories” by choosing examples that speak to everyone was a real plus.
“We organized decision-making committees to refine the risk/value analysis.
Your comments will be considered by the members of the Cercle at the next monthly meeting.