我们应当怎样做需求调研.docxVIP

我们应当怎样做需求调研：初识从高层领导着手，提出规范化管理的口号在进行需求调研时，尽可能地召集各个单位的代表在一起开会讨论应当有高层领导，或者指定一个负责人，在出现分歧的时候最终拍板决策与客户一起为项目制订了短期与长期目标高层领导：研发目标、宏观统计报表、决策支持功能，不谈细节问题；中层领导：功能的定义、业务流转的衔接、查询报表的设计，不关心具体操作和细节基层人员：操作的细节，业务流程的操作者，软件今后真正的使用者我们应当怎样做需求调研：拜访与客户建立长期友好的关系逐个拜访，展开调研我们应当怎样做需求调研：研讨会集中式的研讨：优势：处理高效，个性化差异可以及时分析拍板；劣势：集中难度大。分散式的研讨：优势：无需集中；劣势：需要记录各个区域的差异，在其他区域分析时再次确认。最好建立典型范例以便推广。分模块组织专项研讨会：一至三个业务人员和一个负责人（负责拍板）建立联系方式，以便迭代我们应当怎样做需求调研：需求研讨跟客户探讨的不是软件功能，而是客户现有的业务知识——业务领域分析业务流程、操作、事物、专用名词、关系、操作目的、报表说明的问题、要知道需求为什么会被提出……针对无效需求和难于实现或者根本就无法实现的需求，提出一个更加合理的方案我们应当怎样做需求调研：迭代需求捕获-需求整理-需求验证-再需求捕获……我们应当怎样做需求调研：需求捕获访谈初期，不谈需求，而是谈业务，你们是怎样操作的？都经过些什么流程？谁来完成这些操作的？为什么这样操作？模拟原型，提供参照物客户说的需求不一定合理，提出问题的同时必须提出解决方案我们应当怎样做需求分析：功能角色分析与用例图用例图：按职能角色划分，系统中的一个功能对应某项业务流程的某个操作，操作还有产出物，此功能就是用例。用户视角描述，使用用户的语言来描述由大到小，由粗到细，不要粗细都在一个用例图中用例必须有一个场景，也就是时间相近、地点单一的一系列操作，并且这些操作最终应当有一个明确的结果。如果系统规模较大，还应先划分为几个子系统，然后再划分出各个功能模块。然后，我们为每个功能模块绘制用例图。我们应当怎样做需求分析：业务流程分析信息化不是万能，不能代替所有现实中的工作；信息化过细，会增加基层业务人员负担，适当才可提高效率。业务流程分析就是分析业务流程中哪些需要信息化，哪些不需要流程差异化分析：分治与一统的平衡目标：清除低效环节、简化业务瓶颈、整合可用资源，以及将繁琐任务自动化。我们应当怎样做需求分析：用例说明用例标识：项目编号-子系统编号-模块编号-序号用例名称：动词短语或短句用例类型：业务操作，查询报表，子用例，扩展用例……用例描述：整体功能定义，业务需求，如何使用，主要流程，外部关系……前置条件：在触发该用例相关操作前必须达到的条件。事件流：详细流程基本流程扩展流程：编号规则是“基本流程号+序号”异常流程后置条件：最终目的，达到的状态非功能需求：简称为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）我们应当怎样做需求分析：查询报表分析数据链接：哪些数据项有链接，链接到什么报表，或显示什么数据。我们应当怎样做需求分析：子用例与扩展用例子用例是多个流程中重复或者相同或者共享的公共流程子用例逻辑上是相对独立的子用例是抽象的，没有自己的参与者，只有调用时才能确定使用者与子用例相似，扩展流和异常流中的流程如果相对独立、可以为其它流程所共享，则可以提取出来，形成一个单独的用例，叫扩展用例(标注为extend)。目标：提高系统的内聚并降低系统的耦合。我们应当怎样做需求分析：行动图和状态图行动图：状态图：我们应当怎样做需求分析：业务领域分析原文分析法领域驱动设计我们应当怎样做需求分析：原文分析法提取事件流部分的名词——领域模型中的实体排除系统外的参与者系统之内-实体或实体中的属性实体是系统中的执行者或者施与者,自身有自己的属性实体与属性不是绝对的提取事件流部分的动词——领域模型中的实体的行为排除参与者的行为目的：分析需求，不细化技术实现，如下图中的“指标定义”、“过错标准”。我们应当怎样做需求分析：领域驱动设计有效建模思想统一的语言我们应当怎样做需求分析：非功能需求可用性（Usability）：易用性（易操作、易理解）、准确性、安全性（权限体系、访问限制）、兼容性（服务器、客户端的兼容度），等等。可靠性（Reliability）：系统成熟度（数据吞吐量、并发用户量、连续不停机性能等）、数据容错度、系统易恢复性，等等。性能（Performance）：并发访问量，是否要建立集群，是否使用消息队列，流程是否有性能瓶颈，采用什么技术架构可支持性（Supportability）：可维护性、易变更性我们