需求分析读后感

在一开始，作者讲述了自己曾经接的一个项目的上一个团队的搁浅并解散的过程和原因。关于客户对需求改来改去的原因

从这段我们可以看到，作者认为，不能只被客户的要求牵着走，要深入的思考，为什么客户会有这样的需求，怎样更改能解决这个问题，从用户的角度出发，切实的看到问题的根源，才能满足客户的需求。

在第二个故事中，作者提到了自己曾经失败的项目。

从这一段，我们可以看到，客户的手工报表给作者带来了很大的困难，最终导致项目无法完成，作者从这次经历中得到的教训是：客户的要求往往是站在自己的理想角度来提的，他们根本不知道技术问题是否可以解决，也不知道不系统的管理会带来的困难，因此我们在做需求时，就应该去有意识的引导他们系统化的管理，将管理模式转化为易操作、可实现的。

剩下两个故事都遭遇了各种各样的问题，我不一一举例，仅仅讲讲作者的看法以及我从中想到的一些感悟。

第三个故事中，作者因为在需求分析中没有详细得分析所有角色的需求，导致最后的作品状况百出，我认为在需求分析时，应该切实地去对每个用户角色进行调研，然后在进行分析，才能做出客户满意的作品。

第四个故事中，作者十分顺利的完成了项目，可是提交时，却发现许多地方不符合客户需求要重新修改。因此，在开发过程中，一定要不断地跟客户进行交流，才能在最后阶段完成跟客户想象中接近的作品。

 

 

 

我们应当怎样做需求调研：初识

我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，

在软件项目中，特别是管理型软件项目中，客户都代表的是一个群体，而不是个人。他们代表的可能是一个单位、一个集团，甚至是一系列组织机构。在这样一个群体中，他们按照职能被划分成了不同的角色。拿一个单位来说，横向可能划分成不同的部门，财务部、销售部、采购部、生产部••••••不同的部门，由于业务的不同，对软件的需求自然是不同的，因此我们在进行需求调研的时候，什么部门的需求就应当跟什么部门谈。同时，纵向又可以划分为多个层次，如高层领导、中层领导与基层人员，理解这些方面格外重要：

1. 高层领导
高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，都应当与高层领导谈。他们关系的都是宏观的问题，因此不要与他们谈那些细枝末节；

2. 中层领导
中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节；

3. 基层人员
基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。另外，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。而他们关心的则是每项操作的细节。

 

 

我们应当怎样做需求调研：拜访

    那就是做事先培养感情，感情培养起来才好慢慢做事，需求调研也是一样。分析一个客户人群的关系，就是在分析这个人群中，谁有意愿支持我们，而谁却在自觉不自觉地阻碍我们。

我们应当怎样做需求调研：研讨会

业务研讨会是重要的，但同时又是灵活的，没有一个定式，甚至有时都不能称之为会议。项目经理需要根据实际情况，合理地与客户组织研讨会。但不论怎样组织，必须注意两点：有效抑制个性化差异、分模块组织专项研讨会。
我们应当怎样做需求调研：需求研讨

做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
我们应当怎样做需求调研：迭代

需求分析就是按照这样的过程，每次多理解一些，再多理解一些，更多理解一些，逐渐深入的过程。每深入一步，我们的软件就更接近客户的满意。

我们应当怎样做需求调研：需求捕获

首先，在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书

功能角色分析与用例图

业务流程分析

用例说明

查询报表分析

子用例与扩展用例

行动图和状态图

业务领域分析

原文分析法

领域驱动设计

非功能需求

需求列表

一个需求列表的实例

快速原型法

需求规格说明书
我们应当怎样做需求确认：

转载于:https://www.cnblogs.com/edithfinch/p/8530494.html