{"id":25871,"date":"2021-07-14T14:12:21","date_gmt":"2021-07-14T12:12:21","guid":{"rendered":"https:\/\/cesam.community\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/"},"modified":"2022-11-15T12:02:09","modified_gmt":"2022-11-15T11:02:09","slug":"2-4-more-systems-architecture-dimensions-2-2","status":"publish","type":"post","link":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/","title":{"rendered":"2.4 More Systems Architecture Dimensions (2\/2)"},"content":{"rendered":"<div class=\"wpb-content-wrapper\"><section class=\"vc_row wpb_row vc_row-fluid  vc_custom_1627389518372\"><div class=\"wpb_column vc_column_container vc_col-sm-10 vc_col-md-offset-1 col-xs-mobile-fullwidth\"><div class=\"vc_column-inner \"><div class=\"wpb_wrapper\"><div class=\"vc_row wpb_row vc_inner vc_row-fluid\"><div class=\"wpb_column vc_column_container vc_col-sm-9  col-xs-mobile-fullwidth\"><div class=\"vc_column-inner \"><div class=\"wpb_wrapper\"><h3 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-1\"  style=\"font-weight: 500;\">2.4.2.3 Dynamics<\/h3><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">The <em>dynamic<\/em> of a static element of a system S refers to its temporal behavior or equivalently to an algorithmic description of such a temporal behavior. Dynamics are completely crucial if one wants to precisely specify the behavior of any system or any system mission, function or component.<\/p>\n<p style=\"text-align: justify;\">There are therefore logically three different types of dynamics for a given system S, depending on the considered architectural vision, which are defined as follows:<\/p>\n<ul>\n<li style=\"text-align: justify;\">Operational dynamics are called <em>operational scenarios<\/em>: an operational scenario of S is an algorithmic description of the interactions existing between the system (considered as a black box) and its environment,<\/li>\n<li style=\"text-align: justify;\">Functional static elements are called <em>functional scenarios<\/em>: a functional scenario of S is an algorithmic description of the interactions existing on one hand internally between the functions of S and on the other hand externally with the environment of the system,<\/li>\n<li style=\"text-align: justify;\">Constructional static elements are called <em>constructional scenarios<\/em>: a constructional scenario of S is an algorithmic description of the interactions existing on one hand internally between the components of S and on a second hand externally with the environment of the system.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Note that these three types of scenarios have exactly the same nature since they are all describing an exchange algorithmic. The only difference comes here from the nature of the exchanges that are described by these different scenarios.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25415&Prime; img_size=\u00a0\u00bb400&#215;270&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 34 \u2013 Standard representations of an operational dynamic <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Let us now end by addressing the question of the standard representations of the different types of dynamics which are typically given \u2013 in most modeling languages \u2013 by <em>sequence diagrams<\/em>. Figure 34 depicts this formalism with an example of operational dynamic description, here the initiation of a toothbrush use where one specifies the interactions existing between all involved stakeholders and the system. Sequence diagrams provide indeed an efficient and classical formalism for representing distributed algorithms (see [20] for more details). In this mode of representation, the different elements in interaction are positioned on the top of the diagram and each of them has a timeline going from top to bottom that represents time (each element having its own time). One models then an interaction by putting \u2013 one after the other \u2013 arrows, going from the initiator to the receiver of an interaction between two elements, with an indication either of the function, used by the interaction initiator to manage the interaction, or of the flow which is exchanged during the interaction (see our next subsection for more details). These arrows are thus following the sequential order of a given interaction, as depicted in Figure 34. Note finally that one indicates the interacting sequences that are highly coupled by a large rectangle at the level of the modeled system.<\/p>\n<p style=\"text-align: justify;\">For the sake of completeness, we also provide an example of constructional scenario that can be found in Figure 35 below which represents the exact constructional counterpart of the previous operational scenario. Functional scenarios are represented exactly in the same way, components being just replaced by functions. Note that the difference between a functional or constructional scenario and an operational scenario is only that the environment is a black box in the first situation when it is the case of the system in the second situation<sup class=\"modern-footnotes-footnote \" data-mfn=\"1\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-1\">1<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-1\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"1\">There are of course also mixed scenarios where one may provide details on both the environment and the system.<\/span>.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25418&Prime; img_size=\u00a0\u00bb400&#215;270&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 35 \u2013 Standard representations of a constructional dynamic <\/span><\/strong><\/p>\n<\/div><h3 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-2\"  style=\"font-weight: 500;\">2.4.2.4 Flows<\/h3><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">A <em>flow<\/em> associated with a system S models an object \u2013 matter, energy, data, information, etc. \u2013 which is exchanged either externally between the system and its environment, or internally between two functional or constructional elements of the system.<br \/>\nFlows may be quite different depending on the vision. To illustrate that last point, let us take the example of a traffic light system. When the traffic light is red, it operationally sends a stop request to the drivers that are looking at it. The operational flow exchanged between the traffic light and the drivers can then be modeled by a \u201cSTOP ORDER\u201d flow. On the functional level, one would however typically say that the traffic light is just sending red light (which is interpreted as a stop signal by the drivers) to its environment, which may be modeled by a \u201cRED\u201d functional flow. Finally it is amusing to observe that at constructional level, the red color is just produced by lighting the first (starting from the top) white traffic light, in connection with a red filter. The associated constructional flow can thus be modeled by \u201cWHITE 3\u201d to express that situation.<\/p>\n<p style=\"text-align: justify;\">There are therefore logically three different types of flows for a given system S, depending on the considered architectural vision, which are defined as follows:<\/p>\n<ul>\n<li style=\"text-align: justify;\">Operational flows or objects: an <em>operational flow<\/em> or object of S is an object that is exchanged between S and its environment, i.e. between S and one of its external system,<\/li>\n<li style=\"text-align: justify;\">Functional flows or objects: a <em>functional flow<\/em> or object of S is an object which is an input or an output of one of the functions of S, i.e. which is exchanged between the functions of S,<\/li>\n<li>Constructional flows or objects: a <em>constructional flow<\/em> or object of S models a concrete object which is exchanged between the components of S.<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">Flows are usually simply stated using only names that are referring to concrete objects which are exchanged between different systems. Table 4 below illustrates these various notion of flows with some examples for an electronic toothbrush.<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25421&Prime; img_size=\u00a0\u00bb450&#215;233&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb css=\u00a0\u00bb.vc_custom_1627903199184{margin-bottom: 25px !important;}\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Table 4 \u2013 Examples of flows for an electronic toothbrush <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Note that flows are naturally related by allocation relations. As illustrated by the traffic light system example provided above, an operational flow OF may be allocated to either a functional flow or a constructional flow which may be operationally interpreted as OF. In the same way, a functional flow FF may also be allowed to a constructional flow that may be functionally interpreted as FF. Flows hierarchies are therefore naturally induced by these allocation relations. Let us end by providing the standard representations of the three different types of flows \u2013 in most modeling languages \u2013 which are modeled by \u201cobjects\u201d or \u201cblocks\u201d in the usual meaning given to this concept in object-oriented modeling (see [20] or [34]).<\/p>\n<\/div>[vc_single_image image=\u00a0\u00bb25424&Prime; img_size=\u00a0\u00bb400&#215;75&Prime; alignment=\u00a0\u00bbcenter\u00a0\u00bb css=\u00a0\u00bb.vc_custom_1627903191127{margin-bottom: 30px !important;}\u00a0\u00bb]<div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Figure 36 \u2013 Standard representations of flows <\/span><\/strong><\/p>\n<\/div><h2 id=\"0.1\" class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-3\"  style=\"font-weight: 500; color: #01af50;\">2.4.3 Expected Properties<\/h2><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">As already stated above in section 0.3, expected properties are formally speaking logical predicates related with the system of interest (see Chapter 0 or<a href=\"https:\/\/cesam.community\/en\/2021\/08\/04\/appendix-a-system-temporal-logic\/\"> Appendix A<\/a> for more technical details on that core logical concept that goes back to Aristoteles). An expected property is thus nothing else than a Boolean function<sup class=\"modern-footnotes-footnote \" data-mfn=\"2\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-2\">2<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-2\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"2\">This is thus also true for needs and requirements according to the definitions that follow.<\/span>, i.e. a function P that maps a system on TRUE or FALSE, depending whether the property that P models is satisfied or not by the system:<\/p>\n<p style=\"text-align: center;\">P: S \u2192 P(S) \u2208 { FALSE, TRUE }<\/p>\n<p style=\"text-align: justify;\">This consideration allows avoiding confusing expected properties with their constitutive elements. An expected property indeed typically expresses that a given system shall behave or be structured with a certain external or internal performance<sup class=\"modern-footnotes-footnote \" data-mfn=\"3\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-3\">3<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-3\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"3\">In other terms, expected properties do express the performances that shall be satisfied by the system of interest or by its environment, depending whether one deals with the functional\/constructional or operational visions. <\/span>. The involved behavioral or structural elements &amp; performances shall thus not be mixed with the property, since they are just not logical predicates.<\/p>\n<p style=\"text-align: justify;\">It is also important to remember that one can analyze in practice a given system S from an external or from an internal perspective. This consideration leads to the key distinction between needs &amp; requirements, which are the two first main types of expected properties on S:<\/p>\n<ul>\n<li style=\"text-align: justify;\"><strong>External perspective<\/strong><sup class=\"modern-footnotes-footnote \" data-mfn=\"4\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-4\">4<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-4\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"4\">External perspective is here a synonym of operational vision.<\/span> <strong> \u2013 Need<\/strong>: a <em>need<\/em> with respect to S is a property that is expected or imposed by the environment Env(S) of S, expressed in the language of the environment<sup class=\"modern-footnotes-footnote \" data-mfn=\"5\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-5\">5<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-5\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"5\"> One cannot thus use the language of the system to express a need.<\/span> (i.e. only referring to operational descriptions &amp; performance),<\/li>\n<li style=\"text-align: justify;\"><strong>Internal perspective \u2013 Requirement<\/strong>: a <em>requirement<\/em> on S is a functional or constructional property that shall be satisfied by S, expressed in the language of the system (i.e. only referring to functional or constructional descriptions &amp; performances).<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">One shall of course understand that these definitions are fundamentally relative to a given system. A need with respect to a system S is indeed a requirement on the environment Env(S) of S. In the same way, a requirement on S is also a need with respect to a subsystem of S. One should hence always remember to point explicitly out the system of interest to which refers any need or requirement. Note also that we used here above a voluntarily different terminology depending on the external or internal perspective we may take with respect to expected properties. A good system architecting practice indeed consists in strictly separating the domain of the question \u2013 expressed using needs \u2013 from the domain of the <em>solution<\/em> \u2013 expressed by means of requirements<sup class=\"modern-footnotes-footnote \" data-mfn=\"6\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-6\">6<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-6\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"6\">This point is illustrated by Case study 4.<\/span>. In other terms, needs shall be only reserved to model questions, when requirements shall model the corresponding answers. This point is crucial since many engineering problems are due to the fact that stakeholders are often expressing their \u201cneeds\u201d in an intrusive way, i.e. in terms of requirements in our meaning. This bad practice both limit the ability of the designers to propose better alternative solutions and prevent them to know the real needs hidden behind requirements<sup class=\"modern-footnotes-footnote \" data-mfn=\"7\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-7\">7<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-7\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"7\">In a recent customer specification file for military vehicles, one could for instance find the demand C \u2261 \u201cThe vehicle shall be painted in green\u201d which was just copied\/pasted from previous files. This expected property is typically not a need, but a constructional requirement. A good systems architect shall then try to understand the functional &amp; operational expected properties from which C derives. In this case, C can be traced back to a functional requirement F \u2261 \u201cThe vehicle shall not be visible\u201d, itself coming from a quite simple need N \u2261 \u201cSoldiers shall not die when in operations\u201d. At this point, one now has the rationale of the green color which was just motivated by the fact that it allows to be invisible in European battlefields when green is dominant. But conflicts are not anymore taken place in Europe, but rather in Middle East or Afghanistan where ocher and sand colors are dominant. The analysis of the root need allows thus to understand that C is a very bad constructional choice to implement the functional requirement F which is still valid. One shall of course rather request C\u2019 \u2261 \u201cThe vehicle shall be painted in ocher\/sand colors\u201d, which could not be suspected if only staying at constructional level.<\/span>, which may ultimately lead to bad solutions from an end-user perspective even if fitting perfectly to their requirements.<\/p>\n<p style=\"text-align: justify;\">Note finally that requirements on a system S can be of course refined into two sub-types depending whether one is dealing with functional or constructional visions:<\/p>\n<ul>\n<li style=\"text-align: justify;\"><strong>Functional requirement<\/strong>: a <em>functional requirement<\/em> on S is a property that shall be satisfied by the behavior of S, expressed in the functional language of the system (i.e. only referring to functional descriptions &amp; performances),<\/li>\n<li style=\"text-align: justify;\"><strong>Constructional requirement<\/strong>: a <em>constructional requirement<\/em> on S is a property that shall be satisfied by the structure of S, expressed in the constructional language of the system (i.e. only referring to constructional descriptions &amp; performances).<\/li>\n<\/ul>\n<p style=\"text-align: justify;\">To write down properly these different types of expected properties, one shall use the standard statement patterns \u2013 referring to the notions introduced above \u2013 that are provided in Table 5.<\/p>\n<table class=\" aligncenter\" style=\"border-collapse: collapse; width: 72.3028%;\">\n<tbody>\n<tr>\n<td style=\"width: 13.1916%; text-align: center;\"><em>Need<\/em><\/td>\n<td style=\"width: 59.1113%; text-align: center;\">The \u201cexternal system<sup class=\"modern-footnotes-footnote \" data-mfn=\"8\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-8\">8<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-8\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"8\">Or equivalently a stakeholder of the system (see Chapter 3). <\/span>\u201d shall \u201cdo something \/ be formed of something\u201d with a certain \u201coperational performance\u201d in a given \u201coperational context\u201d.<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 13.1916%; text-align: center;\"><em>Functional requirement<\/em><\/td>\n<td style=\"width: 59.1113%; text-align: center;\">The \u201csystem\u201d shall \u201cdo something<sup class=\"modern-footnotes-footnote \" data-mfn=\"9\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-9\">9<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-9\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"9\">\u201cTo do something\u201d shall always refer here to an existing function of the considered system. <\/span>\u201d with a certain \u201cfunctional performance\u201d in a given \u201cfunctional mode\u201d.<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 13.1916%; text-align: center;\"><em>Constructional requirement<\/em><\/td>\n<td style=\"width: 59.1113%; text-align: center;\">The \u201csystem\u201d shall \u201cbe formed of something<sup class=\"modern-footnotes-footnote \" data-mfn=\"10\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-10\">10<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-10\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"10\">\u201cTo be formed of something\u201d shall always refer here to an existing component of the considered system.<\/span>\u201d with a certain \u201cconstructional performance\u201d in a given \u201cconfiguration\u201d.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Table 5 \u2013 Standard statement patterns for needs and functional &amp; constructional requirements <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Table 6 illustrates the three previous different types of expected properties \u2013 written in accordance with the above standard statement patterns \u2013 on an electronic toothbrush, with a picture of the toothbrush part which is (partially) specified by them. In this example, the proposed need was derived first into a functional requirement that was derived then into a constructional requirement. One can thus immediately trace back here the last constructional choice to the associated service provided to the end-users, which is useful \u2013 especially to analyze the stakeholder value brought by a given technical decision \u2013 since this service cannot be seen at constructional level.<\/p>\n<table class=\" aligncenter\" style=\"border-collapse: collapse; width: 72.3028%;\">\n<tbody>\n<tr>\n<td style=\"width: 13.1916%; text-align: center;\"><em>Need<\/em><\/td>\n<td style=\"width: 59.1113%; text-align: center;\">End users shall get a positive<sup class=\"modern-footnotes-footnote \" data-mfn=\"11\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-11\">11<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-11\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"11\">Positive refers here to the performance.<\/span> feeling when efficiently cleaning their teeth.<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 13.1916%; text-align: center;\"><em>Functional requirement<\/em><\/td>\n<td style=\"width: 59.1113%; text-align: center;\">The electronical toothbrush shall display an encouraging message within 1 second when cleaning performance has been met.<\/td>\n<\/tr>\n<tr>\n<td style=\"width: 13.1916%; text-align: center;\"><em>Constructional requirement<\/em><\/td>\n<td style=\"width: 59.1113%; text-align: center;\">The electronical toothbrush shall have a user interface of 2.5 cm x 1cm in each configuration.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Table 6 \u2013 Examples of expected properties per architectural vision <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">Note finally that the previous types of expected properties are <em>complete<\/em> by construction with respect to the CESAM framework. In other words, one can always specify any system in intension by <em>using only<\/em> needs, functional requirements and constructional requirements, without anything else.<\/p>\n<\/div><div class=\" vc_custom_1627906169963 last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong>Needs or Requirements? The Tanker Case<\/strong><\/p>\n<p style=\"text-align: center;\">In the 70\u2019s, important leaks occurred when pumping out liquid natural gas from tankers. The issue was that dangerous cracks appeared in the shell of the tankers due to the very cold temperature \u2013 closed to 0\u00b0K \u2013 of the gas. To solve that problem, engineers began to think in terms of technical solutions which lead to a strong requirement on a metal for tankers shells that should not crack at liquid gas temperature. This was however a very bad idea since the resulting solution would probably have requested many years of R&amp;T and cost hundreds of millions euros.<br \/>\nAnother way of reasoning is to express the problem in terms of the question to solve, which is \u201chow to avoid the gas to enter in contact with the shell metal?\u201d Such a question expresses a simple constraint on the gas (which is a need in CESAM formalism) that has to be fulfilled. Such a question has then a simple and quite cheap solution, consisting in putting pieces of folded cardboard under the leaking points. The gas is then retained by the cardboard before quickly evaporating, which avoids all troubles.<\/p>\n<p style=\"text-align: center;\">As one sees on that illustrative simple example, there may be a huge gap between thinking in terms of solutions (requirements) and in terms of questions (needs).<\/p>\n<\/div><div class=\" vc_custom_1627907901514 last-paragraph-no-margin\"><p style=\"text-align: center;\"><strong><span style=\"font-size: 10pt;\">Case study 4 \u2013 Needs or requirements? The tanker case <\/span><\/strong><\/p>\n<\/div><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\">There is in particular no need to introduce the concept of \u201cnon-functional requirements\u201d that exists in many other architectural referential (cf. [42], [43] or [44]) and does often refer to \u201city\u201d properties of a system such as availability, maintainability, operability, safety, reliability, security, etc. All these properties can indeed easily be expressed in terms of needs. To be more specific, let us take the example of a maintainability property for a given system which would probably be expressed by most engineers by stating that M \u2261 \u201cthe system shall be maintainable\u201d. However \u201cTo be maintainable\u201d can clearly not be considered as an internal function of a system since it does not refer to any input\/output behavior, but rather to a permanent status of the system. Property M is therefore neither a functional, nor a constructional requirement<sup class=\"modern-footnotes-footnote \" data-mfn=\"12\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-12\">12<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-12\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"12\"> Since it also obviously does not directly refer to a property of the components of the system. <\/span>, nor a need<sup class=\"modern-footnotes-footnote \" data-mfn=\"13\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-13\">13<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-13\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"13\">Strictly speaking, it indeed only refers to the system and not to its environment.<\/span> within our framework. It has thus absolutely no status at all, which shows that it is probably a bad specification! The good way of expressing the property M is then just to identify the hidden stakeholders behind \u2013 which are here just maintenance teams \u2013 and to understand what are expecting these stakeholders. In our example, this would lead us to reformulate M by stating instead M\u2019 \u2261 \u201cthe maintenance teams shall maintain the system with a certain performance\u201d<sup class=\"modern-footnotes-footnote \" data-mfn=\"14\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-14\">14<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-14\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"14\"> Which is now correctly written since \u201cTo maintain the system\u201d is clearly a behavior of the maintenance teams.<\/span> which is now obviously a need since it expresses an expectation of the environment of the system. The reader can do the same kind of exercise for the other classical \u201cnon-functional properties\u201d of a system to convince him\/herself that all theseproperties are just bad formulations of needs<sup class=\"modern-footnotes-footnote \" data-mfn=\"15\" data-mfn-post-scope=\"00000000000019b60000000000000000_25871\"><a href=\"javascript:void(0)\"  role=\"button\" aria-pressed=\"false\" aria-describedby=\"mfn-content-00000000000019b60000000000000000_25871-15\">15<\/a><\/sup><span id=\"mfn-content-00000000000019b60000000000000000_25871-15\" role=\"tooltip\" class=\"modern-footnotes-footnote__note\" tabindex=\"0\" data-mfn=\"15\">Availability, operability, safety, reliability or security issues do for instance typically refer to customers, end-users and\/or operators expectations.<\/span>.<\/p>\n<\/div><a  href=\"https:\/\/cesam.community\/2021\/08\/02\/2-5-cesam-systems-architecture-matrix\/\" target=\"_self\" class=\"btn pofo-button-1 bg-position-center-center  wow none button-style9  btn-link text-extra-dark-gray text-deep-pink-hover  btn-medium   vc_custom_1627911675822\" >Next page<i class=\"ti-arrow-right   margin-5px-left no-margin-right\" aria-hidden=\"true\"><\/i><\/a><\/div><\/div><\/div><div class=\"wpb_column vc_column_container vc_col-sm-3  col-xs-mobile-fullwidth\"><div class=\"vc_column-inner \"><div class=\"wpb_wrapper\"><h2 class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-4\"  style=\"font-size: 10px; font-weight: 600; color: #000000;\" data-fontsize=\"10px\">TABLE OF CONTENTS<\/h2>[vc_wp_custommenu nav_menu=\u00a0\u00bb132&Prime;]<h2 class=\"text-medium-gray text-small margin-5px-bottom alt-font text-uppercase heading-style4  heading-5\"  style=\"font-size: 10px; font-weight: 600; color: #000000;\" data-fontsize=\"10px\">REFERENCES<\/h2><div class=\"last-paragraph-no-margin\"><p style=\"text-align: justify;\"><span style=\"font-size: 8pt;\">[20]Booch G., Jacobson I., Rumbaugh J., The Unified Modeling Language Reference Manual,<\/span><span style=\"font-size: 8pt;\">Second Edition, Addison-Wesley, 2004<\/span><\/p>\n<p style=\"text-align: justify;\"><span style=\"font-size: 8pt;\">[34] Friedenthal S., Moore A.C., Steiner R., A Practical Guide to SysML : the Systems Modeling Language, Morgan Kaufmann OMG Press, 2012 <\/span><\/p>\n<p style=\"text-align: justify;\"><span style=\"font-size: 8pt;\">[42] IEEE, IEEE 1220-2005 \u2013 Standard for Application and Management of the Systems Engineering Process, Institute of Electrical and Electronics Engineers, 2005 <\/span><\/p>\n<p style=\"text-align: justify;\"><span style=\"font-size: 8pt;\">[43] INCOSE, Systems Engineering Handbook, A guide for system life cycle processes and activities, INCOSE, January 2011, <\/span><\/p>\n<p style=\"text-align: justify;\"><span style=\"font-size: 8pt;\">[44] ISO\/IEC\/IEEE, ISO\/IEC\/IEEE 15288:2015 \u2013 Systems and software engineering &#8212; System life cycle processes, May 2015<\/span><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/div><\/section>\n<\/div>","protected":false},"excerpt":{"rendered":"2.4.2.3 DynamicsThe dynamic of a static element of a system S refers to its temporal behavior or equivalently to an algorithmic description of such a temporal behavior. Dynamics are completely crucial if one wants to precisely specify the behavior of any system or any system mission, function or component. There are therefore logically three different types of dynamics for a given system S, depending on the considered architectural vision, which are defined as follows: Operational dynamics are called operational scenarios: an operational scenario of S is an algorithmic description of the interactions existing between the system (considered as a black box) and its environment, Functional static elements are called functional scenarios: a functional scenario of S is an algorithmic description of the interactions existing on one hand internally between the functions of S and on the other hand externally with the environment of the system, Constructional static elements are called constructional scenarios: a constructional scenario of S is an algorithmic description of the interactions existing on one hand internally between the components of S and on a second hand externally with the environment of the system. Note that these three types of scenarios have exactly the same nature since they...","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[158],"tags":[157],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v24.2 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>2.4 More Systems Architecture Dimensions (2\/2) - Cesam Community<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/\" \/>\n<meta property=\"og:locale\" content=\"fr_FR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"2.4 More Systems Architecture Dimensions (2\/2) - Cesam Community\" \/>\n<meta property=\"og:url\" content=\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/\" \/>\n<meta property=\"og:site_name\" content=\"Cesam Community\" \/>\n<meta property=\"article:published_time\" content=\"2021-07-14T12:12:21+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2022-11-15T11:02:09+00:00\" \/>\n<meta name=\"author\" content=\"admin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@cesamcommunity\" \/>\n<meta name=\"twitter:site\" content=\"@cesamcommunity\" \/>\n<meta name=\"twitter:label1\" content=\"\u00c9crit par\" \/>\n\t<meta name=\"twitter:data1\" content=\"admin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Dur\u00e9e de lecture estim\u00e9e\" \/>\n\t<meta name=\"twitter:data2\" content=\"14 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/\"},\"author\":{\"name\":\"admin\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505\"},\"headline\":\"2.4 More Systems Architecture Dimensions (2\/2)\",\"datePublished\":\"2021-07-14T12:12:21+00:00\",\"dateModified\":\"2022-11-15T11:02:09+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/\"},\"wordCount\":3367,\"publisher\":{\"@id\":\"https:\/\/cesam.community\/fr\/#organization\"},\"keywords\":[\"Article\"],\"articleSection\":[\"CESAM Systems Architecting Method\"],\"inLanguage\":\"fr-FR\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/\",\"url\":\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/\",\"name\":\"2.4 More Systems Architecture Dimensions (2\/2) - Cesam Community\",\"isPartOf\":{\"@id\":\"https:\/\/cesam.community\/fr\/#website\"},\"datePublished\":\"2021-07-14T12:12:21+00:00\",\"dateModified\":\"2022-11-15T11:02:09+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/#breadcrumb\"},\"inLanguage\":\"fr-FR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/cesam.community\/fr\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"CESAM Systems Architecting Method\",\"item\":\"https:\/\/cesam.community\/fr\/category\/cesam-systems-architecting-method-en\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"2.4 More Systems Architecture Dimensions (2\/2)\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/cesam.community\/fr\/#website\",\"url\":\"https:\/\/cesam.community\/fr\/\",\"name\":\"Cesam Community\",\"description\":\"La communaut\u00e9 CESAM\",\"publisher\":{\"@id\":\"https:\/\/cesam.community\/fr\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/cesam.community\/fr\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"fr-FR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/cesam.community\/fr\/#organization\",\"name\":\"CESAM Community\",\"url\":\"https:\/\/cesam.community\/fr\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"fr-FR\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png\",\"contentUrl\":\"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png\",\"width\":7310,\"height\":1018,\"caption\":\"CESAM Community\"},\"image\":{\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/x.com\/cesamcommunity\",\"https:\/\/www.linkedin.com\/company\/community-cesam\/about\/\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505\",\"name\":\"admin\",\"sameAs\":[\"https:\/\/cesam.community\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"2.4 More Systems Architecture Dimensions (2\/2) - Cesam Community","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/","og_locale":"fr_FR","og_type":"article","og_title":"2.4 More Systems Architecture Dimensions (2\/2) - Cesam Community","og_url":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/","og_site_name":"Cesam Community","article_published_time":"2021-07-14T12:12:21+00:00","article_modified_time":"2022-11-15T11:02:09+00:00","author":"admin","twitter_card":"summary_large_image","twitter_creator":"@cesamcommunity","twitter_site":"@cesamcommunity","twitter_misc":{"\u00c9crit par":"admin","Dur\u00e9e de lecture estim\u00e9e":"14 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/#article","isPartOf":{"@id":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/"},"author":{"name":"admin","@id":"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505"},"headline":"2.4 More Systems Architecture Dimensions (2\/2)","datePublished":"2021-07-14T12:12:21+00:00","dateModified":"2022-11-15T11:02:09+00:00","mainEntityOfPage":{"@id":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/"},"wordCount":3367,"publisher":{"@id":"https:\/\/cesam.community\/fr\/#organization"},"keywords":["Article"],"articleSection":["CESAM Systems Architecting Method"],"inLanguage":"fr-FR"},{"@type":"WebPage","@id":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/","url":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/","name":"2.4 More Systems Architecture Dimensions (2\/2) - Cesam Community","isPartOf":{"@id":"https:\/\/cesam.community\/fr\/#website"},"datePublished":"2021-07-14T12:12:21+00:00","dateModified":"2022-11-15T11:02:09+00:00","breadcrumb":{"@id":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/#breadcrumb"},"inLanguage":"fr-FR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/cesam.community\/fr\/2021\/07\/14\/2-4-more-systems-architecture-dimensions-2-2\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/cesam.community\/fr\/"},{"@type":"ListItem","position":2,"name":"CESAM Systems Architecting Method","item":"https:\/\/cesam.community\/fr\/category\/cesam-systems-architecting-method-en\/"},{"@type":"ListItem","position":3,"name":"2.4 More Systems Architecture Dimensions (2\/2)"}]},{"@type":"WebSite","@id":"https:\/\/cesam.community\/fr\/#website","url":"https:\/\/cesam.community\/fr\/","name":"Cesam Community","description":"La communaut\u00e9 CESAM","publisher":{"@id":"https:\/\/cesam.community\/fr\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/cesam.community\/fr\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"fr-FR"},{"@type":"Organization","@id":"https:\/\/cesam.community\/fr\/#organization","name":"CESAM Community","url":"https:\/\/cesam.community\/fr\/","logo":{"@type":"ImageObject","inLanguage":"fr-FR","@id":"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/","url":"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png","contentUrl":"https:\/\/cesam.community\/wp-content\/uploads\/2021\/04\/cesam_community_logo_v4.png","width":7310,"height":1018,"caption":"CESAM Community"},"image":{"@id":"https:\/\/cesam.community\/fr\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/x.com\/cesamcommunity","https:\/\/www.linkedin.com\/company\/community-cesam\/about\/"]},{"@type":"Person","@id":"https:\/\/cesam.community\/fr\/#\/schema\/person\/1698618e5539e0eadd3578d29281a505","name":"admin","sameAs":["https:\/\/cesam.community"]}]}},"_links":{"self":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25871"}],"collection":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/comments?post=25871"}],"version-history":[{"count":7,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25871\/revisions"}],"predecessor-version":[{"id":32449,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/posts\/25871\/revisions\/32449"}],"wp:attachment":[{"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/media?parent=25871"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/categories?post=25871"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cesam.community\/fr\/wp-json\/wp\/v2\/tags?post=25871"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}