标签：
建议采用迭代方式，即详细设计->测试的迭代，概要设计阶段会提取出所有需要开发的功能点，这些功能点将会按照优先级被划分为3-4个阶段，每个迭代阶段都会进行详细设计、编码和测试，然后与用户见面进行修正。
所有迭代过程结束之后，再进入整体集成测试、实施以及最后的维护阶段。
最终出具《需求调研报告》。需求调研步骤一览：
整体情况了解产出：需求调研报告，补充第一章
调研计划制定产出：需求调研计划
具体工作调研产出：需求调研报告，全部补充完整、并确认
需求成果评审产出：需求规格说明书
需求成果录入产出：录入到需求管理工具的需求
目的在于对客户有个整体了解，调研内容包括：
u 系统目标和主要领导的期望：整体把握系统的定位，以后大概要做成什么样子。
u 已有系统的建设：看看以前系统做成什么样子，客户为什么要重新做，哪些地方好的可以借鉴的，哪些地方不好的要避免的
u 部门组织结构和人员角色：知道接下来要找哪些人了解具体工作。
u 各个角色涉及的工作项：了解接下来和具体的人了解业务工作时需要询问的范围。
一般用组织机构图描述组织机构和人员角色，用二维表格描述各类角色的工作内容，成果补充到《需求调研报告.docx》中。
整体情况了解采取的方式可以有很多种：
1向市场部或者产品部进行了解，获取并阅读相关材料，
2自己打电话同用户交流；
3同用户方进行的项目启动会议；
如果是同用户交流最好选择对方中层领导，他们往往对一线工作人员比较了解，同时又大概了解上面领导的意图，对系统的定位和期望。划分清楚部门或角色，弄清楚每个部门或角色的工作内容，就是为了在今后的需求调研中找对正确的人，使今后的调研工作事半功倍。
将了解的整体情况录入到对应的《需求调研报告.docx》中，补充文档第一章。
在了解了系统的整体情况，即组织机构、用户角色等信息后，需要制定一个接下来在用户现场将要进行的需求调研计划，参见《需求调研计划.docx》，同时将《需求调研报告.docx》中补充好的整体情况用红色加粗字体显目出来。
将这两个文档发给用户，提早告知用户即将进行的现场调研的计划安排。
步骤1：整体情况确认
之前已经了解过一次系统整体情况，这次到用户现场主要目的是针对自己录入到《需求调研报告.docx》中的整体情况做进一步深入和确认。
步骤2：业务流程调研
根据前面的调研，已经掌握了系统涉及的角色，以及每个角色的主要工作内容，接下来就是和各类角色的一线工作人员单独交流了解详细的工作内容，补充完善《需求调研报告.docx》中的二、三、四章。针对每类角色的一线工作人员若有多个，尽量叫在一起，一般和一线工作人员的交流也需要经过多次迭代：
u 第一步：启动交流，了解流程
两种方式启动：
方式1：如果已经在上一步清楚了其涉及的工作内容，可以主动逐一询问，比如“你们在实际工作中是怎么将购买的产品入库的？”
方式2：不大清除对方涉及的具体工作内容，可以收集他们使用的报表和单据，询问报表和单据的用途，通过这种方式开始此次交流。
初次交流一定要在纸上记录、画出对应的流程图的草图，这种方式较为高效。
一旦准确无误了解了涉及工作内容的流程之后，一定要先暂停交流，将了解的流程和流程涉及的所有单据、报表的情况记录下来，填充《需求调研报告.docx》中第二章工作项描述的“原始流程”和“单据报表”两项、以及第三章，建议“原始流程”用文字描述，按照步骤分隔，同时思考一下初步还有哪些问题需要询问，记录在“问题列表”一项。
备注：相关单据、报表尽量都要一份在手里，在上面备注字段的录入要求、默认值、唯一约束、可选范围、单据状态等细节。
u 第二步：流程确认，开始问答
此次杀回来需要将之前记录下来的流程和单据报表进行最终确认。
然后针对自己想要知道的问题进行问答，记录在“问题列表”一项。
询问用户最希望系统解决工作中的什么问题？关注点主要在哪方面？记录在“用户关注点”一项。注意，在问用户最想要解决的问题的时候，要看清问题的本质，比如用户说“我要一个馒头”，“你为什么要一个馒头？”“因为我饿了”，所以如何填报肚子才是用户最核心的问题，我们在这个环节应该多问为什么，挖掘用户最真实的想法。
u 第三步：流程优化
到底为止用户最原始的需求大体上已经记录完成，即帮助用户梳理其业务流程的工作已经结束，接下来就是要帮助用户优化业务流程，建立对应的规范。
流程优化包括以下几种情况：
1 将用户实际的工作流程和我们的系统结合起来，提出一个新的业务流程；
2 多个部门、角色之间类似的流程可以进行抽象，提出一个统一的规范；
3 多个部门、角色之间衔接的地方是否可以通过系统进行规范或优化。
这个过程可以自己私底下思考，也可以和相关用户一起讨论，最终将优化后的结果记录在第六章，通过用例图、活动图并配以文字来进行描述。
u 第三步：优化结果确认
优化后的结果要得到相关角色的确认。
步骤4：需求调研成果确认
针对每个部门/角色进行“步骤2”的迭代之后，至此已经跟每类角色的各个一线工作人员都已经交流完成。接下来要做的就是把能基本做出决策、又了解上层大领导的设想和思路的中层领导和之前交流过的一线用户集中起来，一起将原始流程、关注的问题、特别是优化后的流程进行最终修改确认，领导的决议和关注点也要对应记录下来。至此需求调研报告全部完成，打印出来留给用户一份，如果能够签字最好，方便之后需求变更管理。
产出为：《需求调研报告》
根据需求调研报告出具《需求规格说明书》，需求规格说明书根据不同公司，不同项目可能都不大一样，但是核心思想都是差不多的，大概涉及以下几方面内容：
n 运行环境、上下文关系、限制条件（工期、运行环境、技术等）
n 角色及其对应的用例
n 单个用例的细化，包括用例的详细文字性描述，可用活动图加以辅助描述
n 类图或者E-R图，描述系统数据对象以及它们之间的关系
n 测试用例(较为抽象、注重需求是否满足)
注意编写需求规格说明书之前需要先分析出系统角色，一般原则是从常用操作场景去分析参与的角色有哪些，然后列出所有场景以及各个角色在该场景下的功能权限和数据权限，验证角色划分正确之后，在进行需求规格说明书编写。因为编写需求规格说明书时，绘制用例图和活动图需要以分析出来的角色作为参与者。
其实根据我的经验，需求规格说明书里面的很多内容其实在需求调研阶段已经完成了，只是可能形式上不是很注重，比如系统角色，用例，运行环境，限制条件，对象实体关系等在需求调研阶段就已经需要同时分析出来的。所以说需求规格说明书一定程度上来将是前期需求调研和分析的成果体现。
最终完成需求规格说明书需要经历以下步骤：
1、 项目经理根据需求调研报告，进行《需求规格说明书》的编写；
2、 进行项目组内甚至更大范围的评审会议，这一步很关键，需要相关的研发人员以及项目经理等有经验的角色共同参与；
3、 根据评审结果进行修改，之后发给用户进行最终确认。
产出为：《需求规格说明书》。
经过用户确认的所有需求已经包含在最终形成的《需求调研报告.docx》中，接下来要做的就是将这些需求录入到需求管理工具中，进行跟踪管理。
在这里可以下载我自己编写的不涉密的 需求调研相关的文档：http://pan.baidu.com/s/1nq4cm
概要设计包括四个方面：
n 技术架构设计。包括逻辑架构和物理架构并详细说明
n 功能模块组织和划分，给出功能模块图或者思维导图(脑图)
n 功能点提炼、优先级确定。第一阶段功能点应该尽量少，涵盖关键性业务即可，在完成第一阶段功能点研发之后立刻与用户见面，以免与需求产生较大偏差。可以认为我们采用的是迭代式开发，按照这个阶段划分的功能点进行迭代。
n 后续启动计划制定，比如需要在什么时候完成详细设计、准备工作、第一阶段功能点开发、第一阶段产出系统与用户见面并修改等。
产出为：《概要设计文档》。
详细设计包括以下三个方面：
n 各个功能点的详细设计
n 数据库详细设计
n 导航、数据权限详细设计
产出为：《XXX功能点详细设计》、数据库pdm文件、《权限设计》。
在测试正式启动之前，项目负责人需要根据环境和人员制定出可控的测试计划，比如由哪些人来承担测试环境搭建，由哪些人来细化或者编写测试用例，由哪些人来执行具体的测试，由哪些人来执行系统产品化工作。然后各自这些任务的目标，所涉及的工作范围，阶段的划分，时间限制等都要规定好。然后为每个部分指定一个负责人，进行任务分配和进度控制，并直接向项目负责人汇报进度。
然后要求所有系统模块单元测试通过，提出最后源码提交期限后，禁止源码环境的源码提交权限，禁止出测试环境部署人员之外的人员针对测试环境的提交权限，将测试环境和外界断开，具体理由可参考另一篇文章。
在提出测试目标、分配测试任务、划分测试阶段之后，就可以开始启动系统集成测试。大概可以将信息化系统的集成测试划分为以下几个阶段：
（1） 系统开发完成、制定总体测试计划（测试目标、测试范围、人员分配）
（2） 部署人员部署系统到测试环境，产品化人员协助。比如数据库初始化脚本等需要产品化人员提供，这个阶段先不要将数据库、服务、客户端等打包。
（3） 需求掌握人员编写测试用例(参考原始需求调研报告和需求分析报告)；
（4） 测试人员执行第一轮测试；
（5） 第一轮测试Bug修复、回归测试至Bug修复完成。
（6） 编写测试报告，开始产品化打包工作。
（7） 产品化安装包测试。
（8） 系统安装文档、用户使用手册编写。
（9） 最终定版，系统、文档、源码归档。
在系统开发完成之后，后续的版本迭代、代码和系统维护过程中，最关键的是版本控制问题。
撰写人：季义钦、欢迎交流
标签：
原文地址：http://blog.csdn.net/jiyiqinlovexx/article/details/46509113
