{"id":25535,"date":"2021-06-03T13:54:39","date_gmt":"2021-06-03T11:54:39","guid":{"rendered":"https:\/\/cesam.community\/?p=25535"},"modified":"2023-01-20T11:45:21","modified_gmt":"2023-01-20T10:45:21","slug":"5-2-the-key-deliverables-of-functional-architecture","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/06\/03\/5-2-the-key-deliverables-of-functional-architecture\/","title":{"rendered":"5.2 The key Deliverables of Functional Architecture"},"content":{"rendered":"

5.2 The key Deliverables of Functional Architecture<\/h2>

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

    \n
  1. the functional requirement architecture diagram<\/em> that hierarchically organizes all functional requirements \u2013 with respect to S \u2013 according to an refinement hierarchy,<\/li>\n
  2. the functional mode diagram<\/em> that describes how S passes \u2013 with indication of the associated events \u2013 from a functional mode to another one, starting from its birth up to its death,<\/li>\n
  3. the functional decomposition & interaction diagrams<\/em> that are describing \u2013 in a purely static way \u2013 the functions of S with their interactions1<\/a><\/sup> Usually only at global level, but also possibly in only a given functional mode. <\/span>,<\/li>\n
  4. the functional scenario diagrams<\/em> that are describing \u2013 in a dynamic way \u2013 the interactions taking place between the functions of S, in a given functional mode,<\/li>\n
  5. the functional flow diagrams<\/em> that synthetizes all flows \u2013 with their logical relationships \u2013 absorbed or produced by the functions of S during the \u201cfunctional mode cycle\u201d2<\/a><\/sup>That is to say the period of time modeled by the functional mode diagram.<\/span> of S.<\/li>\n<\/ol>\n

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

    5.2.1 Functional Requirement Architecture Diagram<\/h2>

    Let S be a system. The functional requirement architecture diagram<\/em> of S is then a hierarchical exhaustive representation of all functional requirements of S, a functional requirement R1 being under another functional requirement R2 in this hierarchy if and only if one can logically deduce R1 from R23<\/a><\/sup>Remember that functional requirements are logical predicates (see subsection 2.4.3).<\/span>. In this last situation, one says then more precisely that R2 refines into R1, which explains why one speaks of a functional requirement refinement hierarchy.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25536″ img_size=\u00a0\u00bb450×276″ alignment=\u00a0\u00bbcenter\u00a0\u00bb]

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

    Figure 47 illustrates here a (partial) functional requirement architecture diagram for an electronic toothbrush, a functional requirement being \u2013 classically and exactly similarly to a need \u2013 represented here by a 2-part box, whose first top part is a short name summarizing the functional requirement scope and second bottom part is the functional requirement statement, the refinement relations, on which relies the functional requirement hierarchy, being \u2013 also classically \u2013 represented by arrows.<\/p>\n

    Note that exactly the same issue already pointed out for the need requirement architecture diagram takes also place with the functional requirement architecture diagram: organizing a functional requirement refinement hierarchy is indeed always difficult since one shall avoid to have too much functional requirements of first level, but of course 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 a precious tool to handle this real difficulty. As a consequence, a typical \u201cgood\u201d functional requirement architecture diagram associated with a given system shall have no more than 7 high level functional requirements, each of them refined in around 7 medium level functional requirements, finally also refining in the same way into 7 low level functional requirements. Note again that the number 7 shall just be taken as an order of magnitude. Obtaining up to 10-12 high level functional requirements in a functional requirement 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 as many additional functional requirement architecture diagrams as necessary, for refining such an analysis as soon as all relevant functional requirements are not derived and\/or captured.<\/p>\n<\/div>

    5.2.2 Functional Mode Diagram<\/h2>

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