理顺软件开发各个环节-8（需求管理-软件需求分析探讨）
4.4.5软件需求分析探讨
本节探讨一下软件需求分析在实际操作中的几个问题。
4.4.5.1软件需求分析的必要性
我的看法，软件需求分析是十分必要的。
1）因为软件需求分析将产品需求转换为软件需求，即将用户（业务）语言表达的产品需求转换为开发人员语言表达的软件需求，使得开发、测试人员更能准确、完整地理解需求。
2）因为软件需求分析，清晰、完整地表述的软件需求，基于此开展的设计方案才有可能考虑得更加全面、更加有弹性，评审设计方案也有据可依。
3）只有做了软件需求分析，才能了解软件的需求集合的实际规模，估算软件产品的开发工作量才能相对较靠谱，再结合人力资源情况，给出开发计划。
只有产品需求清单，没有做软件需求分析的情况下，给出软件开发计划是困难的。此时很多模块是灰盒子，朦朦胧胧，软件需求没有明晰，工作量测算是拍脑袋定的。如果工作量算少了，后期开发时需频繁调整开发计划，开发团队加班加点还顶一个拖延进度的帽子，心情可想而知；如果工作量多算，管理者又不满意，认为没多少需求，怎么要这么多时间！因为没有软件需求分析，开发项目经理拿不出明细条目来，没法据理力争，结果开发计划往往是按领导的意思去做。
而做过软件需求分析后，情况就大不相同。
首先，全部的需求集是明晰的，每个需求项的工作量也容易测算的，因此工作量的估算不会偏差很多。
其次，可以根据需求的优先级，结合开发资源情况，规划版本计划，确定在哪个时间点开发完成哪些需求项，提供些什么功能，达到什么效果？
因此，我的观点是软件需求分析阶段不可省。
4.4.5.2软件需求分析缺失原因探讨
软件需求分析在瀑布式开发模式时代，是不可逾越的阶段。而如今，敏捷开发大行其道之时，很多研发团队往往能省则省。
为什么如此？
我的理解是：
首先，一部分管理者对软件需求分析的重要性理解不足，软件需求分析需要时间，这段时间只是纸面作业，看不到有形的输出，不愿意付出这些时间成本。
其次，软件需求分析和设计阶段，不需要整个开发团队的成员全部参与，这段时间的工作安排，对开发管理者是个挑战；如果针对产品需求，直接编码实现，这样大家都有活干了。
再次，需求变更时，软件需求分析文档的及时更新维护成本过高，经常没有及时更新，导致软件需求规格书最后版本与实际有所偏差，最后流于形式。
4.4.5.3软件需求分析的执行者
软件需求分析的分析人员，需要什么资质？
我认为需要系统分析员或高级程序员，最低程度为中级程序员偏上水平，很多情况是系统分析员（或高级程序员）带领1到2位中高级程序员来做。需求分析时候，还需要经常与产品经理及客户沟通。
因为软件需求分析，是一项创造性的智力劳动。如Use Case的表达方式，实际上，需要想象需求使用场景，正常过程是什么流程？有哪些可选过程？有哪些异常过程？考虑得越全面，分析质量越高，为后期开发带来的益处越多。
之前我有过经历，带领一个开发小组一起做软件需求分析，结果是惨不忍睹，有些成员对需求为什么用、如何用Use Case形式来表达软件需求理解不深，做出来的需求分析质量可想而知；还有即使掌握了Use Case形式的软件需求表达方式，但对正常过程的每一个步骤，没有去质问这一步是否可能发生异常，有哪些可能的异常过程，这样异常过程轻描淡写，软件需求分析质量也不会很高。
因此，做好软件需求分析，需要能力和责任心的结合。
等软件需求分析通过评审后，可以安排时间给开发团队的其它人来讲解，同样达到使之理解需求的目的。
4.4.5.4软件需求分析不仅仅是产品需求的细化
软件需求分析一方面是对产品需求的细化，对每个需求项，或功能需求、非功能需求等，罗列具体的需求规格。但不仅限于此。
软件需求分析还伴随着初步的模块划分和架构设计。模块划分是归并需求子集，将功能相关的需求项归于同一个模块中；而架构设计，则从系统实现角度，设计哪些功能、逻辑处理模块，一般可使用C4设计模式（C4模式中的Code视图一般忽略）。
为什么软件需求分析需要初步的模块划分和架构设计？
举个栗子：
对于通信协议而言，一般使用CSN.1或ASN.1语法来描述的，如3GPP协议。一个具体协议的解码模块的需求，有两种处理方法。
方法1，使用硬coding方式，来解码，即按照具体的通信协议，按照ASN.1语法，逐个结构来解析，解析结构存入一个个消息结构中。
方法2，开发通用的ASN.1的解码器，针对某个ASN.1的协议的相关脚本，解码器输出特定计算机语言（如C++）的解码代码文件。
方法1和方法2都可以满足需求，但两者的开发难度和工作量是不同的。
方法1容易，但如果需要解码的协议很多，工作线性叠加，最后实际工作量还是很大的。
方法2有难度，但是属于一劳永逸型，除非ASN.1的语法有扩展，但维护工作量也是不大的。这种方法对于有多个协议需要解码，且通信协议版本升级的情况，后期工作量可忽略不计，且质量稳定可靠。方法2属于配置化的设计思想。
对于产品需求而言，需求项就是：需要一个针对XX协议族的解码。而软件需求分析的结果，如果决定使用方法2，则需要进一步描述通用解码器的软件需求。
4.4.5.5软件需求变更的文档一致性维护
软件需求变更，对于软件而言，是很正常的，特别是前期需求不明确的情况下，需求变更更是频繁。关于软件需求变更，在变更管理中详细讨论。
这里重点探讨一下，如何使得软件需求发生变更时，软件需求分析文档能以比较低的代价得以维护，从而确保软件需求符合软件产品的最新情况。
之前，使用word文档格式，编写软件需求分析，输出SRS文档、DD文档、及外部接口文档等。
由于文件的共享性问题，结果导致维护成本很高；作为文档发布路径的管理，有一定的权限控制，上传更新成问题；相互之间传递，时间一长，可能不是最新版本。
软件产品经过多次迭代后，由于不同的人员负责不同的模块，其对需求也更了解，由其来维护需求也更可行；结果不同人员的维护不同的需求模块，整合是一个问题。
使用Markdown形式，纳入git配置管理，是一个方案；但是文档篇幅较长，还包含图片，需要注意图片更新，文件需要使用不同的链接地址，从而确保不同版本的图片共存。
还有一种形式，只是我的理解（还没有尝试），利用wiki的形式，来管理各需求项，维护软件需求与软件产品的一致性，是一个可行的方案。
