I work as a business analyst in a software development firm. In my previous organisation, the development was done using waterfall and we wrote: "Business Requirement Documents" (BRDs).
In my current role, the team is using Agile Scrum and JIRA to write the user stories to capture the functional requirements etc.
My question is, how best to capture the non-functional requirements in JIRA as a story?
In a BRD this was pretty straightforward, add the non-functional requirements in its own section and make sure each requirement has a unique ID next to it.
ID:
001
Requirement:
The web app shall be compatible with the following browsers: IE11, Firework 50 etc…
But in Agile Scrum, and especially in JIRA, how should these be documented?
Best Answer
Non-functional requirements come in many forms, but they have one thing in common: The don't describe functional behavior of the system but rather put constraints on the design choices that you can make.
Non-functional requirements are ill suited to be expressed as user stories because user stories work best when they can be implemented once in a short timeframe (compared to the length of the entire project) and then be considered Done. After a story is Done, there should be no need to regularly revisit the story. For non-functional requirements, that doesn't work, because adherence to them needs to be maintained over the entire project. You can't say that you will look at browser compatibility only once during the project and ignore it the rest of the time.
For non-functional requirements that affect nearly all (functional) user stories, the best place to document them is as part of the Definition of Done.
For non-functional requirements that affect a relatively small subset of the functionality, you can make them part of the acceptance criteria of the relevant user stories. If this subset is still rather large for your taste (or it might grow in the future and you are afraid that you might miss some non-functional requirement on a future story), you can put the non-functional requirements in a document of some sort and reference that from the acceptance criteria of the relevant stories.
As for the format of the requirements themselves and a possible document to put them in, use whatever works best for you and your team.