Business Requirements
What Is a Business Requirement in ArchRepo?
A Business Requirement is a statement of something the solution must do — a specific capability or behaviour required by the business. Business Requirements translate the high-level goals captured in Business Outcomes into a defined, testable scope for the solution.
In ArchRepo, Business Requirements are referenced using the prefix FR- (Functional Requirement) — FR-1, FR-2, and so on. The FR prefix reflects their nature: these are statements of functional capability, defining what the solution must do.
In many projects, Business Requirements are formally agreed with the customer or key stakeholders before delivery begins. They may form part of the contractual scope of the solution. Once signed off, changes to requirements typically require a formal change control process.
ArchRepo’s Customer Reference field supports this: if the customer maintains their own requirements register, the cross-reference can be recorded here.
Outcomes vs Requirements
Business Requirements sit below Business Outcomes in the traceability hierarchy:
- Business Outcomes describe what the business wants to achieve — the goals and desired changes (e.g., “Reduce invoice processing time by 60%”)
- Business Requirements describe what the solution must do to achieve those outcomes (e.g., “The solution must allow batch upload of invoices in CSV format”)
Requirements support Outcomes. Each requirement should be traceable back to at least one outcome. If a requirement cannot be linked to any outcome, it is a candidate for challenge: “Why are we building this? What goal does it serve?”
Priority
Each Business Requirement is prioritised using MoSCoW:
| Priority | Meaning |
|---|---|
| Must Have | This requirement is essential — the solution fails without it |
| Should Have | Important but not critical; should be delivered if possible |
| Could Have | Desirable; include if time and budget allow |
| Won’t Have | Out of scope for the current phase; may be revisited later |
Prioritising requirements with MoSCoW enables scope negotiation and phasing decisions — when trade-offs arise during delivery, requirements supporting a Must Have outcome should take precedence over those supporting a Could Have.
Categories
Requirements can be assigned to categories to group them by domain or theme. The Requirements by Category custom view organises the full requirement set into its categories, providing a structured view that is easier to review with stakeholders than a flat numbered list.
Acceptance Criteria
Two types of acceptance criteria can be linked to each requirement:
| Type | Purpose |
|---|---|
| Acceptance Criteria | Business-level criteria: defines how the business will verify that this requirement has been met |
| Implementation Acceptance Criteria | Technical criteria: defines how the delivery team will verify that this requirement has been implemented correctly |
The Requirements v Acceptance Criteria collection view provides a completeness check — any requirement without linked acceptance criteria has no defined test for success.
Collection Views
The Business Requirements collection includes three cross-reference matrix views:
- Acceptance Criteria — maps every requirement to its acceptance criteria; highlights requirements with no defined test criteria
- Apps — maps requirements to the applications that implement them; verifies that every requirement has been assigned to at least one application
- Releases — maps requirements to the releases they are scoped to; useful for planning phased delivery and tracking which requirements are in scope for each release
Fields Reference
See Business Requirement Fields for a description of each field and guidance on what to record.