跟踪器中的 TZ 代替 Word，适用于开发者

在跟踪器中撰写需求而非Word文档：优化SRS流程

在企业开发中，使用Word文档编写软件需求规格说明书（SRS）会导致需求被手动分解到Jira等跟踪器中。客户起草文本、获得批准、签署后，承包商需手动重写每个要点。这会造成瓶颈：复制粘贴错误、可追溯性丢失以及项目延误。

Confluence解决了部分问题——它是一个基于网络的协作编辑平台，支持评论和通知。但即使导出到Word，也无法消除承包商方面的手动劳动。SRS的每个段落都应是一个原子需求，具有唯一标识符，以便在代码、测试和报告中引用。

最佳工作流程：从跟踪器开始

转向直接在跟踪器中起草SRS。流程如下：

客户在跟踪器中创建需求任务 ->
  通过评论进行讨论并发送通知 ->
  设置状态（已接受/已拒绝/不可行） ->
  生成带有任务ID的PDF/Word格式SRS ->
  签署 ->
  导入到承包商的跟踪器

每个需求都是一个独立任务，包含字段：描述、优先级、验收标准、系统ID。参与者在线评论，避免无休止的邮件链。批准后，点击“生成SRS”按钮即可创建带有可追溯任务链接的文档。

优势：

• 可追溯性：PDF中的任务ID支持自动导入。
• 协作性：实时讨论，无版本冲突。
• 自动化：无需手动数据输入——任务自动同步。
• 一致性：需求冻结后，更改被阻止。

企业环境与招标场景

在企业内部，跟踪器对所有人员开放——无需签名。冻结需求列表、分配状态，流程即告完成。Jira、YouTrack或Redmine支持自定义工作流来实现此目的。

对于招标，问题在于承包商的跟踪器未知。解决方案是使用统一的SaaS工具，支持导出标准格式（CSV、JSON）以导入Jira/Redmine。寻找如ReqView或Polarion等具有文档生成API的工具。

// 用于导入的任务导出JSON示例
[
  {
    "id": "REQ-001",
    "title": "OAuth授权",
    "description": "支持PKCE流程",
    "status": "已批准"
  }
]

此格式允许脚本加载需求而无需重新输入。

实际实施

2018年，我们在Redmine中创建了SRS作为任务层次结构，通过插件导出到Word。如今，可集成：

• Jira需求模块：用于用户故事并具备导出功能。
• Confluence + Jira集成：宏用于同步页面和任务。
• 自定义脚本：使用atlassian-python-api的Python脚本生成PDF。

确保：

• 原子性：每个任务对应一个需求。
• 版本控制：类似Git的变更历史。
• 权限管理：为客户/承包商设置角色。

关键要点

• 在跟踪器中起草SRS，以自动化分解并确保可追溯性。
• 使用带ID的原子需求，便于在代码和测试中引用。
• 对于招标，选择支持导出通用格式的SaaS工具。
• 在企业环境中，跳过签名——冻结状态即可。
• 集成Confluence/Jira，在过渡期采用混合方法。

— Editorial Team