|
阅读：15798回复：15
需求分析经验分享
综合我这几年的工作经验，给大家分享一下我做需求分析的一些经验，希望对大家日后的工作有所帮助。
第1步，阅读资料明确项目背景和目标。 1、 项目前期的资料包括项目的合同、投标书、招标书 2、 寻找公司内部资料 3、 寻找网络资源，了解项目背景 4、 结合客户提供的资料包括客户提供的与项目相关的一些规章制度、工作中使用的表格等； 5、 明确本项目的实施（建设）内容； 首先拿到一个项目之后，我会先把客户提供的所有资料和前期的一些资料都通读一遍。项目前期的资料包括项目的合同、投标书、招标书等，客户提供的资料包括客户提供的与项目相关的一些规章制度、工作中使用的表格等。读这些资料的目的，是为了让自己更清楚的了解这个项目的主要目标，客户想要实现什么功能，这个项目能给客户带来什么价值。 第2步，列出功能和问题清单。 在看资料的过程中遇到不熟悉的术语在网上查阅相关的资料，弄明白。然后多看一下与项目相关业务的书籍，了解这个行业。还要根据系统要实现的功能，在网上查阅一下其它的相似的项目是如何做的。然后根据查看的资料以及自己的理解，列出整个项目的用户角色和功能，并把整个项目的功能结构图画下来。在这个过程中遇到了任何不明白的问题，都记录下来形成问题清单。这些问题清单就是接下来调研需求时要去跟客户确认的问题。 第3步，需求调研 在需求调研之前，一定要准备好问题清单，要带着非常明确的目的去调研需求。在调研前要把准备好的问题，提前发给客户，让客户先熟悉。在这个过程，可能客户就可以把简单的一些问题回答了，然后复杂的问题再去现场进行讨论。 在讨论的过程中，客户提出的一切功能都记录下来，但不做承诺最终要不要实现这个功能。在客户说完之后，自己再重复一遍，看看双方的理解是否一致。 第4步，编写需求文档。 编写文档的思路，首先要明确需求文档的读者是谁，只有明确了读者才知道从哪些方面去写这个文档。写文档的目的是为了什么。写这个文档一是为了跟客户确认需求，二是这个文档是设计的依据，开发人员从这个文档了解客户的需求，测试人员根据需求编写测试用例等。这个可以根据实际情况判断。 拿到需求模板后，对模板上的大纲进行浏览，看一下哪些地方根据现在的情况是可以写出来的，哪些是不能写出来。不能写出来的部分，就是需要继续调研和确认的。 写文档时，不要想一步就完全写好。可以先把能够写出来的地方都写上，作为一个需求的初稿。然后再通过调研来逐步的完善。 项目背景一般在合同、解决方案或标书上面有提到。 角色用户分析，根据前期的调研工作分析系统的用户角色，再对每个用户角色要在系统中做的事情转化为用例图和跨职能的业务流程图。这样就可以完成客户和系统整个用例图的编写。然后再把第2步时的功能清单拿过来，结合现在的调研情况和用例图就可以画出整个功能的功能结构图。 针对每个大的功能，还有小的功能。对每个小的功能，也是需要先明确使用这个功能的角色，然后根据角色对需求描述进行完善。需求描述可能是从客户那里采集到的，然后再加入了自己的一些分析，然后形成的。它包括了对这个功能模块要实现的功能，系统需要用户输入什么，系统在用户输入后进行了什么处理，处理完成后又反馈给用户什么。 用例图，刚开始的时候，我也没有画用例图。在做比较急的项目时，是没有画这个图的。但实际上画了这个图之后，会让你更加的清楚，客户在这个系统中可以使用的功能有哪些。 业务流程图，针对有业务流程的功能，可以画，没有的就可以不画。业务流程图，可以帮助我们梳理角色间的业务流转。 数据流图，这个也是很重要的一个图。通过画这个图，可以帮助自己梳理清理每个功能的数据流转，对设计和开发很有用。 界面原型，与功能类似的图，可以贴到需求说明文档上，向客户展示一下这个大概是做成这个样子。在需求文档中的这个界面原型，也就是看一下样子，不画太细了。细化的界面原型，我认为应该是放在设计文档中的。 写需求文档要遵循的原则是不要为了写文档而写文档。所以这里面的图也好文字也好。都是为我们的目的而服务的，需要根据实际的情况进行调整，遇到一些通用的功能，写一份详细的说明就可以了，其它的都可以参见。还有一些明显的如新增、删除、修改功能。可以不做详细的描述。需要详细描述的功能，要是业务的关键点，客户关注的，设计的时候容易有疑问的。 第5步，需求评审。 先内部评审，再外部评审。做内部评审的目的是为了发现需求中的问题，让需求更加的完善，让自己更清楚思路。但现阶段我们部门这个需求的内部评审做得并不是很好。 做外部评审，也就是跟客户去确认需求。去跟客户讲，看看我们理解的需求是不是一致的。为之后的设计做准备。万事开始难，一步错就步步错。所以一定要确定之后再动手。这也是经验教训。 整个过程，要反复的与客户沟通。通过沟通来完善需求。要是客户也不能确认的需求，需要客户的领导来确认。领导也确认不了的需求，要商量对策，到底是做还是不做。如果要做，我们这边要主动提供解决方案给客户确认。有问题要及时候反馈给项目经理。 总结一下 软件项目是一个综合性很强的，现在各行各业都在信息化。想要做好这一行业的需求分析，就需要充分的了解某一行业的业务。所以在分析时多查阅资料来了解该行业的业务、术语这些是非常有必要的。所以要加强这方面的学习。 沟通很重要。随时与客户保持沟通。需求过程中的问题及时询问客户。这样可以让客户充分的参与进来。 文档字数不在多，而是要写到点子上，达到写文档的目的。 熟能生巧。 要有保密意识。在调研过程中客户会提供很多资料，不要把客户的资料外传。以防万一，避免不必要的纠纷。 |
|
|
板凳#
发布于：2019-03-29 15:39
|
|
|
地板#
发布于：2019-03-29 15:40
曾昭洪：求续集，求互动这不是你写的嘛 |
|
|
11楼#
发布于：2019-03-29 15:59
小建议：1可以公成几集来写，建议来内处案例分享。2 还有就是需求分析需要有一定的技术功底，要对需求代价有较准确的判断； 3 如果需求代价超过项目预期花费，一定要切记与商务联合解决。切记切记！
|
|
|
12楼#
发布于：2019-04-23 15:47
|
|
上一页
下一页
