InspiRD Suite Terminology

InspiRD Suite uses Platforms-Based Design to improve R&D management efficiency, enhance design reuse and drive technology insertion. To simplify access and enhance design reuse, InspiRD Suite builds a configuration/architecture to structure the R&D activities. R&D activities are divided into three domains representing technology, product or market development. Each are described below.

Terms Describing Domains / Views

  • Technology Domain: Technology domain aggregates R&D projects related to new technology development that spans across product lines.
  • Product Domain: Product Domain is used to categorize and aggregate R&D projects for developing new products and/or product lines that are delivered to customers.
  • Market Domain: Market domain is used to categorize and aggregate customer needs by market segments and sub-segments. It is possible to map products to market needs and build optimal solutions to support market needs. Depending on your implementation, the market domain may be called Missions or Indications etc. Please check with your super user for details.

Terms describing Architecture (Platforms)

Portfolio architecture or configuration is made of elements referred to as Platforms. Platform architecture for each domain is described below.

Technology Domain Platforms:

  • Technology Area Platform (e.g. Metals)
    • Technology Discipline Platform (e.g. Steel)
      • Technology Platform (e.g. Cast Steel)

Technology platform hierarchy can also be referred to using Parent/Child terminology. Technology Area Platform (e.g Metal) is a Parent of Technology Discipline Platform (e.g. Steel). Technology Platform (e.g. Cast Steel) is a Child of Technology Discipline Platform (e.g. Steel).

Technology Domain Platforms are numbered with the prefix T. Different levels of the hierarchy are denoted using periods. Hence, a Technology Area Platform (e.g. Metals) can be numbered at T1, a technology discipline platform (e.g. Steel) numbered as T1.1, and Technology Platform (e.g. Cast Steel) numbered as T1.1.1 etc.

Product Domain Platforms:

  • Product Line Platform (e.g. Cars)
  • Subsystem Level 2 Platform (e.g. Engines)
    • Subsystem Level 3 Platform (e.g. Blocks)
      • Subsystem Level 4 Platform (e.g. Liners)
    • …
  • Subsystem Level 2 Platform (e.g. Transmissions)
  • Subsystem Level 2 Platform (e.g. Frames)
  • …

Product platform hierarchy can also be referred to using Parent/Child terminology. For example, Product Line Platform (Car) is parent of Subsystem Level 2 Platform (Engines). Subsystem Level 3 Platform (Blocks) is a child of Product Line Platform (Cars).

Product Domain Platforms are numbered with the prefix P. Different levels of the hierarchy are denoted using periods. Hence, a Product Line Platform (e.g. Car) can be numbered as P1, a Subsystem Level 2 Platform (e.g. Engines) can be numbered P1.1, and a Subsystem Level 3 Platform (e.g. Blocks) can be numbered P1.1.1, etc.

Product Domain Platform Linking

A key advantage of InspiRD Suite is the ability to share subsystems and technologies across product lines. This sharing is achieved by linking Platforms together. We will use the following example to describe Platform Linking terminology: Product Line Platform P1 (e.g. Cars) has a Subsystem Level 2 Platform P1.1 (e.g. Engines) where P1àP1.1. Product Line Platform P2 (e.g. Trucks) has the linked Subsystem Level 2 Platform P1.1 where P2 àP1.1L1. Hence, engines are shared between Cars and Trucks.

  • Link Origin Platform: Parent of the platform being linked (P1, Cars)
  • Link Destination Platform: Parent where the link is being created (P2, Trucks)
  • Link Prime Platform: Platform being linked (P1à1, Cars à Engines)
  • Link Adjunct Platform: The new link created (P2 à1L1, Trucks à Engines)

Links are identified by a suffix L followed by a number indicating the number of the link e.g. P1.1L1 in the examples above.

Market Domain Platforms

  • Market Level 1 Platform (e.g. North America)
  • Market Sub-segment Level 2 Platform (e.g. USA)
    • Market Sub-segment Level 3 Platform (e.g. California)

Market platform hierarchy can also be referred to using Parent/Child terminology. For example, Market Level 1 Platform (North America) is Parent to Subsystem Level 2 Platform (Engines). Subsystem Level 3 Platform (Blocks) is Child to Subsystem Line Platform (Engines) Child.

Market Domain Platforms are numbered with the prefix M. Different levels of the hierarchy are denoted using periods. Hence, a Market Level 1 Platform (e.g. North America) can be numbered as M1, a Market Level 2 Platform (e.g. USA) can be numbered M1.1, and a Market Level 3 Platform (e.g. California) can be numbered M1.1.1, etc.

Terms describing Portfolio Elements

Technology Domain Projects

Technology Projects are only created at for Technology Platforms (e.g. Cast Steel for Engine Blocks)

Technology Projects are indicated by a colon (“:”) and a number following the source platform number. Hence, the Cast Steel for Engine Blocks project may be numbered T1.1.1:99 etc.

Product Domain Projects

Product project hierarchy can also be referred to using Parent/Child terminology. For example, Product Project (e.g. 2013 Midsize Car) is a parent of Subsystem Level 2 Project (e.g. 3l V6). Subsystem Level 3 Project (e.g Block for 3l V6) is a Child of Product Project (e.g. 2013 Midsize Car). Any project with no parents is referred to as a root project (e.g. 2013 Midsize car). Two children of a parent at the same level are referred to as siblings (e.g. 3l V6 and Chassis for 2013 Midsize Car).

Product Projects are indicated by a colon (“:”) and a number following the source platform number (P1:1 à P1.1:1). Hence, a Product Line project 2013 Midsize Car under Platform S1, Car, may be numbered P1:1.

Project numbers are assigned sequentially within the platform hierarchy level regardless of project location. As an example, if Product Line Platform P1 has 13 projects, the next project created in P1 will be P1:14. Similarly, if Subsystem Level 2 Platform P1.1 has 5 projects, the next project created in P1.1 will be P1.1:6. If that project was created as a subsystem project of P1:14 the project hierarchy numbering will be P1:14 à P1.1:6.

Project Linking Nomenclature

We will use the following example to describe Project Linking terminology: Product Line Project P1:1 has a Subsystem Level 2 Project P1.1:1 (P1:1 -> P1.1:1). Product Line Project S2:1 has a linked Subsystem Level 2 Project P1.1:1 (P2:1 -> P1.1:1L1)

  • Link Origin Project: Parent of the Project being linked (P1:1, e.g. 2013 Midsize car)
  • Link Prime Project: Project being linked (P1.1:1, e.g. 3l V6)
  • Link Destination Project: Parent where the link is being created (P2:1, e.g. 2020 Small Truck)
  • Link Adjunct Project: The new link created (P1.1:1L1, 2020 Small Truck à 3lV6)

InspiRD Suite allows several different types of links between projects:

  • Insertion: Link type insertion is used when development related to the child project was completed as part of the link prime project. The work done is reused without changes – hence it is just inserted into the Link Destination.
  • Transition: Link type Transition is used when development is incomplete in the prime project and will continue as part of the Link Destination project. Hence development is transitioned to Link Destination project.
  • Co-development: Link type co-development is used when link origin and destination projects will both contribute to development of the linked project.

Market Domain Projects

Market domain follows a similar approach to Product domain. Please see the section above for nomenclature reference.

Terms describing Project Continuation (for multi-phase or multiyear projects)

  • Prior Project: Previous project in a continuation chain
  • Successor Project: Next project in a continuation chain
  • Initial Project: First project in a continuation chain (only has a successor, no prior)
  • Final Project: Last project in a continuation chain (only has a prior, no successor)
  • Intermediate Project: Intermediate project in a continuation chain (has both a prior and a successor)

Continued projects are shown grouped together by default. A + sign is shown to the left of the continuation group to ungroup them. A – sign is shown next to the base continuation item to group them together. Projects cannot be edited while grouped together.

Terms describing relationship between Platforms and Projects

  • Product Line Platform (P1) is Product Line Project’s (P1:1) Basis Platform
  • Technology Platform (T1.1.1) is Technology Project’s (T1.1.1:1) Basis Platform
  • Product Line Project (P1:1) is Product Line Platform’s (P1) Instance Project
  • Technology Project (T1.1.1:1) is Technology Platform’s (T1.1.1) Instance Project

Terms describing Requirements

  • Source Project: Project for which the Requirement has been generated
  • Originating Requirement: A requirement that has not been derived from another requirement. For example, a customer requirement, a deliverable etc
  • Derived Requirement: A Requirement that has been derived from another requirement. Derived Requirement can be added to the source project, parent of source project, any sibling of source project or any child of the source project. A derived requirement can have further derived requirements as appropriate.
  • Linked Derived Requirement: A derived requirement that has been linked to another requirement (originating or derived).

Terms describing Risks

  • Source Project: Project for which the Risk has been generated
  • Source Requirement: The source requirement for a risk. In InspiRD Suite, all risks are risks of not meeting a requirement.

Terms describing Tests

  • Source Project: Project for which the Test has been defined
  • Source Requirement: The source requirement for a test. In InspiRD Suite, tests are defined to check if a requirement has been met.
  • Source Risk: The source risk for a test. In InspiRD Suite, tests are defined to check if a risk has been mitigated.
  • Test Session: Test Session is a set of tests conducted as per test plan and its results.

Terms describing Tasks

  • Source Project: Project for which the Task has been defined
  • Source Requirement: The source requirement for a task. In InspiRD Suite, tasks are defined to satisfy requirements.
  • Source Risk: The source risk for a task. In InspiRD Suite, tasks are defined to mitigate risks.
  • Dependent Task: A task that depends on another task to be completed.

Terms describing Skills

  • Skill Area(e.g. Engineering)
    • Fields (e.g. Electronics Engineering)
      • Skills (e.g. RF Electronics Design)

Skills hierarchy can also be referred to using Parent/Child terminology. Skill Area (e.g Engineering) is Field’s (e.g. Electronics) Parent. Skill (e.g. RF Electronics Design) is Field’s (e.g. Electronics) Child.

Skillsets are numbered with the prefix S. Different levels of the hierarchy are denoted using periods. Hence, a Skill Area (e.g. Engineering) can be numbered at S1, a Field (e.g. Electronics) is numbered as S1.1, and Skill (e.g. RF Electronics Design) numbered as S1.1.1 etc.

Terms Describing Teams

Team members are created for each Skill. Each Team Member is numbered sequentially for each underlying Skill. The Team member is identified as Skill number, followed by a “:” and the team member number. In the example above, a RF Design Engineer may be numbered as S1.1.1:20.