Value Modelling ############### ============================================================= Overview of the Generic Value-Driven Design (VDD) Methodology ============================================================= The image below provides an overview of the generic VDD process from the capture of stakeholder expectations to the establishment of requirements. .. figure:: /objects/images/D224_figure1.png :scale: 100% The generic Value-Driven Design (VDD) Process Model The high-level VDD process consists of the following sub-processes: 1. Stakeholder expectations are captured and validated. 2. Based on step (1), plus any additional available context knowledge, stakeholder needs are identified, analysed and rank-weighted. 3. A first iteration Value Creation Strategy including Value Drivers is developed for a specific context, based on the analysed and rank-weighted needs. 4. Hierarchies of quantified objectives with specific target values or target functions are developed based on the analysed and rank-weighted needs. 5. A second iteration Value Creation Strategy including Value Drivers is developed for the specific context, based on the analysed and rank-weighted quantified objectives. 6. Value models are developed and used for the |optimisation| of early design concepts. 7. Requirements are established based on the rank-weighted, quantified objectives. .. figure:: /objects/images/D224_figure2.png :scale: 100% The iterative nature of the VDD process For more details on the background to Value Generation see eLearn: Value Generation Training which conveys and trains on the perspective of Value Generation, including some of the main concepts of value – from expectations to requirements, through needs, value dimensions and value drivers, its application in real industrial contexts (at A/C, engine and sub-system level) and its implementation through the collaborative BDA ===================================================== Brief description of Value Modelling Business objects ===================================================== The |Value Modelling| Business objects are: =========================================== ========================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================== Name Description =========================================== ========================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================== Stakeholder Expressed Expectation Stakeholder expectations can be of any format, granularity or detail. Stakeholder expressed expectations are expectations that have been stated by stakeholders. Stakeholder validated expectation Stakeholder validated expectations are what we understand to be the expectations of stakeholders based on their statements made. These may be reformulated and contain additional information, and have to be validated by the stakeholders. This validation means that the stakeholders agree that we have properly understood their expectations. Stakeholder Need Stakeholder Needs are high-level statements of problems that need to be solved by a new or re-used system solution. In a given context these needs will be based on captured and validated expectations of external stakeholders, as well as additional context knowledge from external and internal stakeholders. Needs are the source for the development of Requirements, through the Objective definition activity (to make them measurable); and are satisfied by improvements along one or several value dimensions. Stakeholder Constraint These are constraints that have been identified for the Stakeholder(s) e.g. use only regional (i.e. smaller) airports e.g. baggage weight limitations (e.g. restrictions in size of cabin bags) Stakeholder Strategic Goal These are the General strategic goal of the stakeholder and are unlikely to be public information. There are likely to be a small number of goals (3-5) for each stakeholder. Quantified Objective An objective reflects the solution point of view. Objectives describe how we want to satisfy a Need in question. Objectives can be organized in a hierarchy per Need, but root objectives shall ultimately be quantified. Expectation Capture Study This is where the Stakeholder expectations were captured. It is likely to have a meeting associated to it which is the customer focus group when the expectations were captured. Either in the same study, or in a related study, the validated expectations are created. Need Analysis Study This is the study to create Stakeholder Needs having analysed Validated Expectations. Value Creation Strategy A Value Creation Strategy (VCS) is a description of a specific context in terms of the selected high level value strategy for this context. It includes initially a set of rank-weighted Needs that have to be satisfied, or in later iterations sets of rank-weighted Objectives with corresponding Measurement criteria; as well as a set of Value Drivers. Value Dimension Value dimensions are abstract high level categories of Needs. Each need should only have one identified value dimension, for example comfort, weight, or cost. It is possible to manage an open list of typical value dimensions. Value Driver Value drivers indicate Key Engineering Characteristics given a specific Value Creation Strategy (i.e. for a specific stakeholder profile and context). They represent proposed directions of investigation since they seem to have a significant influence on the perceived value in a given context (Value Creation Strategy). Value Drivers themselves are not attached to a target value or function, but they tend to result in measurable objectives, and later, based on these objectives, result in requirements. Rank-Weight Type This is the definition of the "scale" for how something is ranked or weighted. It can either be a ranking mechanism, or a weighting mechanism. They can be combined so it is possible to have both ranking and weighting in one "scale". Rank-Weight Instance This is the value for the rank-weight of something. It is an instance of a Rank-weight type Rank-Weight Need Assignment This is the assignment of the rank-weight instance to a Need in the context of a Value Creation Strategy Quantified Objective Rank-Weight Assignment This is the assignment of the rank-weight instance to a Quantified Objective in the context of the particular need fulfilment Quantified Objective Target Assignment This is the assignment of the target to a Quantified Objective in the context of the particular need fulfilment Stakeholder Profile This is how to represent a collective of stakeholders, e.g. large airlines that operate ageing long range fleets. =========================================== ========================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================================== The icons representing the |value modelling| objects in the Business Object Model are shown below: .. figure:: /objects/images/value_modelling_icons.png :scale: 100% Icons for Value Modelling ================================================== Worked example using Business Object Model classes ================================================== The following is a simplified scenario using example data from CRESCENDO deliverable "D2.2.4 Validation Of The System To Link Expectations To Technical Requirements". ====================================================== 1. Stakeholder expectations are captured and validated ====================================================== It is decided to capture some expressed expectations from some key airlines at a customer focus group. An expectation capture study is created, and the customer focus group meeting associated to the study. Note, there are many more relationships that could be set up here, including planning the meeting, templates for the meeting, minutes, concerns to be addressed etc. See SysML - Meetings for more details All the expectations have a focal point that happens also to be the chair of the meeting, and they have a stakeholder which is the profile of the organisations attending the meeting. There are likely to be hundreds of expectations, but for simplicity, this example uses three: * No Down Time * Green Aircraft * Good Passenger Entertainment .. figure:: /objects/images/vm_e_expectations.png :scale: 100% Expressed Expectations are captured .. figure:: /objects/images/vm_ea_e_expectations.png :scale: 100% Expressed Expectations are captured using classes Once the expectations have been addressed, they are then validated as part of a second expectation capture study that has the first as an input. Note: that there does not have to be a one to one relationship between the validated and expressed expectations. The expectations are validated as follows: * Expressed: No Down Time * Validated: High Aircraft Availability * Expressed: Green Aircraft * Validated: Environmentally friendly both A/C and manufacturing aspects * Expressed: Good Passenger Entertainment * Validated: Undisrupted use of the in-flight entertainment system * Validated: Unlimited use of the internet .. figure:: /objects/images/vm_v_expectations.png :scale: 100% Expressed Expectations are Validated .. figure:: /objects/images/vm_ea_v_expectations.png :scale: 100% Expressed Expectations are Validated using classes ========================================= 2. Stakeholder needs identified, analysed ========================================= Once the Validated Expectations are identified, these can be analysed in a Needs Analysis Study to identify the needs. In this example the focal point and stakeholders are the same for the Expectations and for the Needs, but this does not always have to be the case. Note: there are many other objects that can be used as rationale for a Need. See |SysML - Needs| and |SysML - Need Analysis Study| for more details. * Need: Both the A/C itself and the enabling product need to be perceived as environmentally friendly. * Validated: Environmentally friendly both A/C and manufacturing aspects * Need: The A/C needs to be perceived as setting a new standard in terms of entertainment (both on ground and in flight). * Validated: Undisrupted use of the in-flight entertainment system * Validated: Unlimited use of the internet .. figure:: /objects/images/vm_ea_needs_analysis.png :scale: 100% Stakeholder needs are identified All this can happen at multiple levels, so the Expectations and Needs identified at the level of the Airframe Manufacturer can be passed down to the Engine Manufacturer level for the Expectations, Needs and Value Dimensions to be identified at that level. This is illustrated below: .. figure:: /objects/images/vm_e_l2_expectations.png :scale: 100% Needs and Value Dimensions at multiple levels Using the Business Object classes to show how this is done in more detail, the Airframe Manufacturer Needs effectively become the expressed expectations for the Engine Manufacturer, and their own Needs identified. Traceability is maintained between the Expectations and Needs, and between the various Studies used to identify them. .. figure:: /objects/images/vm_ea_e_l2_expectations.png :scale: 100% Level 2 Expectations and Needs identified This example only shows the flow downwards for one level, but there is no reason why the flow cannot be across several levels, and also be upwards. For upwards flow the Needs from the Engine Manufacturer become Expectations for the Airframe Manufacturer. The process then becomes cyclical and iterative. This is described in more detail in eLearn: Value Generation Training =============================================================== 3. Value Creation strategy for analysed and rank-weighted Needs =============================================================== A first iteration Value Creation Strategy (VCS) is developed for a given context, based on the analysed and rank-weighted needs. This VCS contains a context description, the Rank-weighted (pale-blue) Needs (orange) for this context and a list of suggested Value-Drivers (olive green) that usually correspond to system characteristics that are expected to particularly contribute to stakeholder value * Need: Both the A/C itself and the enabling product need to be perceived as environmentally friendly. * Rank-Weight: 75/100 * Value-Driver: Green Fuel * Value-Driver: Aircraft Resistance * Value-Driver: Electricity Consumption * Need: The A/C needs to be perceived as setting a new standard in terms of entertainment (both on ground and in flight). * Rank-Weight: 82/100 * Value-Driver: Bandwidth * Value-Driver: Wifi Availability * Value-Driver: Electricity Availability .. figure:: /objects/images/vm_ea_needs_rankweight.png :scale: 100% Stakeholder needs are rank-weighted in context with value drivers The Needs can be part of many strategies, and have different rank-weight for each strategy. Therefore the rank-weight and value drivers for the Need are in the context of the strategy. As a relationship cannot have three connections, an "assignment" object is used which points to the Need, the Rank-Weight (or Value-driver) and the context (VCS). To help extract this information, additional services are specified so that the Rank-Weights (or Value-Drivers) are returned for a given Need and VCS. See |SysML - Value Creation Strategy| for more details ===================================================================================== 4. Quantified Objective Hierarchies with targets for analysed and rank-weighted Needs ===================================================================================== The next phase of the value analysis is to assign Quantified Objectives and Targets that are expected to fulfil the Needs in the context of the Value Creation Strategy [VCS] * Need: Both the A/C itself and the enabling product need to be perceived as environmentally friendly. * Rank-Weight: 75/100 * Value-Driver: Green Fuel * Quantified Objective: Enable Use of Bio fuel * Target: Fuel Green-ness indicator : Maximise * Value-Driver: Aircraft Resistance * Quantified Objective: Reduce drag resistance to Cr < xy * Target: reduce drag resistance : Reduce * Value-Driver: Electricity Consumption * Need: The A/C needs to be perceived as setting a new standard in terms of entertainment (both on ground and in flight). * Rank-Weight: 82/100 * Value-Driver: Bandwidth * Quantified Objective: Provide Bandwidth xy * Target: Provide bandwidth yx : Target=0.5Mbit/s * Value-Driver: Wifi Availability and... * Value-Driver: Electricity Availability * Quantified Objective: Ensure undisrupted availability of electricity * Target: ElectricityAvailabilityInCabin : Target=100% .. figure:: /objects/images/vm_ea_QuantifiedObjectives.png :scale: 100% Quantified Objectives and Targets assigned to Needs and Value Drivers The permutations for these objects are extensive: * A single Quantified Objective can fulfil more than one Need in a single VCS. * A single Quantified Objective can fulfil the same Need in different VCS. * In both the cases above Quantified Objective can point to the same, or different Targets As explained above, this means assignment objects are needed to accommodate the three relationships, and as above there are services to help extract the information. For example a Quantified Objective can return the Needs it is fulfilling given a VCS context. Similarly a Need can return the Quantified Objectives that fulfil it given a VCS context. See |SysML - Value Creation Strategy| for more details ..note:: The Value Drivers for the Needs and the Quantified Objectives are not in the context of the VCS. =============================================================================== 5. Value Creation strategy for analysed and rank-weighted Quantified Objectives =============================================================================== As well as applying a Rank-Weight to the Needs, it is also possible to apply a Rank-Weight to the Quantified Objectives fulfilling those Needs. Because the Needs fulfilment is in the contexts, then the Target is in the context of the fulfilment. As described in step 4. above, the permutations and associated services for these objects are extensive: * A single Quantified Objective can fulfil more than one Need in a single VCS. * A single Quantified Objective can fulfil the same Need in different VCS. * In both the cases above Quantified Objective can point to the same, or different: * Rank-Weights * Targets .. figure:: /objects/images/vm_ea_QuantifiedObjectives_rw.png :scale: 100% VCS with Rank-Weighted Needs fulfilled by Rank-Weighted Quantified Objectives with Targets The computation of the Rank-Weights can also be recorded as part of the VCS. The VCS is a specialisation of a Study, so all the |Study Management| behaviours apply. Therefore an Associative Model Network [AMN] can be created with Model-Instance(s) from which the Rank-Weight Instances can be extracted. The diagram below shows the minimum that can be used to show where the Rank-Weight Instances came from. This is touching on the rest of the Business Object Model, so all the other features that allow more thorough traceability to be recorded can be used (e.g. the method used to compute the values, who computed them, when were they computed, were there any assumptions made, etc). .. figure:: /objects/images/vm_ea_QuantifiedObjectives_RW_MI.png :scale: 100% Traceability of how the Rank-Weight instances were computed (yellow AMN and ModelInstance) ========================= 6. Value Models developed ========================= Similar to the end of Step 5. above, Model Instances in Associative Model Networks [AMN] can be used to compute the values for the Targets. Unlike the simple example shown above, this is likely to be a much more extensive AMN, or AMNs. The structure is completely business dependent, see |Study Management| for more details on what is possible. * |Correlation| can be applied to the Target Key Value Types. .. figure:: /objects/images/vm_ea_ProgrammeManagement_correlation.png :scale: 100% Correlation between two of the Target Key Value Types * A series of models can be used to compute the values for the Target Key Value instances as part of an |AssociativeModelNetwork| .. figure:: /objects/images/vm_ea_ProgrammeManagement_amn.png :scale: 100% A simple AMN for computing some of the Target instance values As explained in step 5. above, this is just touching on some of the things that can be captured as part of the Business Object Model, and many more possibilities exist. ======================================================================== 7. Requirements established based on rank-weighted quantified objectives ======================================================================== Finally, the requirements are established based on the rank-weighted, quantified root objectives and can be communicated in a third iteration VCS that summarises the updated context information and makes reference to the validated requirements .. figure:: /objects/images/vm_ea_Requirements.png :scale: 100% Requirements traced to Quantified Objective and Value Creation Strategy ---------------------------------------------------------- Example of Value Modelling using the 'Very Simple Example' ---------------------------------------------------------- * 1a. Stakeholder expectations are captured and validated .. figure:: /objects/images/vse_vm_ea_e_expectations.png :scale: 100% Expressed Expectations are captured using classes * 1b. Stakeholder expectations are validated .. figure:: /objects/images/vse_vm_ea_v_expectations.png :scale: 100% Expressed Expectations are Validated using classes * 2. Stakeholder needs identified, analysed .. figure:: /objects/images/vse_vm_ea_needs_analysis.png :scale: 100% Stakeholder needs are identified * 3. Value Creation strategy for analysed and rank-weighted Needs .. figure:: /objects/images/vse_vm_ea_needs_rankweight.png :scale: 100% Stakeholder needs are rank-weighted in context with value drivers * 4. Quantified Objective Hierarchies with targets for analysed and rank-weighted Needs .. figure:: /objects/images/vse_vm_ea_QuantifiedObjectives.png :scale: 100% Quantified Objectives and Targets assigned to Needs and Value Drivers * 5. Value Creation strategy for analysed and rank-weighted Quantified Objectives .. figure:: /objects/images/vse_vm_ea_QuantifiedObjectives_rw.png :scale: 100% VCS with Rank-Weighted Needs fulfilled by Rank-Weighted Quantified Objectives with Targets * 6. Value Models developed * 7. Requirements established based on rank-weighted quantified objectives .. figure:: /objects/images/vse_vm_ea_Requirements.png :scale: 100% Requirements traced to Quantified Objective and Value Creation Strategy .. sectionauthor:: |Judith Crockford| .. include:: /objects/documents/main/Keywords.rst