Skip to end of metadata
Go to start of metadata

Lifecycle Phases

Integration of Phases in SEA deliverables

Function export as Tree (FAT) and Requirement as Tree (RAT) integrate new concept of Phases introduced in arKitect 4.4

=> User will be able to export object Phases, export options …

Impact on document generation (RAT)


 Changes in generated RAT



Reminder about parameters:

  • Can change from a product application to another. E.g. engine power is a parameter to each engine.
  • Do not change in a given product application life cycle. E.g. Engine power can vary from one vehicle variant to another, but do not change on a given vehicle except as a consequence of aging. Number of cylinders will not change at all.
  • Variables change of value all the time during product life cycle. Variable can be e.g. a vehicle speed measure. A variable can be an input and output of a function. On the contrary, Parameters act as constants in a product lifecycle.
  • Parameters can be shared by many requirements, e.g. min vehicle operating temperature is an input of about every equipment in a vehicle.
  • Defining and refering parameters allows minimizing the number of requirements for describing a product line.
  • A single requirement can be instiantiated for each product variant.
  • Also, a single parameter can be shared by many requirements and so are its values in each variant. Introducing parameters is a guarantee for consistency of parameter values shared by several requirements. Changing one value will be transmitted instantaneously to all requirements sharing that value.
  • So introducing parameters is improving consistency and correctness of system model
  • Parameter values are also an input for simulation models. Consistency between system model and simulation models is improved with parameters

 A specific view will contain the hierarchy of parameters. In SEA it is the new view 1.6 The view contains containers for parameter organization



Variants for parameter values

  • Not all the variants are considered for parameters. Only those variants belonging to a variant folder named « Project Variants » will be considered for parameter values.
  • For each variant, the parameter may have a specific value.

  • Values in all variants are independant.


Parameters structure

A new treeview, « 1.6. Parametrization » has been introduced to gather all Parameters.

  • Parameters can be organized by Folder and SubFolder
  • « Default Group » Folder gathers together all newly created parameters.  
  • This Folder contains a folder per user in the workspace.  
  • When a user adds a new parameter, the parameter is created in the Default Group, in a folder named with that user name.
  • It is then the responsibility of users to organize the set of parameters.

Inserting parameters in description

All “desc” attributes have been converted to new Markup type that allow to add parameters


Editing markup attribute



Requirement description markup commands


Edit parameter values in objects description

Add new parameter


Add existing parameter



Variability of parameter display per variant

Parameter values revision

  1. Requirements can get new revision if and only if parameters to which they relate do have a revision
  2. The parameters table provide parameters and their values and values revisions in the different variants of interest
  3. When a parameter value is modified, a « * » is displayed in its revision



Impacted objects

Making revision of parameter values





Once new revision is performed, it is possible to look again at the parameters table. We see revisions in variant « Basic » are all white which means all values do have a revision in this variant


Making a revision of object with parameters

  • Revision is possible in one or several variants for objects refering to parameters. This means such an object may have different revision depending on variant, e.g. a parameter value may change in a variant and not in another variant.
  • An object under revision refering to parameter values will have independant revision for each variant. So these revisions may be different.
  • Object revision display in « no variant » is always the « max » of revisions in the different variants. If you want to see an object revision in a variant, you need to select that variant in the variant navigation.
  • Once an objet has parameter values in several variants, it will keep a version per variant even if all relations to parameters are removed.
  • Revision in variant view: selecting a variant, only the value in this variant is displayed in the wiki attribute.
  • It is not possible to get a revision of an object when a refered parameter value has been modified and has no revision yet.


Revision of a requirement with parameters.




Search of objects impacted by a parameter



Requirement Management

Functional Chains for Requirement Management

  • A new treeview «  2.c Requirements traceability chains » is available on SEA 6.2.
  • This view allows to create a Flow Chain with Requirements, Stakeholder, enabling system.
  • It allow to create a restricted view in order to refine external needs into STR requirements and then into system concepts.


Impact Analysis based on Functional Chains

  • The new mechanisms allows building automatically functional chains to understand what’s around an object in a model
  • This is performed in all dimensions:
    • from any type of object requirements, functions, data, components….)
    • at any depth (1, 2,…All)
    • in any direction (forward, backward, both)





  • No labels