Non-Functional Requirements in Jira: Where NFRs Live (and How to Write One)
Non-functional requirements like speed, security and uptime get lost because they are not features. Give a shop-wide NFR its own story with a number you can test, mark it NFR so one search finds them all, and put one-story rules in that story's acceptance criteria.
Step by step
What an NFR is
- NFRs in Jira. Non-functional requirements (NFRs) say how well the system works: how fast, how secure, how often it is up. They are not features, so they often get lost in a backlog. Here is where they live in Jira.
- Create. This is the backlog of an online shop. A rule that covers the whole shop gets its own story. Click Create.
- Pick Story. Click the work type field to open the list. Pick Story. The team then sizes and plans it like any other work.
Write the NFR
- Mark it NFR. Start the summary with NFR so everyone can spot it, then write the rule: NFR: Product pages load in under 2 seconds.
- Name the quality. In the description, first name the kind of quality. This one is about performance, so type Quality: performance.
- Give it a number. Then make it measurable. "Fast" is not something you can test. Type Measure: 95 out of 100 product pages load in under 2 seconds, with 500 shoppers online.
- How we test it. Then say how the team will prove it: Test: run a load test before every release.
- Create. Click Create to save the story.
Find them all
- In the backlog. The NFR now sits in the backlog with the other stories, so it gets planned instead of forgotten. Click it to open it.
- Give it a number. The number is right there on the story, so testers know exactly what passes and what fails.
- One search. Because every NFR summary starts with NFR, one search finds them all. Jira's search page runs this JQL: project = SCRUM AND summary ~ "NFR". The new story shows up in the results. As you add more NFRs, for security or uptime, they all appear in this one list.
Recap
- Where NFRs live. To recap: a rule for the whole system gets its own story marked NFR, with a number and a test. A rule for just one feature goes in that story's acceptance criteria.
Common mistakes
- Words like fast or secure with no number. Nobody can pass or fail "fast". Give a number and the conditions, like 95 out of 100 product pages in under 2 seconds with 500 shoppers online.
- Putting a shop-wide rule inside one feature's story. If page speed sits only in one story's acceptance criteria, it closes with that story and gets forgotten. Rules that cover the whole system need their own story.
- Leaving out the NFR prefix. The search looks for NFR in the summary, so a story without it drops off the list. Start every NFR summary the same way, with NFR:.
- No test written down. If the story doesn't say how it will be proved, the check never gets planned. Add a Test line, like a load test before every release.
When a business analyst uses this
In a requirements workshop, a stakeholder says the website must be fast. The business analyst turns that into an NFR story with a real number and a test. Before sign-off, they run the NFR search so stakeholders can review every quality rule in one list.
Questions people ask
Where do non-functional requirements go in Jira?
A rule for the whole system gets its own story, with a summary that starts with NFR so one search finds them all. A rule that only affects one feature goes in that story's acceptance criteria.
What are examples of non-functional requirements?
They cover qualities like performance, security and uptime. One example: 95 out of 100 product pages load in under 2 seconds, with 500 shoppers online.
How do you write a good non-functional requirement?
Name the kind of quality (for example, performance), give it a number you can measure, and say how the team will test it, such as a load test before every release.
