# Software requirements planning template

Use this document to agree what a software project should achieve, what users need to do, and how delivery will be accepted. Copy the blank sections and replace bracketed prompts. Delete anything irrelevant; expand areas where a wrong assumption would be costly.

Keep each requirement identifiable and testable. Use **Agreed** only after its owner accepts it; **Proposed** means a decision is pending; **Open** means information is missing. A technical constraint limits the solution. A design proposal suggests one way to implement it.

## 1. Document and decision owners

- Project/version/date: [ ]
- Business owner / delivery owner / acceptance owner: [ ]
- Contributors and affected teams: [ ]
- Current status and next review: [ ]
- Decision log location: [ ]

## 2. Problem and business outcome

- Current workflow and problem: [ ]
- Evidence: [observations, examples, or existing measurements]
- B-01 — Desired business outcome: [ ]
- Baseline: [value, source, measurement window; write “unknown” if unmeasured]
- Proposed target and deadline: [ ]
- Measurement method, exclusions, and owner: [ ]

Separate a hoped-for business improvement from release acceptance. Shipping the agreed features does not establish that the business target was achieved.

## 3. Users and permissions

| Role | Records it can see | Actions allowed | Actions denied | Owner/status |
| --- | --- | --- | --- | --- |
| [Role] | [Own/team/all; exceptions] | [Actions] | [Restrictions] | [ ] |

Cover overlapping roles, record ownership changes, leavers, administrator access, and whether authorization rules also apply to exports and API requests.

## 4. Scope and workflow

- Included in this release: [ ]
- Explicit exclusions: [ ]
- Starting event and prerequisites: [ ]
- Normal steps and resulting states: [ ]
- Rejection, cancellation, retry, and duplicate-submission behavior: [ ]
- Missing data, unavailable dependencies, and unauthorized actions: [ ]
- Manual fallback and responsible person: [ ]

## 5. Functional requirements

Describe behavior without prematurely choosing its implementation. Include relevant actors, conditions, results, and invalid paths.

| ID | Required behavior | Business link | Priority | Owner/status | Acceptance test |
| --- | --- | --- | --- | --- | --- |
| FR-01 | [When… actor can… system records…] | B-01 | [ ] | [ ] | TEST-01 |
| FR-02 | [Denied/failure behavior] | B-01 | [ ] | [ ] | TEST-02 |

## 6. Quality targets and technical constraints

| ID | Quality target | Workload/data context | Measurement and pass rule | Owner/status |
| --- | --- | --- | --- | --- |
| NFR-01 | [Numeric target] | [Users, dataset, environment, duration] | [Tool, boundary, percentile/error threshold] | [ ] |

Add applicable recovery, accessibility, security, maintainability, and support expectations with their own checks. “Fast,” “secure,” and “scalable” need definitions before acceptance.

| ID | Mandatory technical constraint | Reason and approving owner | Status | Verification |
| --- | --- | --- | --- | --- |
| TC-01 | [Required platform/interface/deployment boundary] | [ ] | [ ] | TEST-03 |

Record optional architecture choices separately: [proposal, alternatives, tradeoffs, decision owner]. Do not silently turn a preferred framework into an agreed requirement.

## 7. Data, integrations, and migration

- Data entities, required fields, relationships, and source of truth: [ ]
- Integration owner, credentials owner, contract, limits, and failure handling: [ ]
- Import mapping, duplicates, validation, rejected-row report, and reconciliation: [ ]
- Personal/sensitive fields and who can view or export them: [ ]
- Retention, deletion, backup treatment, and accountable owner: [decisions to confirm]
- Export format and responsibility for returning data at handover: [ ]
- Migration rehearsal, cutover window, rollback conditions, and approver: [ ]

## 8. Assumptions, risks, and open decisions

| ID | Assumption/risk/question | Consequence if unresolved | Owner | Due date/status |
| --- | --- | --- | --- | --- |
| D-01 | [ ] | [ ] | [ ] | [ ] |

## 9. Acceptance, release, and handover

| Test ID | Requirement IDs | Setup/action | Expected result | Evidence/approver |
| --- | --- | --- | --- | --- |
| TEST-01 | FR-01 | [ ] | [ ] | [ ] |
| TEST-02 | FR-02, NFR-01 | [Separate checks if needed] | [ ] | [ ] |
| TEST-03 | TC-01 | [ ] | [ ] | [ ] |

- Release prerequisites, known defects, and go/no-go owner: [ ]
- Monitoring, incident ownership, and rollback instructions: [ ]
- Source, accounts, configuration, documentation, training, and support handover: [ ]
- Business-outcome review date and measurement owner: [ ]

## 10. Changes after agreement

For each change record: [request ID, reason, affected requirement/test IDs, cost/time/scope impact, decision owner, decision, date]. Update the version and acceptance checks when a change is approved. Keep rejected or deferred decisions visible.

---

## Worked example: internal purchase requests

**Hypothetical planning example.** One organization needs employees to request purchases and assigned reviewers to decide them. The example contains no measured performance or business results. “Agreed” below describes an imagined project agreement.

- **B-01 — Proposed outcome:** reduce median submission-to-decision time to two business days within eight weeks of launch. Baseline is unknown. The operations owner will measure four weeks of the current process, then review the proposal. Measure submitted requests through their first approve/reject decision using the organization’s agreed business calendar; report still-pending requests separately.
- **Scope:** draft, submit, review, decision history. Exclude payments, accounting integration, and outbound email. A requester can read their own requests; a reviewer can read requests assigned to them. A person may hold both roles but cannot approve their own request.
- **FR-01 — Agreed:** a requester can submit their own draft containing a description, positive amount, currency, and a different assigned reviewer. Submission creates a pending request and timestamp. Invalid submissions remain drafts with field errors. Repeating the same submission must not create another request.
- **FR-02 — Agreed:** only the assigned reviewer may approve or reject a pending request; rejection requires a reason. Record reviewer, decision, and timestamp. Deny self-approval, unassigned reviewers, and repeated decisions without changing the existing decision.
- **NFR-01 — Proposed, untested target:** each operation must have API response p95 at most two seconds during ten steady-state minutes after five warm-up minutes. Every valid request must produce its intended result, with zero unexpected HTTP errors or timeouts. Use 50 concurrent virtual users with one-second pauses, 100,000 seeded requests, 500 users, and a 60% read / 30% valid submission / 10% valid decision mix. Measure complete HTTP response time at the load generator against the agreed staging environment. Report each operation separately and record environment capacity and dataset. Permission checks remain enabled.
- **TC-01 — Agreed illustrative constraint:** persist application records in the organization’s approved PostgreSQL instance. A queue or particular frontend framework remains a design proposal.

| Test ID | Traces to | Acceptance check |
| --- | --- | --- |
| TEST-01 | FR-01 | Submit valid data, retry the submission, then try missing/invalid fields. Confirm one pending request, one submission timestamp, and no invalid request. |
| TEST-02 | FR-02 | Exercise approval, rejection without/with reason, self-approval, an unassigned reviewer, and a second decision. Check permitted state changes and unchanged records on denial. |
| TEST-03 | NFR-01 | Run the specified synthetic workload; check every response's intended result and retain per-operation percentiles, unexpected HTTP error/timeout counts, and environment details. Each operation must pass the latency target and all requests must pass correctness checks. This is a planned test, not a result. |
| TEST-04 | TC-01 | Inspect deployment configuration and create/read a test record in the approved instance. |

FR-01 and FR-02 support B-01 by establishing an attributable submission and decision workflow. TEST-01–04 check the software; the operations owner separately measures B-01 after launch. Before agreement, resolve reviewer absence, reassignment, currency rules, record retention, and the business calendar as owned decisions.

## Companion guides

- [Business requirements vs functional requirements](https://nomadicsoft.io/blog/understanding-the-difference-business-requirements-vs-functional-requirements-a-comprehensive-guide)
- [Functional vs technical requirements](https://nomadicsoft.io/blog/functional-vs-technical-requirements-key-differences-in-technical-specification)
- [Bespoke software development](https://nomadicsoft.io/blog/the-ultimate-guide-to-bespoke-software-development-unlocking-custom-software-solutions)

[Download the original editable template](https://nomadicsoft.io/downloads/software-requirements-template.md)