How to design a JIRA form based on Waterfall Model

[Ish]

I have a requirement where I need to modify a JIRA form to accommodate different phases of SDLC with fields being repeated.

For example, the requirement phase has start date, end date, assignee, etc. fields, and these have to be repeated with rest of the phases.

I know it is not possible to use a field twice, and we do not have the provision to create n number of fields separately  just for the sake of this. Because we will have to create more than 50 fields, and it will make the form lengthy, cluttered, and poorly designed.

I tried using a bundle field, however the major issue is reporting on it. When exporting the data in an excel spreadsheet using JQL, all the sub-fields inside the bundle field gets saved to a single column instead of different columns.

Is there any other solution to the problem, or any way to export the bundled field data in separate columns, each for a sub-field inside the bundled field?

[Nic Brough -Adaptavist-]

Sub-tasks.

You can co-opt subtasks to repeat parts of the lifetime cycles.

[Ish]

Could you please elaborate?

[Nic Brough -Adaptavist-]

Sub-tasks are part of their parent issue, so where you've got repeated cycles of things in your process, you can break up the parent into bits and repeatedly use it.

This is a slightly clunky example, as it's from before we really had Jira Software or Service Management and well before Insight, and they can help out in some ways.

I've got a Service (for want of a better choice, heck a Jira server).  That service lives in a DC and regularly goes through maintenance or upgrades, all of which have a similar cycle of downtime, start and end dates, assignees, and even a their own process.  So my Jira Service issue can accumulate a swathe of sub-tasks, each one representing a part of the overall lifecycle and being reportable and yet distinct.

[Ish]

I had the same idea in my mind, however I would have to create n number of fields which we do not have provision to create at the moment, and then there would be a total of m*o tasks for o number of parent tasks, where m being the sub-tasks.