“我们应当怎样做需求分析”——大纲卷

这是一篇关于怎么进行软件需求分析的文章，读完的第一个感觉就是累。真的是特别累，我大概估计了一下，得有40000个字。不过读完之后还是有一点收获的。下面是一个大概的内容。

一.需求调研阶段

初识

1.在客户组织的第一场见面会上，保持良好的态度（不卑不亢）。对需求进行深入的理解，从而提出更加合理的方案，建立良好的初期形象

2.对客户的用户角色进行详细的划分，为解决多元化的问题做好准备（“从高层领导着手，提出规范化管理的口号。同时，在进行需求调研时，尽可能地召集各个单位的代表在一起开会讨论。同时，应当有高层领导，或者指定一个负责人，在出现分歧的时候最终拍板决策。”）

3.了解客户方领导的期望值，建立双方达成共识的宏观目标。

 

拜访

1.也就是交友的部分，与各个角色和各个类型的客户建立联系，培养感情，保持友好的关系

2.判定客户群体对于软件的看法，团结能够因这个项目收益的人；尊重与交好，项目与他无关，但是他可以给予你巨大帮助的人；争取那些怀有敌意的人。

 

研讨会

1.有效的抑制个性化的差异

2.分模块进行专项的研讨会

3.通过对比，发现不同公司的问题所在，并且与客户交流，从而得到一个相对统一的答案（分散式研讨）

4.创建经典案例,例如在一个部门先推行下去，并且获取成功，从而激励其他部门。

 

需求研讨（怎样与客户讨论业务需求）

1.客户会提出不正确的需求的情况

　　1.1对软件不了解，提不出需求

　　1.2能提出需求，但是当软件做出来的时候需求就发生了改变

　　1.3详细的提出需求，甚至知道怎么实现，但是会提出一些不切实际的要求，或者我们会有更好的方案

2.同时还有的情况就是为了开发软件无限扩大学习领域的知识

3.用合理的方式去拒绝技术难以实现的或者根本无法实现的需求

　　3.1提出一个更好的的方案

　　3.2让对方意识到这是不可实现的

 

迭代

1.需求捕获

　　1.1记录下业务流程

　　1.2询问名词的含义

　　1.3记录软件希望的功能

　　1.4列出需求列表

2.需求整理

　　2.1通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程，之后细分流程，直到需求已经非常清楚为止）

　　2.2制作领域模型，一般以对象图和类图的形式表达的，对产品的领域进行更加深刻的理解。

3.需求验证

　　3.1应当对及时地与客户进行反馈，确认我们的理解是否正确，也就是需求验证工作

　　3.2需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式

　　3.3通过每开发完一个迭代周期，将开发的成果与客户反馈。及时对产品进行修改和优化，从而将修复问题的成本降到最低。

 

 需求捕获

1.包括两种态度，主动询问信息和被动的接受信息。其中被动的接受信息，也就是单纯的记录用户所说的功能非常危险。

2.潜伏中的需求

　　2.1用户嘴中没有说出来的需求

　　　　2.1.1原因：在他们看来已经是天经地义，根本就不用说出来的业务规则

　　　　2.1.2解决办法：在需求分析的整个过程，不断进行业务领域知识的学习。

　　2.2客户压根儿就没有想到的需求。

　　　　2.2.1原因：软件在最开始没有实体的时候，客户很难想象开发出来的软件是什么样子。而在软件研发的后期，客户能拿到那些研发成果的实物，去操作，可以看到。这时候，很多他们起初没有想到的需求就会源源不断地被提出来。

　　　　2.2.2解决办法：站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。

 

 

二.需求分析阶段

 

功能角色分析

　　1.采取用例图的方式来进行分析工作的细化

　　　　1.1参与者（Actor）

　　　　1.2用例（Use Case）

　　　　1.3系统边界（Boundary）。

　　　2.绘制用例图的错误示范

　　　　2.1没有正确理解用例图的视角。没有站在用户的角度方面来考虑，仅仅站在自己的角度来看问题

　　　　2.2图形绘制杂乱无章，绘图不够清晰

　　　　2.3用例不是一个场景，没有将一个案例真正放在事实上的案例上就会导致有考虑不周或者将问题想的太简单的问题。

　　　3.补充：

　　　　3.1必须要对用例进行进一步的文字描述。

　　　　3.2在每一个用例说明的后面与该用例相关的需求列表，便于需求跟踪。

 

业务流程分析

　　1.通过流程分析，抛开软件实现，对一个流程进行梳理，并且分析我们的软件能做什么事：

　　2.明白软件系统的功能是为了提高客户的工作效率，而避免加重他们的负担。

　　3.流程改进的意见：

　　　　3.1清除低效环节

　　　　3.2简化业务瓶颈

　　　　3.3整合可用资源

　　　　3.4自动化繁重操作

 

查询报表分析

　　1.报表的目的：通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。

　　　2.用户使用报表的频率，常常决定了报表设计的方式。

　　　3.一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。

 

业务领域分析

　　1.原文分析法

　　　　1.1对原文进行分析，提取其中的名词，判定其中的实体

　　　　1.2名词的多义性，需要注意细致的措辞，以防引起开发人员的误解

　　　　1.3对原文进行分析，提取其中的动词

　　2.领域驱动设计

　　　　2.1建立双方都能理解的共同语言

 

非功能需求

　　1.可用性（Usability）:它泛指那些能让用户顺利使用系统的指标，包括易用性（易操作、易理解）、准确性、安全性（权限体系、访问限制）、兼容性（服务器、客户端的兼容度）

　　 2.可靠性（Reliability）:系统可以可靠运行，包括系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性，等等。

　　3.性能（Performance）:在设计的时候就解决的问题

　　4.可支持性（Supportability）：是维护系统的关键所在

　　5.其它（+）

 

三.需求确认阶段

 

需求列表

　　1.需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，

　　2.需求列表应当是站在业务人员的视角，对业务需求的简明扼要的描述。

　

快速原型法

　　1.利用快速开发出来的原型，来与用户进行交流。从而获取用户对软件的看法。

—————————————————————————————————————————————————————

 

 

四.之间的关系

原文链接，请参考链接：http://blog.csdn.net/yqmfly/article/details/7679781