Somebody choosing a system writes two kinds of line without noticing the difference. A functional requirement says what the system must DO: raise a purchase order, alert the owner when a contract is 90 days from renewal, export the register. A non-functional requirement says how well it must do it, and under what conditions: how fast, for how many users, to what availability, with what audit trail, under whose data-residency rules. The distinction matters for exactly one reason on a selection: functional lines are usually answered yes or no in a demo, and non-functional lines are almost never answered at all unless you ask them as numbers. This page sets out where the line falls, what each kind of requirement decides once vendors are scored, and which free sheet on this site works the figure.
The difference between functional and non functional requirements, stated usefully
A functional requirement is a behaviour with a subject and a verb: the system raises a purchase order; the system emails the owner at renewal minus 90 days; the system exports the requirement register as CSV. If you can demo it, it is functional. A non-functional requirement is a constraint on that behaviour: the export completes in under a minute for 10,000 rows; the renewal alert is delivered at 99.9% availability; the audit trail is immutable and retained for seven years; the data stays in the United States. The practical test is not the textbook one. Ask whether the answer to the line is a yes, a no, or a number. Yes and no are functional. A number, a rate, a duration or a jurisdiction is non-functional, and it is the kind of line that quietly decides whether the system you chose survives the second year.
Why the split changes the score, not just the vocabulary
Selections are lost in the non-functional column. A list of forty functional lines will separate two mid-market vendors by very little, because both were built for the same job and both will demo it. The separation lives in the constraints: one supports single sign-on and the other charges for it; one keeps an audit trail you could hand an auditor and the other keeps an activity feed; one restores in hours and the other in days. If the functional and non-functional lines sit in one undifferentiated list, the scoring is won by whoever has the most yeses, which is the same as saying it is won by volume of easy items. Split them into weighted groups instead, agree the weights before anyone demos, and the requirements scoring sheet on this site will show you what the weighting did to the result: on its worked example, two vendors that tie at 7.67 unweighted come out 7.50 and 7.45 once the groups are weighted.
Making non-functional requirements answerable
A non-functional requirement written as an adjective cannot be scored. "Fast", "secure", "scalable" and "reliable" all read well in a checklist and mean nothing in a demo, because every vendor agrees with them. Rewrite each one as a figure with a condition attached: a page loads in under two seconds on the reporting screen with a year of data; the system supports 40 concurrent users at month end; the provider publishes an availability target and credits against it; the data is held in the United States and the sub-processor list is published. Those can be answered, evidenced and scored, and the gaps they expose are the ones the coverage sheet prices in workaround hours. This is also where the cost of ownership figure moves: single sign-on, sandbox environments, API call limits and retention beyond the default are non-functional lines that arrive as line items on the quote.
Priority is a third axis, and MoSCoW is where it usually goes
Functional against non-functional says what kind of line it is; must, should, could and won't says how much it matters. The two are independent, and conflating them is the most common way a requirements list stops discriminating: teams mark every functional line a must and leave the non-functional ones unprioritised, which is exactly backwards for a system that has to last. The DSDM framework that MoSCoW comes from is explicit that Must Have effort should not exceed 60 percent of the total, and that a contingency pool of around 20 percent Could Have effort is what makes the plan credible. The same discipline works on a selection: if more than about three in five of your lines are musts, the list will not separate vendors, and the decision will be made by whoever demos last.
Questions people ask about functional and non functional requirements
Is a functional requirement always more important than a non functional one?
No, and assuming it is loses selections. Functional lines are usually answered yes or no in a demo and rarely separate two vendors built for the same job. Non-functional lines (availability, audit trail, data residency, concurrency, the cost of single sign-on) are where the separation lives, and they are the ones a demo will not surface unless you ask them as numbers.
What is the difference between functional and non functional requirements in one line?
A functional requirement says what the system must do; a non-functional requirement says how well it must do it and under what conditions. If the answer to the line is yes or no it is functional; if the answer is a number, a rate, a duration or a jurisdiction, it is non-functional.
How many of my requirements should be must-haves?
Fewer than most lists have. The DSDM framework MoSCoW comes from puts the safe ceiling at no more than 60 percent Must Have effort, with around 20 percent held as Could Have contingency. On a system selection the same ratio keeps the list able to discriminate: if you would not walk away from a vendor over a line, it is not a must.
Do I score functional and non functional requirements separately?
Score them in separate weighted groups, and agree the weights before you meet a vendor. Weights agreed after a demo describe the demo. The requirements scoring sheet on this site takes the group weights and each vendor's score out of ten and returns both the weighted and unweighted result, so you can see whether the scores or the weighting decided it.