理顺软件开发各个环节-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的形式，来管理各需求项，维护软件需求与软件产品的一致性，是一个可行的方案。