Item types & fields
How a requirement is structured — item types, core and custom fields, field data types, and admin-configured order.
Every requirement follows the structure of its item type — the definition of which fields it has, what kind of data each holds, and the order they appear in. Item types are configured in Administration, so the structure of a requirement matches your organization’s process rather than a fixed template.
Item types
An item type is the blueprint for a kind of record. The Requirements module may use one or several item types — for example to distinguish user needs from system requirements — each with its own fields and behavior. Defining item types is covered in the Administration section; here, the point is that what you see on a requirement is driven by its type.
Core and custom fields
Each item type combines core fields — the built-in fields every item carries, such as its identifier, title, and state — with custom fields your organization adds to capture exactly the information your process requires. Core fields are fixed; custom fields are yours to define.
Field data types
Fields are strongly typed, so each holds the right kind of data and is edited with the right control. Available types include:
- Text and rich text — short identifiers and titles, or formatted longer content
- Number — integer and numeric values
- Boolean — yes/no flags, edited as a checkbox
- Date and date-time — calendar dates and timestamps
- Picklist — a value chosen from a managed list (see picklists below)
- User — a person, chosen with a user picker
- Release — a link to a release
- Test steps — structured step/expected-result content
- URL — a validated web link
- Auto-number — an identifier the system assigns automatically
Picklists
Picklist fields draw their options from managed picklists defined in Administration. Centralizing the allowed values keeps data consistent across every record and avoids free-text drift — so a field like priority or category always uses the same controlled vocabulary.
Every field, in order
A requirement renders every field defined on its item type, in the order an administrator arranged them. There are no hidden fields by data type or control — the record you see is the complete, configured structure. Where a field should only appear in certain states, that’s governed by an explicit, admin-controlled rule rather than guesswork.