{"id":25506,"date":"2021-07-04T10:34:13","date_gmt":"2021-07-04T08:34:13","guid":{"rendered":"https:\/\/cesam.community\/?p=25506"},"modified":"2023-01-20T11:44:02","modified_gmt":"2023-01-20T10:44:02","slug":"4-2-the-key-deliverables-of-operational-architecture","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/07\/04\/4-2-the-key-deliverables-of-operational-architecture\/","title":{"rendered":"4.2 The key Deliverables of Operational Architecture"},"content":{"rendered":"

4.2 The key Deliverables of Operational Architecture<\/h2>

For any system S, operational architecture has five core types of deliverables:<\/p>\n

    \n
  1. the need architecture diagram<\/em> that hierarchically organizes all needs \u2013 with respect to S \u2013 according to an refinement hierarchy (see below),<\/li>\n
  2. the lifecycle diagram<\/em> that describes how S passes \u2013 with indication of the associated events \u2013 from an operational context to another one, starting from its birth up to its death,<\/li>\n
  3. the use case diagrams<\/em> that are describing \u2013 in a purely static way \u2013 the missions of S that are contributing to a given operational context,<\/li>\n
  4. the operational scenario diagram<\/em>s that are describing \u2013 in a dynamic way \u2013 the interactions taking place between S and its stakeholders1<\/a><\/sup>Or equivalently external systems.<\/span> in a given operational context,<\/li>\n
  5. the operational flow diagrams<\/em> that synthetizes all flows \u2013 with their logical relationships \u2013 exchanged between S and its reference environment during the lifecycle of S.<\/li>\n<\/ol>\n

    These different types of deliverables are presented more in details below.<\/p>\n<\/div>

    4.2.1 Need Architecture Diagram<\/h3>

    Let S be a system. The need architecture diagram<\/em> of S is then a hierarchical exhaustive representation of all needs with respect to S, a need N1 being under another need N2 in this hierarchy if and only if one can logically deduce N1 from N22<\/a><\/sup>Remember that needs are logical predicates (see subsection 2.4.3)<\/span>. In this last situation, one says then more precisely that N2 refines into N1, which explains why one speaks of a need refinement hierarchy. Figure 42 below now shows a (partial) need architecture diagram for an electronic toothbrush, a need being \u2013 classically \u2013 represented here by a 2-part box, whose first top part is a short name summarizing the need scope and second bottom part is the need statement, when the refinement relationships on which the need hierarchy relies are \u2013 also classically \u2013 represented by arrows.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25507″ img_size=\u00a0\u00bb450×275″ alignment=\u00a0\u00bbcenter\u00a0\u00bb css=\u00a0\u00bb.vc_custom_1627978147126{margin-bottom: 25px !important;}\u00a0\u00bb]

    Figure 42 \u2013 Example of a need architecture diagram for an electronical toothbrush\u00a0<\/span><\/strong><\/p>\n<\/div>

    The same issue that was already pointed out in the first part of subsection 3.2 when dealing with the stakeholder hierarchy diagram can also be expressed \u2013 more or less in the same terms \u2013 with the need architecture diagram: organizing a need refinement hierarchy is indeed always difficult since one shall avoid to have too much needs of first level, but also too many levels of refinements if one wants to be able to efficiently use such a view. The 7x7x7 rule (see first part of subsection 3.2) is again precious to handle this real difficulty. As a consequence, a typical \u201cgood\u201d need architecture diagram associated with a given system shall have no more than 7 high level needs, each of them refined in around 7 medium level needs, finally also refining in the same way into 7 low level needs. Note again that the number 7 shall of course be just taken as an order of magnitude. Obtaining up to 10-12 high level needs in a need architecture diagram could of course work: however one must probably not go further without analyzing whether this number is justified. Finally one shall not hesitate to construct additional need architecture diagrams for refining such an analysis as soon as all relevant needs are not captured.<\/p>\n<\/div>

    4.2.2 Lifecycle Diagram<\/h3>

    Let S be again a system. The lifecycle diagram<\/em> of S is then a representation of:<\/p>\n