Business Requirement Fields

1. Description (required)

• What it’s for: The requirement statement — a clear, specific description of what the solution must do.

• What to include:

  • Write as a capability statement: “The solution must…” or “The system shall…”
  • One requirement per record — if a statement contains multiple capabilities joined by “and”, split it into separate requirements.
  • Be specific and testable: avoid vague language like “the system should be fast” or “users should find it easy to use”. Instead: “The solution must process invoice uploads of up to 500 records within 10 seconds.”
  • Focus on what the solution must do, not how it should do it — implementation detail belongs in design decisions, not requirements.

• Examples:

  • "The solution must allow Accounts Payable users to upload supplier invoices in CSV format containing up to 500 records per file."
  • "The solution must send an automated email notification to the approving manager when an invoice is submitted for approval."
  • "The solution must prevent a purchase order from being raised if the total value exceeds the user's delegated authority limit."

2. Customer Reference

• What it’s for: The customer’s own reference number for this requirement, if they maintain a separate requirements register.

• What to include:

  • If the customer has a requirements management tool, a numbered requirements document, or a contractual schedule that references requirements by their own IDs, record the cross-reference here.
  • This field ensures that the ArchRepo register and the customer’s register can be reconciled without ambiguity.
  • Leave blank if the customer does not maintain a separate requirements register.

• Example: REQ-0147 or Section 4.3.2

3. Priority (MoSCoW)

• What it’s for: The relative importance of this requirement to the overall solution.
• Options:

• Guidance: Apply MoSCoW from the business’s perspective — “If we delivered only the Must Haves, would the customer accept this solution?” The answer should be yes (however reluctantly). Should Haves are the next tier; Could Haves provide the stretch target.

4. Notes

• What it’s for: Additional context, background, or clarification for this requirement.
• What to include:
  • Background on why this requirement exists.
  • Constraints or edge cases that inform the requirement but do not belong in the main description.
  • Links to supporting discussions, meetings, or email threads.
  • Guidance for developers or testers that helps them understand the intent.

Relationships