TZ in tracker instead of Word for developers

Requirements in the Tracker Instead of Word: Optimizing the SRS Process

In corporate development, Word documents for Software Requirements Specifications (SRS) lead to manual decomposition of requirements into trackers like Jira. The client drafts the text, gets it approved, signs it off, and then the contractor manually rewrites each point. This creates bottlenecks: copy-paste errors, loss of traceability, and project delays.

Confluence solves part of the problem—it's a web-based platform for collaborative editing with comments and notifications. But even exporting to Word doesn't eliminate the manual labor on the contractor's side. Every paragraph of the SRS should be an atomic requirement with a unique identifier for referencing in code, tests, and reports.

The Optimal Workflow: Start in the Tracker

Shift to drafting the SRS directly within the tracker. The process looks like this:

Client creates requirement-tasks in the tracker ->
  Discussion in comments with notifications ->
  Setting statuses (accepted/rejected/infeasible) ->
  Generating the SRS in PDF/Word with task IDs ->
  Sign-off ->
  Import into the contractor's tracker

Each requirement is a separate task with fields: description, priority, acceptance criteria, system ID. Participants comment inline, avoiding endless email chains. After approval, a "Generate SRS" button creates a document with traceable links to the tasks.

Advantages:

• Traceability: Task IDs in the PDF allow for automated import.
• Collaboration: Real-time discussions without version conflicts.
• Automation: No manual data entry—tasks sync automatically.
• Consistency: Changes are blocked after the requirements are frozen.

Corporate Environment vs. Tenders

Within a company, the tracker is accessible to all—no signatures are needed. Freeze the requirements list, assign statuses, and the process is complete. Jira, YouTrack, or Redmine support custom workflows for this.

For tenders, the problem is the contractor's tracker is unknown. The solution is a unified SaaS tool with export to standard formats (CSV, JSON) for import into Jira/Redmine. Look for tools like ReqView or Polarion with APIs for document generation.

// Example task export in JSON for import
[
  {
    "id": "REQ-001",
    "title": "OAuth Authorization",
    "description": "Support PKCE flow",
    "status": "approved"
  }
]

This format allows a script to load requirements without retyping.

Practical Implementation

In 2018, we created SRS in Redmine as a hierarchy of tasks, exporting to Word via a plugin. Today, integrate:

• Jira Requirements: A module for user stories with export capabilities.
• Confluence + Jira Integration: Macros for syncing pages and tasks.
• Custom Scripts: Python with atlassian-python-api for PDF generation.

Ensure:

• Atomicity: One requirement per task.
• Versioning: Git-like change history.
• Permissions: Roles for client/contractor.

Key Takeaways

• Draft the SRS in the tracker to automate decomposition and ensure traceability.
• Use atomic requirements with IDs for referencing in code and tests.
• For tenders, choose SaaS tools with export to universal formats.
• In corporate settings, skip signatures—freezing statuses is sufficient.
• Integrate Confluence/Jira for a hybrid approach during transition periods.

— Editorial Team