我对需求分析的理解

分享到

我对需求分析的理解

发布于2013-3-27

写本文的起源是公司新上任的领导要求规范各种文档，第一个规范的就是需求分析文档，这是当时我提交的意见稿，公司是通信行业，我从事PC平台.NET程序开发，和一般的企业管理软件开发有所区别。

1、什么时候需要需求分析文档（需求分析的价值）

项目前期，签订合同时，合同双方用于约定产品功能与标准；同样适用于模块级开发前期，例如调度台模块，所谓合同就是调度台操作员、调度台、交换机之间的合同，我负责的则是调度台UI模块，所谓合同就是调度台操作员、UI、调度台业务接口（dll）之间的合同。
开发阶段，设计、开发、测试时，需求分析文档作为开发与测试人员的最高依据，经常需要查阅；
维护阶段，需求分析文档作为开发与测试人员的最高依据，基本是必须先查阅

2、需求分析的本质

约定系统与系统边界之间的交互规则（协议）。例如，调度台UI模块的需求分析描述可以是：操作人员做XXX动作，调度台界面调用业务接口XXX函数，调用业务接口返回XXX，调度台界面向操作人员给出XXX提示。

3、需求分析的结构

具体要素不展开叙述（文章结尾有补充），要素可以包括：执行者、前置与后置条件、基础与扩展路径、字段列表、业务规则、非功能需求、设计约束、操作界面、测试用例

4、需求分析的标准

准确性：不能有歧义。
成本低：编写和维护需求分析文档的所花的时间要少。
效率高：在使用需求分析文档的各个场景中，在准确前提下，效率要高。例如，别的开发人员需要参照需求分析文档来设计或编码时，越快能被理解的文档就是越好的文档。

5、需求分析的形态

无文档类：口头说说，在模糊的记忆中。
单独文档类：例如word格式，公司目前的主要方式。
集成文档类：集成在项目管理软件平台中。理想一些的需求分析文档，应该能关联整体的模块架构设计，关联实现该需求分析文档的设计文档和代码，关联对应的bug，关联对应的版本历史，关联任务分配和人员工时，关联其他相关的需求分析文档。

6、需求分析的常见误区

警惕“有形无神”的需求分析文档（设计文档也是如此）。模板可以很快建立，好的模板可以提高文档的质量和编写的效率，但是最重要的还是对需求分析要素的理解把握。格式正确，写不到“点子上”的需求分析，有害而无益；要真能使需求分析文档发挥作用，讨论和规范模板后，更重要的是在实践中，以严谨务实的态度，持续总结、交流和学习。例如，可能会做类似下面的实验：预设同样的需求背景和“客户”，让不同人做需求分析，然后让客户和多个设计人员评判，从而讨论和总结什么是更好的。
需求分析需要多人参与。需求涉及的各方必须参与设计和评审，特别是涉及UI的需求分析，UI开发人员和客户（测试人员可以部分代表客户）必须参与。
需求分析应该包含测试用例，用于验收和明确。开发人员开发时也是需要参照测试用例的，这样才能更加准确的理解和沟通自己的需要完成的目标，开发人员自己编写的单元测试数据都可以直接或间接来源于需求分析中的测试用例。复杂功能的基础的测试用例可以由需求分析人员直接完成，一般情况可以由测试人员完成，需求分析人员复核。
需求分析和模块设计（划分）的没有本质的区别。模块设计产生的模块接口协议，就可以作为具体模块的需求分析，最小的需求分析可以看做是定义函数的输入输出和规则。
需求分析文档不是越细越好（设计文档更是如此）。细是需要编写和维护成本的，只要可能用到该需求分析文档的人能清楚理解功能的规则即可，相似的功能也可以“参考XXX功能”，简单的功能也可以省略部分要素，复杂的功能可能需要多种图示和多个测试用例辅助理解。
写需求文档的前提是设计系统解决方案（基于当前业务流程问题，设计新流程，创造价值）。但很多时候没有明确的系统解决方案文档，所以在需求分析文档中，常常包含了部分系统解决方案的内容。设计系统解决方案（下图中的0-业务）、需求分析，以及与软件过程的其他步骤之间的关系，见下图（供参考）。
缺少强有力的实际客户的反馈，需求分析有闭门造车的嫌疑。实际客户包括直接使用软件的人，也包括间接相关的人（如领导等等），每个人都有自己的利益，需要统筹考虑；客户的反馈和软件的改进是一个持续的过程，需要不断收集、分析、统计用户的意见和实际使用情况。