Feature Requests

What Is a Feature Request in ArchRepo?

A Feature Request is a captured ask to add or change a feature in the solution. It is the entry point for any new piece of functionality the team is being asked to consider — whether the request comes from a customer, a project sponsor, an end user, or someone inside the delivery team.

Feature Requests sit alongside, and are distinct from, several neighbouring concepts:

The lifecycle runs roughly: captured → triaged → committed → delivered. Triage is where most Feature Requests live, and ArchRepo provides a dedicated Triage Board to keep that flow moving.

Why Track Feature Requests in an Architecture Repository?

Documenting Feature Requests in ArchRepo provides:

• Visibility of in-flight asks — a single register every architect, project manager, and stakeholder can look at to see what’s being considered, what’s been deferred, and what’s been agreed
• A shared triage flow — one place where business priority and engineering action are agreed together, rather than each side keeping its own list
• Impact captured on the architecture model directly — each request can be linked to the architecture items it would touch (requirements, scenarios, applications, data sets, APIs, and more). The architecture documents and the request register stay in step
• Supporting items hang off the request — tasks, risks, assumptions, issues and design decisions can be attached, so a single request can become the hub of the conversation about how to deliver it
• Cross-reference to customer change registers — the Linked CR field stores the customer’s own change-request number, so the two systems remain aligned without duplicating content

The Triage Board

The Triage Board is the default tab on the Feature Requests collection page. It is a two-dimensional matrix:

• Columns: the request’s Action (Pending Triage, Investigate, Defer to Backlog, Reject, Pending Change Board, Pending Commercial Agreement, Under Development, Delivered)
• Rows: the request’s Business Priority (Must, Should, Could, Won’t), plus a “No Priority” row for items that have not yet been prioritised

Each row is tinted with its MoSCoW colour (Must — tomato, Should — plum, Could — indigo, Won’t — grey) so the priority of a card is visible at a glance.

The toolbar above the board provides:

• A free-text search box that matches name, ref, description, and customer
• A Customer dropdown, Age filter, and Has open tasks toggle
• A density toggle (Comfortable / Compact)
• The Inbox button (see below)
• A New Feature Request button

The Reject and Delivered columns are hidden by default to keep the board focused on active work — click the + strip in the header to expand a hidden column, or − on a visible column to collapse it. Hidden state is remembered per project.

The toolbar stays pinned at the top of the page as you scroll; the column headers stay pinned at the top of the board panel; the row labels stay pinned on the left as you scroll horizontally.

The Triage Inbox

Inside the Inbox panel:

• Sort options — Oldest first (default), Newest first, or By priority. The third option is the “triage the triage list” lane: when time is short, sort by priority and work down from items that already have a Must / Should priority set.
• Filter chips — All / With priority / No priority. Mutually exclusive; use to focus on items that need priority set vs. items that need an action set.
• Inline selects — each row in the Inbox has a Priority dropdown then an Action dropdown. The recommended workflow is to discuss and set priority first, then decide on the action. The moment a non-Pending Triage action is selected, the card leaves the Inbox and appears in the matrix below — so setting the action is the last step.
• Hover preview — hover the row header to see the request’s full description, customer, priority, age, and open task count without leaving the panel.
• Tasks badge — links to the request’s Tasks tab, even when zero tasks exist, making it a one-click route into adding the first task.
• Edit pencil — opens the full edit dialog, where the Impacts picker and all the other fields live.

Editor Tabs

The Edit dialog organises a request’s properties across five tabs:

The Impacts picker on the Impact tab is the fastest way to link a request to the architecture items it would touch. Open the picker, choose any number of items across allowed types (requirements, scenarios, processes, rules, reports, applications, data sets, APIs, services, etc.), and save. The target items automatically gain a “Feature Requests” section on their Specification page listing every request that impacts them — keeping the request register and the architecture model in sync.

Action Values

Relationships

A Feature Request can impact, or be supported by, many other model items:

• Impacts — businessRequirement, nonFunctionalRequirement, transitionRequirement, businessScenario, useCase, businessProcess, businessRule, report, application, dataFlow, dataSet, api, stream, dataStore, uiComponent, service
• Has — task, risk, assumption, issue, designDecision, concept

Impacts relationships are best added via the Impacts picker on the Impact tab. Has relationships (tasks, risks, assumptions, etc.) are typically added directly on the request’s Specification page in the matching section.

Fields Reference

See Feature Request Fields for a description of each field and guidance on what to record.