Feature Request Fields

Feature Request fields are organised across five tabs in the editor: Details, Who, Business, Impact, and Notes and Comments.

Details

1. Item Name

• What it’s for: A short title that identifies the request.

• What to include:

  • Use a noun phrase that captures the essence of the ask: “Bulk update of records”, “Export to PDF”, “Sort by last updated”.
  • Keep it terse — long descriptions belong in the Description field.
  • Avoid restating the action (“Add ability to…”); the editor will render the type and ref alongside.

• Example: Bulk update of records

2. Description

• What it’s for: The narrative of what is being asked for — context, the originating need, and any constraints the requester has expressed.

• What to include:

  • Who asked, when, and what they were trying to do.
  • Any context that explains why — the underlying business need, not just the proposed solution.
  • Constraints (timing, customer, regulatory) that affect how the request should be handled.

• Example: "Today the daily wires report prints with an introductory paragraph describing protection limits. Neil Fowler asked for an option to suppress that text, because their Daily Wires / WON Supplements pack does not require that information."

3. Action

• What it’s for: Tracks where the request is in the triage flow.
• Options:

• What happens when you change this:
  • Setting Action to anything other than Pending Triage moves the card out of the Triage Inbox and into the corresponding column of the Triage Board matrix.
  • Setting Action back to Pending Triage, or clearing it, moves the card back into the Inbox.
  • On the Inbox row, the Priority dropdown sits to the left of Action specifically so the recommended order — set priority first, then action — falls naturally from left to right.

Who

4. Customer

• What it’s for: The customer or business unit on whose behalf the request was raised.

• What to include:

  • The customer / business unit name.
  • Leave blank if the request originates internally with no specific customer attached.

• Example: Network Rail – East Coast Route

5. Identified By

• What it’s for: The person (or team) who raised the request.

• What to include:

  • The name (or role + name) of whoever first surfaced the request.
  • Useful when the request needs to be discussed with the originator during triage.

• Example: Neil Fowler (Operations Manager)

6. Project Owner

• What it’s for: The person on the project team responsible for shepherding the request through triage and any resulting work.

• What to include:

  • The name of the project-side owner.
  • If unset, the request has no named owner — useful to spot during weekly reviews.

• Example: Gav Grayston

Business

7. Business Priority

• What it’s for: The MoSCoW priority assigned to the request from the business perspective.
• Options:

• Note: A request without a priority appears in the No Priority row of the Triage Board and the Inbox until prioritisation is agreed.

8. Potential Benefit

• What it’s for: A short description of the business benefit the change would deliver if implemented.

• What to include:

  • Concrete benefit — reduced effort, faster decision-making, regulatory compliance, revenue, customer retention.
  • Quantify when you can (“saves 30 minutes per day per dispatcher”).

• Example: "Removes manual editing of the daily wires PDF; saves ~30 minutes per dispatcher per day."

9. Can Go Live Without?

• What it’s for: A Yes / No / Unknown flag indicating whether the wider solution can launch without this feature.
• What to include:
  • Yes — go-live is not blocked by this request.
  • No — go-live is blocked unless this is delivered; in practice the priority should usually be Must.
  • Unknown or N/A — not yet determined or not applicable.

10. Is Funding Available?

• What it’s for: A Yes / No / Unknown flag indicating whether the change has funding agreed.
• What to include:
  • Yes — funding is agreed; the request can proceed when capacity allows.
  • No — funding needs to be agreed before commitment; often combined with Pending Commercial Agreement as the Action.
  • Unknown or N/A — not yet determined or not applicable.

Impact

11. Business Design Impact

• What it’s for: A description of how the request would affect the business design — processes, roles, information flows, the experience of business users.

• What to include:

  • The business-side consequences of delivering the request: who does what differently, what data flows change, what processes need updating.
  • Outright unknowns (“To be confirmed in triage”) if the impact has not yet been assessed.

• Example: "The dispatcher's role for producing the daily wires pack changes — no manual PDF editing required. Daily wires SOP needs updating to remove that step."

12. Impacts

• What it’s for: Direct links to the architecture items that this request impacts. Once linked, each target item gains a “Feature Requests” section on its Specification page back-pointing to this request.

• What to include:

  • Pick any number of items across the allowed types: business requirement, non-functional requirement, transition requirement, business scenario, use case, business process, business rule, report, application, data flow, data set, API, stream, data store, UI component, service.
  • Keep this list current — it is how the architecture model and the request register stay in step.

• Tip: It is often easier to set Impacts after a brief Investigate session, when the affected items are clearer. The picker supports multiple selections at once, so do them in a batch.

13. Technical Design Impact

• What it’s for: A description of how the request would affect the technical design — the architecture, the systems involved, the integrations, the data model.

• What to include:

  • Which applications, APIs, services or data stores would need changes.
  • Any architectural decisions that would have to be revisited.
  • Effort or complexity indicators (“trivial UI change” / “schema change with migration”).

• Example: "Reporting service: add a Boolean parameter to the daily wires generator. No schema change. UI option in the reporting screen."

14. Business Change Impact

• What it’s for: A description of the business-change consequences of delivering the request — training, communications, role changes, transition activities.
• What to include:
  • Training or comms needed for end users.
  • Transition activities (data migrations, parallel-running, hand-overs).
  • Stakeholder management implications.

15. Plan Timescales

• What it’s for: An indication of when the request is expected to be progressed or delivered.
• What to include:
  • A target window (e.g. “Investigate this PI; deliver in next PI”).
  • A specific milestone, increment, or release if known.
  • Leave blank if no timing has been agreed.

16. Linked CR

• What it’s for: A cross-reference to the customer’s own change-request register, where one exists.

• What to include:

  • A URL or identifier in the customer’s CR system.
  • Useful when commercial / contractual change is being tracked formally outside ArchRepo.

• Example: https://customer.example.com/cr/CR-2024-0142

Notes and Comments

17. Notes

• What it’s for: Free-form rich-text notes about the request — discussions, decisions, supplementary information that doesn’t belong in any of the structured fields above.

• What to include:

  • Triage meeting notes.
  • Email threads or chat snippets, summarised.
  • Open questions and their resolutions.
  • Anything else that helps explain how the team arrived at the current state of the request.

• Tip: Notes uses ArchRepo’s rich-text editor (BlockNote), so headings, lists, links and inline images are supported. For very detailed discussion threads, consider separating each session with a heading and date.