How do you manage WRICEF and requirements in Jira?

[Pallab_Empyra_com]

For teams delivering SAP projects in Jira, how are you keeping requirements, WRICEF objects, testing, and defects connected throughout the project?

We've seen a lot of different approaches, from custom issue types to spreadsheets and Marketplace apps, but I'm curious what has worked best in practice.

Is there a workflow or setup you'd recommend?

[Laura Marin - Millarum]

I’ve seen this exact pain point play out across dozens of enterprise teams, especially during SAP or ERP rollouts where WRICEF requirements are heavy.

The typical approach starts with a spreadsheet or a Confluence spec acting as the "elicitation form." In theory, it works. In practice, the moment dev teams start executing in Jira, the two systems start drifting apart:

• Individual contributors end up treating the Jira issue description as the real source of truth.

• Spec authors update Confluence or Excel after implementation decisions change, while Jira tickets remain untouched (or vice versa).

• Teams end up blaming a "broken process," when in reality it's an architectural problem—forcing people to maintain two separate sources of truth.

How to solve spec drift in Jira: To handle WRICEF effectively without spec drift, Jira itself has to serve as both the planning tool and the living document, rather than offloading documentation to external sheets.

(Full disclosure: I’m on the team behind the Millarum PRD add-on)

We built Millarum PRD specifically to solve this disconnect. Instead of maintaining external spec sheets, it turns your Jira Epics, Initiatives in document sections, and WRICEF items (or any defined work item type) into a structured, navigable PRD document directly inside Jira.

A few key things that help keep Jira as the single source of truth here:

1. Live Execution Visibility: You can see whether a specific requirement section is drafted, in progress, or executed based on real-time Jira issue statuses.

2. Flexible Navigation: You can rearrange WRICEF categories or feature sections dynamically without losing issue links.

3. Built-in Quality Checks: It evaluates requirement text against INCOSE rules (for formal engineering specs) or the Connextra template ("As a... I want... So that...") to catch vague requirements before work even starts.

Whether you use an add-on or strict custom fields, the goal is always the same: never make your team look in two places to know what to build.