Why you should manage your requirements in Jira

Why you should manage your requirements in Jira

Posted on Posted in Blog, Electronic QMS, JIRA

Many of my customers are devoted fans of both Jira and Confluence. They use Jira for tracking their development tasks, defects, and often times some of their business processes. For documenting technical specifications they’ll commonly use Confluence.

I am also a fan of both applications, but when it comes to managing requirement specifications within a formal framework of traceability, Jira is superior.

When I ask people why they chose Confluence for that purpose, the answers have more to do with perception than reality.

For example, they look at the layout of a Jira issue and assume it doesn’t have enough space to include all the necessary information. Or they don’t see how they can export from Jira a complete requirements document – one that has full paragraphs, rich text effects, images, and diagrams.

Because it appears as if they can’t develop detailed requirements in Jira, they turn to Confluence. This is where people make requirements management unnecessarily complicated.

Here are 6 reasons why you should use Jira to manage all of your requirements in one place:

  1. Jira’s text fields actually have plenty of space.
    The latest Jira versions have moved into the rich WYSIWYG editor experience, so nothing is preventing you from being as detailed as you want within a Jira issue text field. This includes headings, font effects, image embedding, and tables. Diagramming tools are also now available from third party apps, which even further extend options for rich content.
  2. Traceable items are better managed in Jira vs. Confluence.
    Making a requirement or a design element a Jira issue provides you the following two important features right off the bat:

    • It provides a unique key identifier. (Each Jira issue has a unique key by definition.)
    • It’s possible to link to other issues in the traceability hierarchy. (For example, you may either use existing Jira link types, such as ‘relates to,’ or define your own dedicated link type, such as ‘traces down to.’)
  3.  It allows much closer integration with other aspects of the development work. 
    From your stories to your test cases, you have one place to reference when creating and reviewing documentation.
  4. There are more reporting options.
    If you put your specs in Jira, it’s easier to pull a variety of reports, from a complete description of a particular item to a statistical analysis of a requirements status.
  5. The structure of a Jira issue encourages you to be clear and concise.
    This helps keep each spec item narrow in scope and leads to a more robust traceability.
  6. Complete requirements documents are easy to create – you just need the right plug-in.

When you’re ready to export a complete requirements document, there are several third party apps that generate attractive, flexible export layouts from Jira. I enjoy using PDF View Plugin for Jira and Xporter . I can also integrate each of them with a Continuous Integration (CI) cycle to generate reports automatically.

Here is how a Jira issue is exported to generate a user friendly, easy to read layout as a Word document. This export was generated using the Xporter plugin:

A JIRA issue is exported to generate a user friendly, easy to read layout as a Word document. This export was generated using the Xporter plug-in.

Customers often ask me what Jira issue type their specification item should be – a story or something else. My strong recommendation is to define a purpose-specific issue type. Put a User Requirement Specification in the Jira issue type called, ‘Requirement,’ and a Functional Specification in the Jira issue type called, ‘Functional specification.’ It’s as simple as that!

Jira has evolved, and it has all you need to manage your requirements in one place. If simplification is your goal, then using one program is a great way to get off on the right foot.