How have you best modelled Non-Functional Requirements in Jira?

Kit Friend_kfjbwi

 

I’ve had a few conversations this week where Non-Functional Requirement modelling in Jira  come up - here’s a few of the options I’ve offered based on my experience. What approaches have you seen work best with teams?

1) (normally the best) Document shared NFR standards in Confluence, teams write in NFRs as part of individual Stories etc (as gherkin Acceptance Criteria normally)

2) a specific NFR field (again, normally best if articulated using gherkin)

3) an NFR-specific subtask type. If there’s a strong need to log or codify the NFRs this can help, but as with many scenarios it can result in the child becoming a bit remote from the parent

4) (the exception that proves the rule) if there is GENUINELY a scenario where an NFR should be delivered independently of a functional requirement, seperate it out into a task (normal standards for quality of writing, gherkin etc still apply)

Bill Sheboy

Hi @Kit Friend 

Although I agree with the idea of documenting shared non-functional requirements (NFR) in a human-readable location (e.g., in Confluence) independent from the work items (e.g., in Jira), that may lead to "out of sight / out of mind" behaviors, except for new team member onboarding, project liftoffs, and incident RCAs.

Perhaps use test automation to validate the shared NFRs in the pipeline environments, along with canaries running against production to check for trends and missed ones.  And as with your case #4, also add work items for any specific work needed to met shared or distinct NFRs.

With those, teams could move toward using commit-policy-based, test automation, ensuring no code is committed which would invalidate NFRs...thus requiring engineers to address them first.

Kind regards,
Bill