What makes a good requirement?

A good requirement is clear and unambiguous (only one interpretation), testable (you can verify whether it's met), necessary (it traces to a real business need), feasible, and solution-free (it states what's needed, not how to build it). It should also be traceable — linked to the need it serves and to whatever is built to satisfy it. Requirements that lack these qualities are the root cause of most delivery failures, because design, build and testing all inherit their flaws.

What is the difference between functional and non-functional requirements?

A functional requirement describes what the system must do — a specific behaviour or capability, like 'produce a month-end exposure report by entity.' A non-functional requirement describes how well it must do it — qualities like performance, security, availability, or that a report must generate within a certain time. Finance systems need both: the functional requirements define the capabilities, and the non-functional ones (especially around controls, accuracy and performance at period-end) are often where the real risk lives.

Why should requirements not include the solution?

Because baking the solution into the requirement forecloses better answers and confuses what's needed with one way of meeting it. 'The system must let treasury see exposure by entity' is a requirement; 'add a report screen with these five columns' is a solution. Stating the need without the design lets the team find the best implementation, keeps the requirement stable if the design changes, and makes it testable against the need rather than against one pre-chosen build.

How to Write Good Requirements for Finance Systems

A good requirement states what the system must do to meet a real business need — clearly, testably, and without prescribing the solution. Good requirements are unambiguous, testable, necessary, feasible and solution-free; bad ones are the single most common root cause of delivery failure, because everything downstream — design, build, testing — inherits their flaws. A vague requirement doesn't get clearer as it moves through delivery; it gets built, wrongly, and the cost surfaces in UAT or production. Getting requirements right is the cheapest quality investment a finance-systems project can make.

What a requirement is

A requirement is a statement of something the system must do or a quality it must have, to satisfy a real need. It's the bridge between a shaped problem and outcome and the thing that gets built — and if that bridge is faulty, everything crossing it goes wrong.

The characteristics of a good requirement

Clear / unambiguous — one interpretation only. If two people can read it differently, they'll build it differently.
Testable — you can objectively verify whether it's met. (See below — this is the acid test.)
Necessary — it traces to a genuine business need, not a preference or a habit.
Feasible — it can actually be done within the constraints.
Solution-free — it states what's needed, not how to build it.
Traceable — linked to the need it serves and to whatever satisfies it.

Functional vs non-functional

Two kinds, both needed:

Functional — what the system does: "produce month-end exposure by entity."
Non-functional — how well: performance, security, availability, controls — "the position must generate within N minutes," "changes to bank details require four-eyes approval."

In finance, the non-functional requirements around accuracy, controls and period-end performance are often where the real risk hides — and the ones most easily forgotten.

The "testable" test

Requirements vs solutions

The most damaging habit is smuggling the solution into the requirement. "Add a screen with these columns" isn't a requirement — it's a design decision wearing a requirement's clothes. State the need — "treasury must see exposure by entity" — and leave the how to design. This keeps the requirement stable if the design changes, lets the team find the best implementation, and is the same discipline as separating problems from solution requests at intake.

Prioritize them

Not all requirements are equal, so prioritize — commonly must / should / could / won't (MoSCoW). This is what lets scope and fit-gap decisions be made on value rather than on whoever argued loudest. An unprioritized requirements list treats a nice-to-have as equal to a must-have — and that's how effort goes to the wrong places.

Traceability

Every requirement should trace backwards to the need it serves and forwards to what's built and tested to satisfy it. Traceability is what lets you answer "why are we building this?" (back to a need) and "did we build everything we agreed?" (forward to delivery and test). A requirement that traces to no need is gold-plating; a need that traces to no requirement is a gap.

What usually goes wrong

Ambiguity. Requirements read differently by different people, so the build is a coin-toss.
Untestable. "User-friendly," "fast," "robust" — wishes with no verifiable test.
Solution-prescribing. Design decisions frozen as requirements, foreclosing better answers.
Gold-plating. Requirements with no real need behind them, adding cost for nothing.
No prioritization. Every requirement equal, so effort ignores value.
Orphans. Requirements tracing to no need, or needs with no requirement — hidden waste and hidden gaps.

Write requirements that are clear, testable, necessary, solution-free and traceable; separate functional from non-functional; prioritize them; and keep them traceable both ways — and you remove the most common root cause of delivery failure before a line of anything is built. Requirements are what fit-gap assesses and testing verifies — so their quality sets the ceiling for everything that follows.

Part of the Finance Systems Delivery guide. See also problem statements vs solution requests and testing strategy for finance systems. The newsletter sends one finance-systems pattern every two weeks.