Jira project customisation requirements gathering template

[#1]

Dear Community Members,

I would like to share my insights and experience on putting together a template for gathering Jira project customisation requirements.

As a Site Administrator, I often find myself in meetings discussing Jira customisation requests from our organisation's users. During these sessions, I clarify the aspects that can be customised and those that cannot, urging them to provide detailed requirements following the initial overview.

This requires me to have multiple connects with them to make sure that the requirements are complete and well understood.

Since implementing a templated approach to gather requirements, I have significantly reduced the time spent in these interactions. While we still engage in multiple discussions, there has been a noticeable time-saving benefit.

---

Below are some templates that I frequently use and share with the end users:

Issue Type requirement gathering:

What is an issue type?

An issue type in Jira is a way to categorise different types of work or tasks that need to be tracked. Eg., Task , Bug , Improvement, Change request, Service request.

Why/when to use a new issue type for the project?

Not all the types of work necessarily need their own issue types. For example, functional testing, technical testing, sanity testing etc can still be created under an issue type called ‘Test’ and have then categorised with a field named “Test type” to understand what type of test it is, provided, they all follow the same workflow steps and have the common fields for use.

If Functional testing needs different set of workflow statuses or fields on screen than the “Test” issue type which is in use, then it is good to handle “Functional test” as a new issue type with it’s own workflow and field screens.

Issue type name	[Anchor/Link to workflow requirement]	[Anchor/Link to screen requirement]

---

Workflow requirement gathering:

What is a workflow?

A workflow in Jira is a set of statuses and transitions that an issue moves through during its lifecycle.

Below is a text template describing the requirement.

You can also add an additional workflow diagram to clarify further ( even a hand drawn and photo clicked is enough as long as it helps explanation better 🙂 )

Template with example data filled:

From Status	To status	Transition name	Should specific data to be collected during transition? [yes/no]	Details about fields to collect those data [transition screen fields]	Whether any of those fields be mandatory to be filled?	If you have advanced requirements on any automated actions during the status change or conditional visibility of the transition, please summarise them
[create operation]	Open	[create operation]	[create screen]	[create screen]
Open	In progress	Start progress	no
In Progress	Done	Resolve	yes	“Solution” - customfield_1433unlimited text [Link to Reference fields from 'Export of all the custom fields in my Jira site]	Solution should be always must while resolve	Make sure that the 'remaining estimate' field is set to 0 when this status change happens

---

Screen & Field requirement:

What are Jira screens?

In Jira, screens are used to display and capture information when users interact with an issue. Screens determine which fields and information are shown to users during various operations like creating, viewing , editing, and transitioning issues.

Generally create , edit and view operations will have the same screens unless you have specific needs e.g., capture certain field values only during a particular status change, make a field not editable etc. If needed, discuss this with the Jira SME first and then update the requirements as advised by the SME.

Jira custom fields:

The List of existing fields in our setup is in [Link to export of all custom fields in our Jira site]

Please try and use custom fields from this existing list. Any exceptions for adding new custom fields will have to go through a change approval process.

Please note that field names and types cannot be adjusted as they are global but we can setup field choices to be specific to the project. Eg., Location dropdown field for Project A can list choices ANZ, Global, EU, North Americas while the same Location dropdown field for Project B list choices Office, Home, Factory.

Create/Edit/View screen requirements:

Field name	Field type	Existing field id (reference - [Link to export of all custom fields in our Jira site])	Optional or mandatory ?	Field choices	Help text	Notes
Location	Single select	customfield_14329	Mandatory	EU Americas ANZ	Please select one customer location for this topic.

---

Hope this is helpful and saves time! If you have feedback on what can be improved, happy to hear your insights!

Have a great day!

Thanks and regards,

Fazila ashraf