Type schema

The type schema describes what requirements look like for you: which artifact types exist, which attributes they carry, which values a choice field has and which relationship types are allowed. The administrator manages type schemas in the administration, in the Type Schemas section.

The built-in schema

Mirador comes with a schema that suits many projects:

• attributes such as Id, Name, Description (formatted text), Status, Priority, Rationale, Acceptance Criteria and Verification Method,
• types such as Folder and Module for structure, Stakeholder, System, Subsystem and Component Requirement, architecture elements and Test,
• the relationship types Satisfaction, Tests and Interface.

The status values there are: Draft, In Progress, Ready for Analysis, In Analysis, Ready for Acceptance, Accepted, Rejected and Retired.

Adapting a schema

• Add schema creates a new schema; Edit definitions changes types, attributes, values and relationship types, Save definitions stores them.
• Export and Import file… exchange a schema as a file – for example between test and production systems.
• Make default decides which schema is suggested for new projects; Deactivate takes a schema out of the choice.

Per relationship type you also decide here whether a change to source or target makes the relationship suspect. In the built-in schema this is off.

What applies

• Every save creates a new version. A project stays on the version it is bound to; under Projects in the administration it is moved up to the new version of the same schema. A project cannot be bound to a different schema.
• The data type of an existing attribute cannot be changed. Create a new attribute if a different type is needed.
• Removing deletes no data. Taking a definition out of the schema does not remove it from requirements that already carry it.

Types, attributes and values are data: in the interface they appear in both languages exactly as the schema names them.