If you are trying to figure out how to write non-functional requirements and system rules that do not fit the standard user story format, you are dealing with one of the most practically awkward parts of requirements work. Things like availability thresholds, auto-generated identifiers, data validation rules, and background processing logic are all legitimate requirements. They just do not naturally have a user role at their centre, which means the usual “as a user, I want” structure either forces an artificial framing or obscures what the requirement is actually saying.
There are three formats that work well in practice. The right one depends on the nature of the requirement and what communicates most clearly to the people who need to act on it. I will walk through each one, explain when to use it, and give you a concrete example drawn from a real project situation, including the point where things got complicated.
Option 1: Capture It in the Acceptance Criteria
When the system behaviour you need to document occurs as part of a user-facing process, the acceptance criteria of an existing story is usually the most natural home for it. The requirement does not need its own story. It sits within the “then” clause of a Given-When-Then statement, describing what the system does as part of a broader interaction.
Take the example of an auto-generated application reference number. Rather than writing a separate requirement for this, it can be captured inside the acceptance criteria for the relevant story:
As a university student, I want to submit an online admissions application so that I receive an offer quickly.
Given that I have completed the form, when I submit the application, then the system:
- Saves the application record. The submitted data is stored against a new record in the admissions system.
- Displays an application summary. All submitted fields are shown back to the applicant for confirmation.
- Generates a unique eight-digit reference number. This is displayed to the applicant on the confirmation screen.
This approach works well when the system behaviour is tightly connected to a specific user interaction. It keeps the detail in context and makes it visible to both business stakeholders and developers without requiring a separate artefact. If you are already writing stories and acceptance criteria, this is the lowest-friction option for system behaviours that are bound to a user journey.
Option 2: Write It as a Story
Some non-functional requirements can be written as user stories, particularly those where the impact on the user is real and meaningful even if the behaviour itself is system-driven. System availability is a good example. Rather than documenting a dry constraint, you can write it as:
As a user, I want the site to be available 99% of the time I try to access it, so that I do not get frustrated and look elsewhere.
This format makes the business impact of the non-functional requirement visible, which matters when you are prioritising with stakeholders who might otherwise push back on anything that looks like a technical constraint they do not fully understand. If the consequence of not meeting the requirement can be expressed in terms of user experience or business outcome, the story format earns its place.
That said, this approach has limits. Not every non-functional requirement has a meaningful user-facing consequence you can articulate convincingly. Forcing it produces something that reads awkwardly and adds noise rather than clarity. Use this format when the user impact is genuine, not as a workaround for every system rule that does not fit elsewhere.
Option 3: Use the FDD Syntax
For requirements that are genuinely removed from the user, the Feature Driven Development (FDD) syntax is the cleanest option. Rather than forcing a system rule into a story format where it does not belong, FDD expresses it directly:
[action] the [result] [by/for/of/to] a(n) [object]
For the auto-generated application ID example: Generate a unique eight-digit identifier for the application record.
This is precise, unambiguous, and does not require a user role that would be artificial. It reads naturally as a system behaviour and translates directly into something a developer can implement and a tester can verify. For genuinely system-level requirements, FDD is usually the preferred approach because the format matches what the requirement actually is: a rule, not a goal.
A Worked Example: Where It Got Complicated
On a data migration project for a utilities client (Organisation A), I was documenting requirements for a batch processing routine that ran overnight to reconcile meter reading records against billing accounts. There was no user interaction involved at any point in the process. The system simply ran, matched records, flagged exceptions, and wrote results to a log. Straightforward enough to document in FDD syntax.
The complication came when the project sponsor reviewed the requirements list. She pushed back on the FDD statements, saying they “did not look like proper requirements” and that she expected to see user stories. This is a friction point I have hit more than once, particularly with stakeholders who have been through a recent Agile training course and have come away with the impression that user stories are the only legitimate format.
I ended up booking a thirty-minute session with her to walk through the formats and explain why forcing a user role onto a background batch process would produce something misleading rather than clear. I used the availability example to show her what a non-functional written as a story looks like when it works, and then showed her why the batch reconciliation requirement did not meet that test. She was not immediately convinced, but the development lead backed the position and we agreed on a documented approach: user stories for user-facing requirements, FDD syntax for system-level processes, with a short format guide added to the project wiki so the team had a shared reference.
What I took from that project is that the format decision is not just a documentation choice. It is sometimes a stakeholder management conversation, and it helps to have a clear rationale ready before you need it. If you are working in an Agile environment and want to understand how user stories and acceptance criteria fit alongside these other formats, the article on how to write user stories and acceptance criteria covers that ground in detail.
Choosing the Right Format
The three approaches are not mutually exclusive. Many backlogs use all three, and that is entirely reasonable. The decision rule is straightforward:
| Requirement type | Recommended format | Why it works |
|---|---|---|
| System behaviour that occurs during a user-facing interaction | Acceptance criteria within an existing story | Keeps the detail in context without creating unnecessary artefacts |
| Non-functional requirement with a clear and meaningful user impact | User story | Makes business consequences visible and supports prioritisation conversations |
| System-level rule or process with no meaningful user role | FDD syntax | Precise, testable, and does not introduce artificial framing |
| Constraint imposed by regulation, platform, or policy | FDD syntax or plain requirement statement | Constraints are not user goals, so story format adds ceremony without clarity |
What Non-Functional Requirements Categories to Cover
One of the most consistent problems I see with non-functional requirements is not the format used to write them. It is the categories that get missed entirely. When you are working through non-functionals, make sure you have deliberately considered each of the following:
- Security and access control. Who can access what, under what conditions, and what happens when access is denied or breached.
- Performance and reliability. Response times, availability thresholds, throughput under peak load, and recovery time objectives.
- Technology and platform constraints. Mandated infrastructure, browser compatibility, integration standards, or hosting requirements.
- Release and change management. How changes are deployed, what testing is required before release, and who approves production deployments.
- Support and maintenance. Service levels, support hours, incident response times, and who is responsible for ongoing maintenance.
- Compliance and data retention. Regulatory obligations, data handling requirements, audit trail specifications, and retention periods.
Working through these categories deliberately, rather than leaving non-functionals as a section to fill in at the end, is what separates a requirements set that holds up through delivery from one that generates assumptions and rework. For a fuller treatment of what belongs in each category, the non-functional requirements template on this site gives you a structured starting point. If you want to understand how non-functionals sit within the broader requirements hierarchy alongside business and functional requirements, the article on business vs functional vs non-functional requirements explains the distinctions clearly.
Prioritising Non-Functional Requirements
Non-functional requirements are frequently under-prioritised because stakeholders do not naturally think about them when working through a backlog. The same prioritisation frameworks apply, whether that is MoSCoW, MDO, or another method. The practical challenge is making the business impact explicit enough that stakeholders take the decision seriously.
Framing a performance requirement in terms of what happens to users when it is not met is almost always more effective than presenting it as a technical threshold. “The system shall respond within two seconds” lands differently from “users attempting to access the portal during peak hours will experience timeouts that send them to a competitor.” Both say the same thing. Only one gets the room’s attention.
The underlying principle across all three formats is the same: the requirement should be expressed in whatever form communicates it most clearly to the people who need to act on it. Format is a tool for communication, not an end in itself, and the test of a well-written non-functional requirement is not which column it sits in on a template but whether a developer can build to it and a tester can verify it.
Frequently asked questions
Do non-functional requirements need their own user stories in the backlog?
Not necessarily. Non-functional requirements can live in acceptance criteria, as standalone FDD statements, or as user stories depending on their nature and the team’s preferred approach. The risk with non-functional requirements is that they get missed entirely, not that they are in the wrong format. What matters is that they are captured somewhere visible and agreed upon.
What is the difference between a system constraint and a non-functional requirement?
A non-functional requirement describes a quality characteristic the system must exhibit, such as performance, availability, or security. A constraint is an imposed condition the system must operate within, such as a mandated technology platform, a budget ceiling, or a regulatory deadline. In practice they are closely related and often documented together, but the distinction is worth understanding when you are organising your requirements.
How do you prioritise non-functional requirements alongside functional ones?
The same prioritisation methods apply, whether that is MoSCoW, MDO, or another framework. The challenge is that stakeholders often do not naturally think about non-functional requirements when prioritising, so you need to make their business impact explicit. Framing a performance requirement in terms of what happens to users when it is not met is usually more effective than presenting it as a technical threshold.
Can FDD syntax be used alongside user stories in the same backlog?
Yes, and many teams do this routinely. There is no rule that requires every item in a backlog to follow the same format. What matters is that the team has a shared understanding of the formats in use and what each one is for.
What happens if non-functional requirements are left out of the backlog entirely?
They get interpreted by the development team, which means they get built to whatever standard the team assumes is acceptable. That assumption may be reasonable, or it may result in a system that is too slow, not sufficiently secure, or unable to meet a compliance obligation that nobody thought to document. The risk is entirely avoidable with deliberate, structured elicitation.
Try Ash, Your Virtual BA
If you are working through non-functional requirements right now and want to make sure nothing gets missed, Ash can help you do that systematically. The Ash BRD Writer works through non-functional requirements as a dedicated category, covering security and access control, performance and reliability, technology constraints, release management, support, compliance, and data retention, one subcategory at a time, so gaps do not appear later in delivery. Try Ash Virtual BA and complete your non-functional requirements section with confidence.
Further reading
- Beyond Functionality: The Critical Role of Non-Functional Requirements | Exclusive Articles for IIBA Members
- 10.30 Non-Functional Requirements Analysis
Written by Sam Cordes, founder of the Business Analyst’s Toolkit.