This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.
-- BrentFeather - 05 Mar 2010

We describe a generic “story” and variations for the use of an integration as described in this document.

1.1 Generic story

In this story, there are two main Actors, a Systems Engineer and a Hardware Engineer.

The Systems Engineer (working in RM tool):

· Analyses Stakeholder Requirements

· Authors System Requirements

· Derives Hardware Requirements (this is used as an example; the same applies for Software, Human Factors, etc.)

The Hardware Engineer (working in a PLM tool):

· Creates Hardware Design Spec (PDM)

· Creates Models (Design tool)

There is a Need to create traceability from Hardware Requirements to Hardware Design Specification.

There is a Need to follow (view?) traceability (initially single level) from Hardware Requirements to Hardware Design Specification.

1.2 Variations

We have identified the following high-level variations to this story:

· Hardware Design Specification created is in RM tool, so the interface then needs to enable creation of traceability from the Design Specification to Models.

· Hardware Engineer creates Hardware Requirements. We do not believe that this changes the underlying needs.

· Multiple levels of Hardware Design. It should be possible to generalize from above story, but we will not do this initially.

2. Glossary

BoM? : Bill of Materials, management of the BoM? is part of the functionality of a PDM system and the term BoM? is sometimes used for the information stored in the PDM system, though it is a subset

CI: Configuration Item – An item within the PDM context that is the fundamental structure unit that is designated for tracking changes to that item. Examples of CIs can include individual requirements, software, models, and plans.

Link: defined relationship between two items of information. Note that when we refer to following a link from one item to another in the following, this does not imply a specific direction for the link

OSLC: Open Services for Lifecycle Collaboration – a defined set of services to enable collaboration between tools using related types of information.

PDM user: User of a product data management system, typically a designer or implementer

RM user: User of a requirements management system, typically a requirements author or requirements manager

Requirement Set: A collection of requirements of similar nature or pertaining to the same function.

Impact Analysis: Process of identifying downstream affected product lifecycle artifacts as a result of a change.

Satisfaction: The characteristic of sets of information items that one set is necessary and sufficient to satisfy another

Traceability: The ability to link product requirements back to stakeholders’ needs and forward to corresponding product lifecycles artifacts. Traceability supports numerous product development activities such as change impact analysis, compliance verification, requirements verification and requirements validation.

Traceability analysis: Using traceability information to determine the items of information that are linked to specified items. Typically used for:

· Determining whether a “lower-level” set of information is necessary and sufficient to satisfy a “higher-level” set

· When a change is made in one set of information, determining which items in a related set might need consequential changes

3. Requirements

Based on the current situation the following are the main requirements for an IBM solution.

3.1 Key Capabilities

These requirements represent the most important capabilities from the perspectives of the stakeholders.

CORE1. From within the PDM tool, the PDM user shall be able to create/delete traceability between objects stored in the RM tool and CIs stored in the PDM tool.

CORE2. From within the RM tool, the RM user shall be able to create/delete traceability between objects stored in the RM tool and CIs stored in the PDM tool.

CORE3. From within the PDM tool, the PDM user shall be able to interrogate the configuration information associated with the objects within the RM tool.

CORE4. From within the RM tool, the RM user shall be able to interrogate the configuration information associated with the objects within the PDM tool.

CORE5. From within the PDM tool, the PDM user shall be notified of any changes made to RM objects that are traced to CIs

CORE6. From within the RM tool, the RM user shall be notified any changes made to CIs that are traced to objects within the RM tool.

CORE7. From within the PDM tool, the PDM user shall be able to display objects in the RM tool that are related to CIs, together with the relationship [[#_ftn1][[1]]]

CORE8. From within the RM tool, the RM user shall be able to display objects in the PDM tool that are related to requirements, together with the relationship [[#_ftn2][[2]]].

CORE9. From within the PDM tool, the PDM user shall be able to perform CRUD (Create/Read/Update/Delete) operations on objects and object sets within the RM tool. [[#_ftn3][]]

3.2 Architectural Requirements

ARCH1. Provide a solution that uses Open Services Lifecycle Requirements Management Spec (OSLC RM)

ARCH2. Access must not circumvent or violate security and licensing restrictions of either tool environment

ARCH3. The user interface for all capabilities shall be consistent with the interface of the native tool within which the user is working

4. Use Cases

The following high-level use cases are identified to be the most common and potentially the most useful in pursuing a POC or solution in this area. Our initial focus is on viewing and accessing the RM tool features from PDM tool environments because we have more control over creating this access than we do trying to access PDM data since each PDM tool interface might be different.

4.1 PDM User Use Cases

PDM tool user performs the following operations related to requirements management:

UC1. View requirement or requirement sets

UC2. Create requirement or requirement sets

UC3. Edit requirement or requirement sets

UC4. Link requirement set to a CI in PDM system

UC5. Follow link from a CI to a requirement or requirement set in the RM system

UC6. Display requirement or requirement set linked from a CI

UC7. Carry out traceability analysis

UC8. Decompose a requirement [[#_ftn4][[3]]]

4.2 RM User Use Cases

RM tool user performs the following operations related to product data management:

UC9. View CIs

UC10. Follow link from a requirement to a CI or CI set in the PDM system

UC11. Display CI linked from a requirement or requirement set

UC12. Create a requirements baseline and link It to high-level CI in the PDM system

UC13. Carry out traceability analysis from requirements to CIs


Topic revision: r2 - 16 Mar 2010 - 13:33:16 - BrentFeather
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback