作为软件架构师，优化流程是重要内容。
其实《需求规格说明书（Requirement Specification）》有两个：用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，用户自己完成或用户表达、技术支持整理，就是我们常说的“技术协议”；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是检验软件公司是否正确理解用户需求的试金石，是指导开发人员完成设计与开发的技术性文档，是测试人员完成测试用例的依据。
为什么有了《技术协议》，还要整理《产品需求规格说明书》
1，《技术协议》往往是利益相关人中地位较高的人完成的，那些地位较低的利益相关人，在《技术协议》上没多少发言权，于是他们的诉求被忽视。“忽视利益相关人的诉求”错在用户，但承担恶果的是我们，用户不会因为“某个功能”《技术协议》上没有，而放弃此功能。
2，“技术协议”是理想的，往往有不可行的内容。整理《产品需求规格说明书》时候可以发现这些不可行的内容，然后和客户沟通。如果没有整理《产品需求规格说明书》，软件工程师在软件基本完成后，才发现不可行，这时已经是项目的晚期，变更成本惊人。
3，“技术协议”有些内容必须遵守，有些只是参考（非最优解）。这些往往需要和多个客户沟通，软件工程师往往没渠道、时间、技能与多人沟通。
4，许多需求用户认为是“显而易见”的，无需特别说明。由于没说明，所以软件工程师只能凭感觉猜测，留下大量隐患。比如：不良分类的脱碳和气泡，用户可能认为“三岁的小孩都知道”，所以无需说明。实际上，用户或系统分析师必须用机器视觉能识别的规则来描叙脱碳和气泡。
5，用户往往只记得常用功能，不记得非常用功能。而且有些周边功能，旧系统是不需要的。
6，用户之间，部门之间可能存在矛盾，这使得技术协议可能失真。
7，新的软件系统可能使某些人、某些部门利益受损，这些人或部门会暗中抵制。
系统分析师整理《产品需求规格说明书》相对于软件工程师评审《技术协议》的优势
1，对软件工程师而言，评审《技术协议》是次要任务，这注定软件工程师不会花多少时间评审《技术协议》，草草浏览是常态；整理《产品需求说明书》是系统分析师的核心任务，必定会全力以赴。
2，评审《技术协议》往往需要和客户沟通，软件工程是往往不具备沟通条件，这严重影响评审质量，也使得事后无法追求责任。
3，专业分工带来高效率，至少体现在两点：（一），同类项目，大部分内容是相同或相似的。（二），有了同类项目的衬托，错误和遗漏更容易发现。
4，无法知道软件工程师在评审时是否敷衍塞责；如果系统分析师整理需求时敷衍塞责，后续设计开发会无法进行。
