Terms and definitions
When migrating data, it helps to understand data concepts and terms that are used in
IBM® Engineering Requirements
Management DOORS®
(DOORS)
and IBM Engineering Requirements Management
DOORS Next (DOORS Next). Some
terms are used exclusively in one application or the other. Other terms are used in both
applications, but their meaning varies in the context of each application.
Term | Common definition | DOORS | IBM Engineering Requirements Management DOORS Next |
---|---|---|---|
requirement | A condition or capability that a product or system must provide. This condition is typically derived from user needs and is stated in a contract, standard, specification, or other document. | Expressed as objects in models. | Expressed as artifacts. |
project | None. | A project is a specialized folder that can contain sub-projects, folders, modules, and artifacts. | A project area is a self-contained area for a team or specific project for security purposes. Members of a project area can view any artifact within the project area, non-members see nothing. |
folder | A container for subfolders, modules and artifacts. | Folders can also contain projects. | Projects that are migrated from DOORS are displayed as folders. |
module | A structured document that is composed of multiple requirement artifacts. Structure can be created in a module by modifying the order and hierarchy of the artifacts. | Same as common definition. | Same as common definition. |
collection | None. | Not applicable. | A container that is used to view or manage a group of related artifacts. |
artifact | A requirement or related entity such as text, a picture, or a table. | Requirement artifacts are created as objects in a module. | An artifact can exist as an independent entity in a folder and in modules and collections. Thus, artifacts can be shared in multiple contexts. |
attribute | A defined quality and values that can be assigned to an artifact. For example, an artifact might have a "priority" attribute with values of "high", "medium", and "low". In grid views, attributes can be displayed as columns or hidden. | Same as common definition. | Same as common definition. |
type | A data type that is applied to a artifact or attribute. | Types are specific to individual modules. They are copied when the same types and shapes are used across multiple modules. | Types are defined globally in a project area. Entire type systems are copied between project areas when reuse or standardization is required. |
link | A relationship between two artifacts. An abbreviated term for standard or internal links. | A bidirectional indication of dependency between two or more requirements in the same module or different modules. | A relationship between two artifacts or content within artifacts. Internal links can be applied to any artifacts in a project area. |
OSLC link | A pointer to an artifact in an external OSLC-enabled application. This includes links between DOORS Next and DOORS. | Same as common definition. | Same as common definition. |
external link | A URI or equivalent that points to a resource on another platform or application, such as an Internet web site. | Same as common definition. | Same as common definition. |
migration phases | Preparation, migration, and maintenance phases of data migration. | During preparation, essential migration data is identified; data is analyzed with migration metrics. Data might be modified for consistency. During migration, packages are created and exported. During maintenance, archival data is maintained with read-only permissions. | During preparation, business objectives and essential migration data are identified. During migration, packages are imported. During maintenance, imported data might be assigned to team areas with applicable security. |