7

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?

5

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

  • Thanks k3b, I've not worked with DoD yet, but I might need to read up on it again and give it a shot. – WouterB Nov 30 '16 at 13:20
  • Read up on it, and I can see how this could work. In fact, a combination of me renaming my document to DoD and training the team might also solve it. The documentation you provided talked about a DoD document for a sprint. In my example, I would have a DoD for the whole project. Is this common practice/correct? Or are there any pitfalls? – WouterB Nov 30 '16 at 13:36
  • 1
    DoD defines rules what makes a changerequest/story complete. Just add an additional checkmark "code complies with <<link to your global requirement>>" to the DoD. Your userstory "Reset password" is not finished until "global requirement" is also verified for the story. – k3b Nov 30 '16 at 14:02
3

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."

  • Referencing might be an option, but is really just another way of duplicating the same thing. If I can get away without it, I would still prefer that. I believe @ThomasOwens answer below might be a good place to start. – WouterB Nov 30 '16 at 13:19
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.

  • I will have a look at those Jira plugins you mentioned, but I like your post in general as it aligns with my current way of working. I am just struggling to see how I can make it 100% clear that those non-functional requirements and global requirements are included in everything that is being developed. It sounds like a combination of documentation, communication and testing would do the trick. – WouterB Nov 30 '16 at 13:17
  • @WouterB And don't forget the definition of done like k3b's answer points out. Reference quality attributes and design constraints there. – Thomas Owens Nov 30 '16 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.