Ngenaire Docs
Log inSign up free

Custom Requirement Attributes

Each requirement has a built-in set of fields (statement, category, priority, status, owner, …). Custom attributes let you extend that schema with per-project fields — a regulatory clause number, a safety integrity level, a customer-defined verification class — without changing the data model.

Location: Define → Requirements → Custom Requirement Attributes (/system-definition/requirements/attributes).

What an attribute defines

  • Name — the internal key the requirement uses (e.g. safety_level).
  • Display name — what users see in the requirement editor (e.g. Safety Integrity Level).
  • Type — the field's data type, which drives its input control and validation:
    • string — free text, with an optional regex pattern.
    • number — numeric, with optional min and max bounds.
    • enum — a closed list of choices.
    • boolean — a true/false toggle.
    • date — a calendar date picker.
  • Required — when on, every requirement must supply a value before it can be saved.
  • Description — a short note shown next to the field in the editor.

Validation

Validation rules — regex (string), min / max (number), and enum membership — are enforced on both create and update, on the server and mirrored in the UI. A value that violates a rule (or a missing value on a required field) is rejected before the requirement saves, so invalid data never lands.

Walkthrough

1. Define the attribute

  1. Open Custom Requirement Attributes.
  2. Click New attribute.
  3. Pick a clear name (lowercase, snake_case) and a display name.
  4. Choose a type and fill the type-specific options — enum choices, a string regex, or number min/max.
  5. Toggle Required if every requirement must supply this value.
  6. Save.

2. Set values on requirements

Once defined, the attribute appears on every requirement in the editor drawer and can be shown as a column and filter in the Management view. Open a requirement and fill in the new field; validation runs as you save.

3. Use the attribute downstream

Filter and group the Requirements views by the attribute, and surface it in exports and reports.

Tips

  • Pick the right type up front. Switching string → enum later means mapping existing free-text values onto the new choices.
  • Keep names short and stable. Names appear in exports and integrations; renaming them later breaks downstream consumers.
  • Mark something required only when it really is. A required field blocks saves on every requirement, including ones that predate the attribute.

Related