How do you include "global requirements"?

Question

I know it is best practice to split of your "global requirements". Which is something I do when documenting in Confluence.

However, when coming to grooming with the development team, I don't really know how to best incorporate these in to our User Stories in Jira. The obvious approach would I guess be to add them as acceptance criteria on each user story. But that defeats the purpose of making them global in the first place.

E.g: for a checkout project

Global: all markup must use the styles provided in the style guide

Req: Reset password - As a customer who has forgotten his password, I want to be able to reset my password, so that I can proceed to purchase

Obviously, when connecting the functionality to the provided design (html/css), the developers need to ensure it remains fully responsive (details in html/css). But I would prefer not to spell it out in each user story. How do I deal with this?

Answer 1

In my opition global requirements belong to the definition-of-done because you do not want to update every matching userstory when a global requirement changes

Answer 2

Well, you're not going to address UI standards in your User Story if the User is another machine.

You're going to have to decide if splitting out the "global requirements" is worth the risk of them not being applied to every user story. If you want the global requirements to be implemented in each story, and you want the tests that prove that those global requirements are satisfied, then I think you have one of two choices:

1. Include the global requirements that are relevant to each user story in the user story itself, or

2. Incorporate the global requirements by reference; i.e. "This user story shall conform to UI standard 47, and shall pass all of the acceptance tests specified in that standard."

Answer 3

When talking about requirements, you have multiple types of requirements. User stories often capture a combination of functional requirements (inputs, outputs, behaviors) and user characteristics (goals, desires, objectives of users of the software). But there are other things that are important to consider when capturing requirements - design constraints and quality attributes come to mind.

The difference is that things like design constraints and quality attributes live on throughout the design and maintenance of a system. With functionality, you implement the functionality once and you have it (barring a regression). However, you need to take care to always work within your design constraints and ensure the system has the quality attributes.

In your particular example, I would consider the use of a particular style guide part of the usability of the software system, and usability is a quality attribute. Your requirement to adhere to a specific style guide is a good requirement - it's cohesive, complete, likely to be consistent, atomic, current, clear, and so on.

There's no one right way to handle this.

The first thing that you need to do is to capture and control your guidance. For example, for a style guide, make sure it's available to your team. For performance requirements, put a table that relates functions to timing. For availability, fault tolerance, and disaster recovery, have a plan and test the plan by forcing the system into low availbility or failure modes to ensure the goals are met. A wiki with approrpiate change protection and revision history may be sufficient, or a more rigorous configuration management system may be required.

Tying these other requirements to your product may be as simple as developing test plans (there are JIRA test management plugins - Zephyr, TestFLO) that are executed against your documented standards. I wouldn't recommend putting your design constraints and quality attributes as standard JIRA tickets, since they don't follow the standard lifecycle of a user story, bug, or task. They need to be in a form that is searchable, referenceable, and persistent.

The last step is education - make sure that your development team is aware of the standards or these persistent requirements and how to design and do developer testing against them.