全面提高之需求分析1

一、软件开发过程框架图：

大师的这个开发过程框架图，是一个模型，对我这个刚刚准备工作的学生很有帮助。

二、需求分析评审的感受：

1.需求分析报告一定不能脱离业务调研报告，永远要基于调研的内容来，不要闭门造车，凭着自己的想象在做。

2.需求分析的目的一定要写的符合实际一些，不然会给团队的架构师挖坑。

3.一定不能粗制滥造，将业务调研报告里面的组织结构图直接拿过来作为需求分析里面的功能结构图，必须要经过合理的分析，不能盲目的而使用。

4.文档结构一定要清晰，逻辑一定不可以混乱。

5.在画用例图的时候一定要学会UMl语言，并且经错使用，熟练的掌握。

6.领域类图一点更要学好，对任何的东西该显示的一定要显示粗来，不要因为篇幅太大就不显示了。

7.用做客户验收标准的需求分析报告，必须告知具体的指标，性能的描述一定要精确，响应时间，速度，占用资源多少等等数据一定要详细的列出。

三、读关于需求分析的讨论后体会与初期收获

1.需求分析报告中的图的绘制顺序：学习业务调研报告编写——>学习用例规划——>学习用例描述——>学习用例及参与者关系描述——>学习领域类图——>学习非功能需求的书写。

2.业务调研的时候先从用户容易理解的部分开始入手，，先从一些简单的内容开始，比如用户的部门有哪些，职位有哪些，组织结构，每个岗位处理的档案资料是什么，他们之间的关系是什么等。分类记录好，一定要把专业和业务分开。在第一次沟通以后，一定要了解用户现在在做什么，然后就可以容易的了解用户以后想做什么，想怎么做。怎样来实现更好的内容。调研完毕后整理调研报告的静态结构。

（1）然后绘制单位的组织结构图，一般宜采取直线型结构；

（2）对部门的职责进行描述一般宜采用表格形式；

（3）对某个岗位的职责也需要详细的描述，便于挖掘用户的需求，明白岗位之间的关系；

（4）整理原始资料，主要是整理出哪些岗位职工需要用到哪些资料，做好分类；

（5）画动态的业务流图，描述的是单位的人员之间的业务关系；部门之间的业务流程图称为顶层流程图，针对岗位之间业务流程图称之为底层流程图。业务流程图的格式有很多种，最通用的就是泳道式业务流程图；

（6）非业务调研指的就是在企业现有业务运行的基础上，需要对客户进行进一步的沟通，了解一些业务之外的特殊情况。比如客户运行地地域性、部门变动性、其实就是一些不是业务的东西，但是一旦变动了就会影响业务或者说这个系统的使用，用户操作等的相关性的问题。

（7）最后就是做一个总结，这个总结针对开发技术的选型有重大的意义。