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.

The generic Value-Driven Design (VDD) Process Model

The high-level VDD process consists of the following sub-processes:

Stakeholder expectations are captured and validated.
Based on step (1), plus any additional available context knowledge, stakeholder needs are identified, analysed and rank-weighted.
A first iteration Value Creation Strategy including Value Drivers is developed for a specific context, based on the analysed and rank-weighted needs.
Hierarchies of quantified objectives with specific target values or target functions are developed based on the analysed and rank-weighted needs.
A second iteration Value Creation Strategy including Value Drivers is developed for the specific context, based on the analysed and rank-weighted quantified objectives.
Value models are developed and used for the Optimisation of early design concepts.
Requirements are established based on the rank-weighted, quantified objectives.

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:

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

Expressed Expectations are captured

../../../_images/vm_ea_e_expectations.png

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

Expressed Expectations are Validated

../../../_images/vm_ea_v_expectations.png

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

../../../_images/vm_ea_needs_analysis.png

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:

../../../_images/vm_e_l2_expectations.png

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.

../../../_images/vm_ea_e_l2_expectations.png

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

../../../_images/vm_ea_needs_rankweight.png

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%

../../../_images/vm_ea_QuantifiedObjectives.png

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

../../../_images/vm_ea_QuantifiedObjectives_rw.png

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).

../../../_images/vm_ea_QuantifiedObjectives_RW_MI.png

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.

../../../_images/vm_ea_ProgrammeManagement_correlation.png

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

../../../_images/vm_ea_ProgrammeManagement_amn.png

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