SDLC in Atlassian - Summer 2025 series

1 SDLC in Atlassian: Bring Your Own (requirements) Terminology

Jira isn't typically the first choice for managing requirements and, more broadly, your SDLC. Many people think of dedicated Application Lifecycle Management (ALM) systems or even good old Excel for handling requirements. These options often seem more obvious and fit better with standard practices for Software Development Life Cycle (SDLC). Primarily regulated or formal SDLC. Plus, Jira is missing some key features that are standard in dedicated ALM tools, like signature management and compliant release documentation. It's not clear how to use Jira for requirements management.

Even if you harnessed Jira's power as a platform, turning Jira into your SDLC platform does require a fair bit of skill and leadership. Users have to juggle many decisions about the tool itself while keeping the needs of their stakeholders in mind, leading to some tough trade-offs. It's easy to get overwhelmed.


I hear you!


Despite these challenges, Jira is a solid option for the longer term. I have seen this in action: using Atlassian for SDLC has the power to transform organizations. From isolated garage bands, teams come together to form an orchestra. Instead of cacophonies, organizations ascend on the path to perfect harmony.

Let's see why and how Jira can help with requirements management.

So, why manage your requirements in Jira?


Given all these points, several compelling reasons exist for considering using Jira to manage your requirements. Jira centralizes your teams and enhances collaboration and efficiency across different disciplines.


These are the key benefits:

  1. Power up collaboration: With requirements in Jira, product managers, business analysts, testers, and developers can finally work together with less time wasted on emails, meetings, waiting for responses, and chasing people. Analysts know exactly how their inputs are translated into product demos and final implementations, and no one is surprised by the scope and timing of releases. When technical challenges arise, it's easy to get all hands on deck to find the best solution for the product.

  2. Shared source of truth: All relevant information is consolidated and readily searchable within Jira and Confluence, which allows to quickly find whatever information you need without sifting through various files or documents. And even better, the information is always the most recent one that is available.

  3. Cost efficiency: Remove the hefty costs of specialized SDLC tools. When requirements are in Jira, all team members can access them without financial barriers.

  4. Use a robust and familiar platform: Transform your SDLC by integrating it into a widely adopted, mainstream business platform with a vast user base. By leveraging the power of Jira and Confluence as a platform, you gain the advantage of familiarity, as nearly every developer around the world has experience working with Atlassian tools. This means smoother collaboration and faster onboarding.

  5. Future-ready infrastructure: Being part of a leading platform means your requirements management will benefit from the latest technology advancements, such as AI capabilities, cloud integration, and continual updates, keeping your processes modern and efficient.

How Jira enables SDLC?


Integrating requirements management and the entire Software Development Life Cycle (SDLC) within JIRA hinges on key enablers.


The first is that Jira allows you to bring your own terminology (BYOT), workflow, and fields. You're not limited to just initiatives, epics, and stories. Instead, you can define user needs, user requirements, high-level specifications, design inputs, and design outputs—whatever terminology your team chooses to embrace. You have the flexibility to make Jira speak your language. This flexibility also extends to the relationships between different work items. For instance, you can establish connections such as "implemented by," allowing a user need or high-level specification to trace down to a functional specification. Consequently, a functional specification may then be linked to a story or a feature work, depending on the issue types or work item types you decide to incorporate. In Jira, this is a matter of simple configuration.


The second capability vital to this process is the ability to configure custom fields. Add custom fields with any names and types you require. Additionally, you can define workflows that align perfectly with your requirements management process, tailoring every step to your team's needs.Lastly, permissions in Jira and Confluence can as nuanced as you need them to be. For instance, you can designate that only product owners have the authority to modify requirements while allowing broader access for others to view them.


The third foundational element that facilitates requirements management in Jira is that each work item, including requirements, is uniquely identified by a specific key. This unique identifier allows you to link each requirement to any other work item and define the type of links that best reflect your vocabulary. These two core capabilities—the unique key assigned to each item and the ability to link it with other items in Jira—form the bedrock upon which we build the entire SDLC within Jira.


The starter roadmap to requirements management on Atlassian

How to manage the evolution of requirements?

Check out this article about how to manage the updating of requirements over the system life lifetime (The article is published on the Atlassian Community)

Consider managing your requirements in Jira?
Here's a cheat sheet to help you navigate the road ahead.

Adopt an iterative approach: you can proceed to the next step even if not all decisions or work are finalised. Let your ideal configuration emerge through experimentation.


Step

Who

Scope

1

Define requirements

  • Product managers

  • Business analysts

  • Regulatory quality assurance

Agree on those basic points:

  1. How do you call requirements? Name all the different types of requirements you need. Like: Design inputs, Functional specifications, etc

  2. What structured data is attached to each requirement. For example:

  3. What links do you need to maintain between the requirements and other Jira items.

  4. What is the most basic flow that a reqquirement goes through. Like: a requirement is opened (initiated)→ drafted → approved → obsoleted

  5. How does your requirements specification document look like?

2

Configure a Jira project

  • A user with Jira administrator access and some Jira administrator skills.

Using the input provided by the first step, configure a Jira project that supports your requirements.

Ideally, use a sandbox Jira and define an organisation managed project.
Sanbox - because you’ll want to experiment without fear. Organisation managed projects for two critical reasons:

  1. Eventually, you’ll need the full power of the platform. Team-managed projects don’t have enough configuration power.

  2. Organisation-managed projects can become templates- easily replcable across the whole organisation.

3

Make it real: Put in it some real or semi-real examples and try playing around.

  • Product managers

  • Business analysts

  • Regulatory quality assurance

Manually put some real requirements in Jira.
Verify that you have the fields you need (or maybe too many fields).

Try transitionning requirements through the workflow and link to other issues.

Play around, gather feedback, iterate on the configuration.

4

Create your first release document: Requirements Specifications

  • A user with Confluence administrator access and basic Atlassian administrator skills.

Install Snapshots of Jira Data into Confluence.

Create your first release document: Requirements specifications.

5

Next steps



6

Move your test management into Jira

We’ll cover this topic in our future articles


7

Connect your automatic tests with Jira

We’ll cover this topic in our future articles


8

Allign your SDLC with your Agile flow

We’ll cover this topic in our future articles


9

Validate your Atlassian site

This is strictly required in regulated environments. For example, when you operate under a Pharmaceutical GxP environment, or under ISO 13485.
We’ll cover this topic in our future articles


10

Move your configurations into your Atlassian production site.



11

Import your legacy requirements into the new system

We’ll cover this topic in our future articles


12

Onboard your teams to the new configuration

We’ll cover this topic in our future articles