[{"data":1,"prerenderedAt":356},["ShallowReactive",2],{"blog-\u002Fblog\u002Fhow-to-write-good-requirements-for-finance-systems":3,"blog-surround-\u002Fblog\u002Fhow-to-write-good-requirements-for-finance-systems":337,"blog-related-\u002Fblog\u002Fhow-to-write-good-requirements-for-finance-systems":345},{"id":4,"title":5,"audience":6,"body":10,"cluster":302,"date":303,"description":304,"draft":305,"extension":306,"factCheckedAt":307,"faq":308,"featured":305,"language":307,"meta":318,"navigation":319,"order":320,"originalAsset":307,"path":321,"pillar":322,"primaryKeyword":323,"relatedProject":307,"releaseScope":307,"reviewCycle":324,"reviewStatus":325,"reviewedBy":326,"searchIntent":327,"seo":328,"sources":307,"stem":329,"tags":330,"type":335,"updated":303,"__hash__":336},"blog\u002Fblog\u002Fhow-to-write-good-requirements-for-finance-systems.md","How to Write Good Requirements for Finance Systems",[7,8,9],"business-analyst","product-lead","engineering-manager",{"type":11,"value":12,"toc":290},"minimark",[13,37,42,50,54,102,106,109,131,138,142,153,157,172,176,193,197,213,217,255,265,268],[14,15,16,20,21,26,27,31,32,36],"p",{},[17,18,19],"strong",{},"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 — ",[22,23,25],"a",{"href":24},"\u002Fblog\u002Fsolution-design-and-blueprint-for-finance-systems","design",", build, testing — inherits their flaws. A vague requirement doesn't get clearer ",[22,28,30],{"href":29},"\u002Fblog\u002Fagile-vs-waterfall-for-finance-systems-delivery","as it moves through delivery","; it gets ",[33,34,35],"em",{},"built",", wrongly, and the cost surfaces in UAT or production. Getting requirements right is the cheapest quality investment a finance-systems project can make.",[38,39,41],"h2",{"id":40},"what-a-requirement-is","What a requirement is",[14,43,44,45,49],{},"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 ",[22,46,48],{"href":47},"\u002Fblog\u002Fhow-to-define-a-measurable-outcome","shaped problem and outcome"," and the thing that gets built — and if that bridge is faulty, everything crossing it goes wrong.",[38,51,53],{"id":52},"the-characteristics-of-a-good-requirement","The characteristics of a good requirement",[55,56,57,64,70,76,82,96],"ul",{},[58,59,60,63],"li",{},[17,61,62],{},"Clear \u002F unambiguous"," — one interpretation only. If two people can read it differently, they'll build it differently.",[58,65,66,69],{},[17,67,68],{},"Testable"," — you can objectively verify whether it's met. (See below — this is the acid test.)",[58,71,72,75],{},[17,73,74],{},"Necessary"," — it traces to a genuine business need, not a preference or a habit.",[58,77,78,81],{},[17,79,80],{},"Feasible"," — it can actually be done within the constraints.",[58,83,84,87,88,91,92,95],{},[17,85,86],{},"Solution-free"," — it states ",[33,89,90],{},"what's"," needed, not ",[33,93,94],{},"how"," to build it.",[58,97,98,101],{},[17,99,100],{},"Traceable"," — linked to the need it serves and to whatever satisfies it.",[38,103,105],{"id":104},"functional-vs-non-functional","Functional vs non-functional",[14,107,108],{},"Two kinds, both needed:",[55,110,111,121],{},[58,112,113,116,117,120],{},[17,114,115],{},"Functional"," — what the system ",[33,118,119],{},"does",": \"produce month-end exposure by entity.\"",[58,122,123,126,127,130],{},[17,124,125],{},"Non-functional"," — how ",[33,128,129],{},"well",": performance, security, availability, controls — \"the position must generate within N minutes,\" \"changes to bank details require four-eyes approval.\"",[14,132,133,134,137],{},"In finance, the non-functional requirements around ",[17,135,136],{},"accuracy, controls and period-end performance"," are often where the real risk hides — and the ones most easily forgotten.",[38,139,141],{"id":140},"the-testable-test","The \"testable\" test",[143,144,146],"callout",{"type":145},"tip",[14,147,148,149,152],{},"The fastest way to spot a bad requirement: ask ",[33,150,151],{},"how would we test it?"," \"The report must be user-friendly\" — how do you test that? It's not a requirement, it's a wish. \"The report must generate within 30 seconds for a full month\" — testable, therefore real. If you can't describe the test, the requirement isn't finished.",[38,154,156],{"id":155},"requirements-vs-solutions","Requirements vs solutions",[14,158,159,160,163,164,166,167,171],{},"The most damaging habit is smuggling the ",[33,161,162],{},"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 ",[33,165,94],{}," 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 ",[22,168,170],{"href":169},"\u002Fblog\u002Fproblem-statements-vs-solution-requests","problems from solution requests"," at intake.",[38,173,175],{"id":174},"prioritize-them","Prioritize them",[14,177,178,179,182,183,187,188,192],{},"Not all requirements are equal, so prioritize — commonly ",[17,180,181],{},"must \u002F should \u002F could \u002F won't"," (MoSCoW). This is what lets ",[22,184,186],{"href":185},"\u002Fblog\u002Fhow-to-write-scope-in-and-scope-out","scope"," and ",[22,189,191],{"href":190},"\u002Fblog\u002Ffit-gap-analysis-for-finance-systems","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.",[38,194,196],{"id":195},"traceability","Traceability",[14,198,199,200,203,204,207,208,212],{},"Every requirement should trace ",[33,201,202],{},"backwards"," to the need it serves and ",[33,205,206],{},"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 ",[22,209,211],{"href":210},"\u002Fblog\u002Ftesting-strategy-for-finance-systems","test","). A requirement that traces to no need is gold-plating; a need that traces to no requirement is a gap.",[38,214,216],{"id":215},"what-usually-goes-wrong","What usually goes wrong",[55,218,219,225,231,237,243,249],{},[58,220,221,224],{},[17,222,223],{},"Ambiguity."," Requirements read differently by different people, so the build is a coin-toss.",[58,226,227,230],{},[17,228,229],{},"Untestable."," \"User-friendly,\" \"fast,\" \"robust\" — wishes with no verifiable test.",[58,232,233,236],{},[17,234,235],{},"Solution-prescribing."," Design decisions frozen as requirements, foreclosing better answers.",[58,238,239,242],{},[17,240,241],{},"Gold-plating."," Requirements with no real need behind them, adding cost for nothing.",[58,244,245,248],{},[17,246,247],{},"No prioritization."," Every requirement equal, so effort ignores value.",[58,250,251,254],{},[17,252,253],{},"Orphans."," Requirements tracing to no need, or needs with no requirement — hidden waste and hidden gaps.",[14,256,257,258,260,261,264],{},"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 ",[22,259,191],{"href":190}," assesses and ",[22,262,263],{"href":210},"testing"," verifies — so their quality sets the ceiling for everything that follows.",[266,267],"hr",{},[14,269,270],{},[33,271,272,273,277,278,187,281,284,285,289],{},"Part of the ",[22,274,276],{"href":275},"\u002Ftopics\u002Ffinance-systems-delivery","Finance Systems Delivery guide",". See also ",[22,279,280],{"href":169},"problem statements vs solution requests",[22,282,283],{"href":210},"testing strategy for finance systems",". The ",[22,286,288],{"href":287},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":291,"searchDepth":292,"depth":292,"links":293},"",2,[294,295,296,297,298,299,300,301],{"id":40,"depth":292,"text":41},{"id":52,"depth":292,"text":53},{"id":104,"depth":292,"text":105},{"id":140,"depth":292,"text":141},{"id":155,"depth":292,"text":156},{"id":174,"depth":292,"text":175},{"id":195,"depth":292,"text":196},{"id":215,"depth":292,"text":216},"intake","2026-07-23","How to write good requirements: state what the system must do — clearly, testably, without prescribing the solution. Bad requirements are why delivery fails.",false,"md",null,[309,312,315],{"question":310,"answer":311},"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.",{"question":313,"answer":314},"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.",{"question":316,"answer":317},"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.",{},true,4.5,"\u002Fblog\u002Fhow-to-write-good-requirements-for-finance-systems","finance-systems-delivery","how to write good requirements","annual","reviewed","Tan Gravam","informational",{"title":5,"description":304},"blog\u002Fhow-to-write-good-requirements-for-finance-systems",[331,332,333,334],"delivery","requirements","finance-systems","business-analysis","text","X00JnsVYxzxTaxpnKU_d67tDEzuYmKAtnk2PiGs-NAI",[338,342],{"title":339,"path":340,"stem":341,"type":335,"language":307,"draft":305,"children":-1},"How to Write a TMS RFP (Request for Proposal)","\u002Fblog\u002Fhow-to-write-a-tms-rfp","blog\u002Fhow-to-write-a-tms-rfp",{"title":343,"path":185,"stem":344,"type":335,"language":307,"draft":305,"children":-1},"How to Write Scope In and Scope Out","blog\u002Fhow-to-write-scope-in-and-scope-out",[346,350,353],{"path":347,"title":348,"description":349},"\u002Fblog\u002Fproject-intake-process-for-finance-and-engineering-teams","Project Intake Process for Finance and Engineering Teams","How a team receives, shapes and decides on incoming work before committing people — the stages, the fields that matter, and four honest decisions.",{"path":169,"title":351,"description":352},"Problem Statements vs Solution Requests","A solution request tells you what to build; a problem statement tells you why. Converting solutions back to problems is the highest-leverage move in intake.",{"path":47,"title":354,"description":355},"How to Define a Measurable Outcome","A measurable outcome states what will be true when the work is done, in a way you can verify — a result, not an activity. How to write one, and the traps.",1785182340813]