Concepts

Project and specification

A project is a self-contained set of requirements with its own members and rights. Internally it is called a specification; you will come across that word where several projects are involved – relationships into another project, reuse and synchronisation. A project is either a requirement specification or a test specification.

Artifact, set and type

Everything in a project’s tree is an artifact: a requirement, a test case, a folder. Every artifact has a type – such as “System Requirement” or “Folder” – and the type decides which attributes it carries. In the interface an artifact is often simply called an element.

Some types only structure: artifact sets such as folders or modules. Only sets sit at the top level of a project, and everything else sits in a set.

Type schema

The type schema defines which types, attributes, choice values and relationship types exist. Every project is bound to one type schema once, when it is created; the administrator upgrades it to a newer version of that schema explicitly. Types, attributes and values are data and appear in both languages exactly as the schema names them.

The built-in schema brings attributes such as Id, Name, Description, Status, Priority and Verification Method, and the relationship types Satisfaction, Tests and Interface. See Type schema.

Relationship

A relationship (on the feature pages: link) connects two artifacts, directed from the source to the target, and has a relationship type. Relationships may also point into another project. They are what traceability is built from.

A relationship can become suspect when one of its ends changes – if its relationship type says so in the type schema.

Baseline

A baseline freezes the state of a whole project: every requirement in its revision, the structure, the relationships, the features and variants. See Baselines.

Revision and history

Every change to an artifact creates a new revision. The Version history in the detail panel shows every earlier revision with old and new value and can restore one.

Feature and variant

A feature describes a property of a product, such as “Market Europe” or “Hill hold”; features live in feature trees. A variant is a selection of features. Mirador derives which requirements apply in a variant from the requirements’ features. See Variants.

Review

A review judges a frozen state: reviewers give a verdict per requirement, in rounds, until the moderator closes it. See Reviews.

Filter, check and view

• A filter finds artifacts by conditions.
• A check is a filter with an expectation, such as “no hits”, and keeps its result as evidence.
• A view saves how a table or the traceability board looks. Filters and views are private or shared with the project.

Comment and attachment

On every artifact you can write, answer and resolve comments, and store attachments – files. Findings from a review are comments with their own marker.

Address of an artifact

Every artifact has its own address of the form /a/<UUID> on your Mirador server – the internal identifier, as in the UUID (do not edit) column of the Excel round-trip. Opening it takes you, after signing in, to the right project, the right place in the directory and the artifact’s details.