Revision: revised definitions, a worked invoice-export example and a practical specification outline.
Functional requirements describe required behavior. Quality requirements describe measurable qualities of that behavior. Technical constraints restrict the solutions you can use. “Technical requirements” is a broader label whose meaning varies between teams; it is not a universal synonym for either non-functional requirements or implementation instructions.
A useful specification distinguishes these categories and connects each requirement to evidence that would show it has been met. Below, one hypothetical invoice-export feature shows how to do that. The examples and numerical targets are planning illustrations, not measured results from a Nomadic Soft project.
Compare the requirement types before choosing technology
| Type | Question it answers | Invoice-export example |
|---|---|---|
| Functional requirement | What behavior is required, for whom and under which conditions? | An authorized finance user can export finalized invoices belonging to the selected workspace and date range. |
| Quality requirement | How well must the system perform, under an agreed workload and environment? | A specified proportion of export requests must finish within an agreed time at the stated load. |
| Technical or interface constraint | Which boundaries must the solution respect? | The file must match the finance system's approved CSV import contract. |
| Design decision | How does the team propose to satisfy the requirements? | Generate files in a background worker and store them in private object storage. |
The last row is a proposed solution, not automatically a requirement. A background worker might be appropriate, but the obligation is to deliver the agreed behavior and quality. If the customer mandates a particular platform for an established operational reason, record that as a constraint with its owner and rationale.
Terminology depends on context. NASA's technical requirements guidance includes functional, performance and interface requirements within technical requirements. A commercial team may instead use “technical specification” for its architecture and implementation plan. Define the term in the document rather than assuming the headings settle its meaning.
Non-functional requirements are often used to group quality attributes and constraints. They do not simply describe “how to code the feature.” A response-time target is an outcome to meet; an index or cache is a possible design response. Security also crosses categories: denying an unauthorized export is observable functional behavior supporting a wider security objective.
For the earlier question of why the feature belongs in the project, see business requirements versus functional requirements.
Start with the actor, record scope and output
Assume a small invoicing application serves separate business workspaces. Finance staff need a monthly CSV for an existing reporting tool. The first release exports invoice summaries; it does not change invoice amounts, send invoices to customers or replace the accounting system. Here is an example requirement set to discuss with the finance owner.
- F-01 — Access: the system permits an active member with the Finance Export permission to request an export for their selected workspace. A membership or identifier from a different workspace does not authorize access.
- F-02 — Selection: the export includes invoices with status Finalized and an issue date within the inclusive selected start and end dates. It excludes drafts, void invoices and records from other workspaces. These are invoice date fields, not conversion of creation timestamps into the browser's timezone.
- F-03 — Consistency: capture eligible records and their exported values at generation start. Later edits must not mix old and new values within that export. Display that snapshot time with the result.
- F-04 — Output: produce one row per invoice, ordered by ascending invoice ID, with invoice ID, issue date, currency and total. Use the approved file contract for column names, order, encoding, separators, decimal precision and date representation.
- F-05 — Empty and invalid input: an empty result produces a header-only file and a zero-row message. Missing dates or a start date after the end date produce a field-level error without creating an export.
- F-06 — Delivery: only the requesting member may download the completed file while still holding the required permission in that workspace. Recheck authorization before generation and download. Revoked access prevents delivery; possessing a file identifier alone grants no access.
These statements deliberately settle questions that “add an export button” leaves open. They also expose decisions still needed: maximum date range, maximum rows, file expiry, failed-job recovery and how long export history is kept. Give each unresolved item an owner and a decision date before accepting the scope.
For this example, an interrupted generation must show a failed state and make no partial file available. An explicit retry creates a new attempt with a new snapshot time. Distinguish that behavior from an empty successful result. Do not quietly return fewer rows and label the export complete.
Make quality targets measurable in a stated context
“Exports must be fast and reliable” cannot decide whether a delivery passes. A useful target says what is timed, how much work is involved, where the measurement happens and what counts as failure.
Illustrative Q-01: in a 100-request acceptance run, at least 95 requests must make a correct, complete 10,000-row file available within 30 seconds of server-side request acceptance. Submit five requests simultaneously, wait for that batch to finish, then submit the next five. Use the same approved dataset and environment profile for all 20 batches. Every request must complete correctly within 120 seconds; errors and requests still incomplete at that deadline count as acceptance failures.
The time includes any queue wait, generation and file storage, but excludes the user's download. Record hardware allocation, application and database versions, worker count, data distribution, other traffic and cache state in the environment profile before the test. Without those agreed details, Q-01 remains a draft target. Check its feasibility before promising it.
This target does not prove performance at a larger dataset or in production. A separate test should cover ordinary invoice browsing during exports if protecting that workflow matters. Similarly, a recovery requirement needs a stated failure, expected recovery state and verification procedure; “reliable” alone supplies none of those.
Separate mandatory constraints from provisional design
In this example, the existing reporting tool imposes a real interface constraint. Attach a versioned CSV contract and representative accepted and rejected files. “Must be CSV” is insufficient when one system expects decimal points and another interprets dates differently.
The team might propose background jobs, private storage and a database snapshot strategy. Record those choices in a design note, explain which requirements they address, and keep open choices visibly provisional. A framework name, microservices diagram or queue configuration does not establish that access rules, snapshot consistency or performance targets are satisfied.
Where an implementation choice becomes mandatory, record why. For example, an operations owner may require deployment within an existing supported runtime. Capture the supported versions, approval owner and review date. Distinguish that constraint from a developer's initial preference so future changes do not require undoing an accidental promise.
Turn the requirements into acceptance evidence
| Check | Test setup | Evidence to inspect |
|---|---|---|
| Record selection | Two workspaces; invoices on both date boundaries; finalized, draft and void records. | Exact expected invoice IDs and values appear once; excluded records never appear. |
| Access changes | Request as a permitted member; revoke permission before generation or before download in separate tests. | No file delivery after revocation; direct access with another workspace's identifiers is denied. |
| Snapshot consistency | Change eligible records after the documented snapshot point while generation continues. | All exported values match the captured version, without mixed states or missing rows. |
| Output and errors | Empty range, reversed dates, interrupted generation and a supported reporting-tool import. | Header-only success, validation error, failed state without partial download, and accepted complete file respectively. |
| Performance | Run the agreed Q-01 workload on the recorded environment. | Request timings, correctness results and failures establish whether all acceptance conditions passed. |
Compare outputs with an independently prepared expected result, not another invocation of the same export code. Keep requirement IDs, fixture versions and test results together. A screenshot can demonstrate a status message; it cannot establish workspace isolation or a load target.
NASA's requirement-writing checklist is useful for reviewing clarity, assumptions and verifiability. Apply that discipline proportionately: a small business application needs decisions people can check, not a large document written only to look formal.
Use a short software requirements specification
A software requirements specification, or SRS, can be a maintained document linked to your backlog. For a modest project, start with this outline and expand the parts carrying real uncertainty:
- Purpose and boundaries: intended users, desired outcome, included workflows and explicit exclusions.
- Terms and data: roles, record ownership, states, field meanings and sample inputs.
- Required behavior: numbered requirements covering normal paths, permissions and errors.
- Quality and interfaces: measurable targets, operating conditions, file or API contracts and mandatory constraints.
- Acceptance: requirement-to-check links, evidence, acceptance owner and unresolved decisions.
- Change record: approved versions, decision rationale and links to separate design notes.
Use the downloadable software requirements template as a starting point. Review it with the person performing the workflow and the engineer responsible for delivery. Changes to data scope or quality targets should trigger a review of cost, design and acceptance checks together.
If you are deciding whether a build is justified, our bespoke software guide covers that decision. For a defined project, our custom software development service explains how we scope selected engagements and agree delivery responsibilities.