If you are an existing customer that has upgraded to the latest release, certain terms have changed. For a map of old terms to new terms, see Terminology changes map. This document uses the new terms.
The following terms and concepts are ordered so that information builds from the most simple terms and concepts to detailed explanations that combine terms and concepts.
Artifacts: A general term for the objects in a repository. Artifacts include products and objects that are created and maintained in other tools, such as Rational Team Concert™ work items and Rational® DOORS® requirements.
Products: Visually represent work your team is focused on. A product can be as large as a car or as small as a mechanical heart valve.
Products display in the Browse Products screen, in a tree view.

Teams can change the term products to a term accepted in their organization. After the term is changed and saved, and users refresh their session, the custom term is used in menus, dialog boxes, and messages.
For information about using products, see Working with products and Managing products.
Product grouping: Collects like products into meaningful groups for you or your team. You can group products in any way you want, by date (month, year), by milestone (beta, general), by feature (laser printers, inkjet printers), and so on. Product groupings are displayed in the Browse Products list box.
Property: A piece of descriptive information about a product. A property has a type, for example, name or value. For example, a product called dashboard might have a property name of material with a value of walnut.
Lifecycle Query Engine: An index of data that can be queried. The data is retrieved from data sources, such as products from Rational Engineering Lifecycle Manager, work items from Rational Team Concert, requirements from Rational DOORS, and other tools.
Link: Represents a reference to another artifact. The link might be stored in another tool, such as Rational Team Concert and Rational DOORS. The link might also be stored on a product.
Branch: A variant of a product. A variant is created when a team must change the same product in different ways or independently of each other. After branching a product, teams can make parallel changes.
For example, your team created a blood pressure cuff for adults and is ready to work on the same product for juveniles. The team would create a variant of blood pressure cuff and call it blood pressure cuff (:cuffsize=juvenile).
For information about creating and replacing branches, see Replacing a branch.
Branch dimensions: A branch dimension describes how a branch is unique by defining one of the features of the branch. A dimension consists of a name, such as cuffsize, and a value, such as juvenile, which displays after a product name: (:cuffsize=juvenile). A branch is defined by its unique set of dimensions. A dimension can be local to the product or shared within the product. You can create a local or shared dimension in the Check Out Branch dialog box or by using the Manage Branch Dimensions screen.
Version: A read-only version of a product or product hierarchy. When you create a product version, all the products beneath the selected product are read-only too. All products in the version are given the version name specified at check in.
Teams usually create versions to mark a milestone, for example, a weekly build, a beta release, or a general release.
The image shows the SuperCar product, which is currently at a milestone called sprint 4. Notice that Infotainment was updated in sprint 2 and did not change again, while Wheels was updated in sprint 4. A team that must roll back to a previous sprint of a child product, for example, Interior - sprint 3, could do so by performing a Replace Version operation.

Additionally, any user can freeze a version, which makes it non-modifiable unless you specifically make it modifiable again by performing an unfreeze operation or checking out a branch. Freezing a product version is useful if you must branch a product or if your product is at a point where no further development should be undertaken for a milestone.
For information about creating and replacing versions, see Checking in a version to capture a milestone.
Audit: An examination, in this case, of a product. The audit examines the changes made to the selected product and then displays the results in a table to the right of the products tree.

Additionally, you can view the audit history of a product. The Audit History screen visually presents all versions and branches of a product, including all property changes and added and removed links.
Each version is shown in a separate box in a vertical column layout. The latest version displays at the top of the column. When a product is branched, the branches are shown in a new column.

For information about viewing the audit log, see Showing who made changes to an artifact.
Audit history: A list of past events. The Audit History screen shows a visual list of past events performed on a specified product. The above example shows a version called SuperCar (:model year=2016). The audit history shows relevant metadata: the user who changed the product, what and when changes were made, and the name of added and removed products.
For information about audit history, see Viewing audit history.
Hierarchy: A pyramid-like ranking of products. Each level except the top, has one higher level, and each level except the bottom, has one lower level. Products are organized in a hierarchy most of the time, but not always.
Move: To physically relocate a product under a different product. You can move a product from one location to another in the product tree. For example, the Deluxe Rims product was in the Wheels (:Rims=16") product. The placement was incorrect, so Deluxe Rims was moved to a luxury car brand. Additionally, if Deluxe Rims had a hierarchy beneath it, the hierarchy would move with Deluxe Rims.
You can view the movement of products by looking at their audit history. The image shows that Deluxe Rims started out in Wheels (:Rims=16"), but was later removed.

To learn more about where Deluxe Rims was moved, you could compare versions, which would show you information about products that were added to and removed from the target product.
For information about moving products, see Manipulating products in the product tree.
Reuse: To use again. You can reuse a product in the same product and in other products. You can also reuse products multiple times in the same product, and the product you are reusing is the exact same one, just reused. When you reuse a product, the product includes its child products.
The image shows the SuperCar product with the Wheels product expanded. Under Wheels, notice that XB580 radial is one product used four times. The convenience is that if you change one reused product, for example from radial to studless, the change is propagated to all four uses.

For information about reusing products, see Manipulating products in the product tree.
Replace: To take the place of. Both versions and branches can be replaced by former or newer products. Replacing a version or branch is useful when a team must replace a current broken product with a previous working product.
For information about replacing products, see Versions and variants.
Views: Visual representations of the development lifecycle. The standard views are described in Sample views overview, including the V Process view.
V Process is a visual representation of the systems development lifecycle. Many systems development lifecycles exist: agile, waterfall, lean; the V Process is another methodology.
Visually, the information is divided between the two sides of the V. On the left side are tasks driven by product definition, such as creation of concepts, requirements, architecture, and design. On the right side are tasks driven by product testing and integration, such as system verification and validation, and integration, test, and verification. The verification and validation on the right of the V can be completed simultaneously with the product definition steps on the left side of the V.
Because teams participate in early product verification and validation, teams find defects in early development stages and therefore avoid the downward flow of defects. Finding defects early reduces the cost of fixing the defects. Additionally, early validation and improved communication between team members ensures that your quality standard is met.
The V Process is organization and product independent so each team can tailor the V Process for their product. The Shared Views page contains sample V Process views for hardware and software development.

For information about views, see Creating a view.
To understand how views are populated, read the next entry, "Queries." For information about queries and views, see How queries and views work together.
Queries: A way of retrieving information from the index. Artifacts (such as products, work items, requirements, design models, test cases), are retrieved from the Lifecycle Query Engine.
Administrators craft queries to embed in the custom views that they create. The queries pull data from the index and refresh the custom view with the appropriate artifacts. The retrieved artifacts can then be used to populate a view, run a report, perform an analysis, and more.
Several queries are available on the Shared Queries page.
For information about queries, see Creating and running queries.
Analysis: A detailed examination of artifacts. Analyze artifacts to explore and discover how they relate to one another.
Use the shipped impact analysis profiles to customize profiles for impact analysis diagrams that show relationships between artifacts. For example, if a child product in your product is recalled, you can run impact analysis on that child product to gauge the impact of replacing it.
The analysis output shows all dependencies, child products, and blocked artifacts that are related to the recalled child product.

For information about analysis, see Analyzing an artifact's relationship to other artifacts.
Reports: A physical performance measurement. Reports use data from the index to produce documents that track status and progress. You can use this information to manage and mitigate development risks, improve product quality, control product costs, and more.
For information about reports, see Running and printing a report to show the status of artifacts.
Requirements: Describe what users want from a product or service. A requirement can contain links to related artifacts that enhance its definition. For a detailed discussion of requirements, see Rational DOORS.
Design models: Help teams architect, design, and develop software and systems in an iterative and collaborative way. For a detailed discussion about design models, see Rational Design Management.
Test cases: Help teams plan, develop, execute, and report on their test plan to ensure that the quality standard is met. For a detailed discussion about test cases, see Rational Quality Manager.
Work items: Manage the tasks and issues that your team must address during the development cycle. For a detailed discussion of work items, see Rational Team Concert.