第九章需求分析与管理.doc

第9章 需求开发与管理9.1 目的 通过调查分析、定义、评审、确认、跟踪、沟通等需求活动，使开发方和客户对需求有共同清晰的理解，并依据双方确认的需求开展后续开发工作（如设计、编程、测试等）。9.2 关键活动与流程需求分析与管理的流程如图9-1所示，关键活动是“需求调查与收集”、“需求分析与定义”、“需求评审与确认”、“需求跟踪”和“客户沟通”。 需求调查与收集需求分析与定义需求评审与确认需求跟踪客户沟通 开发人员和客户 迭代图9-1 需求分析与管理的流程 该流程的主要工作成果见表9-1。表9-1 需求分析与管理流程的主要工作成果关键活动主要工作成果责任人需求调查与收集用户需求信息需求开发人员需求分析与定义需求规格说明书需求开发人员需求评审与确认需求评审报告项目经理和客户代表需求跟踪需求跟踪矩阵项目经理客户沟通项目经理和客户代表9.2.1 需求调查与收集需求分析人员起草需求问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以有多份，随着调查的深入，问题表将不断地被细化。需求分析人员确定需求调查与收集的方式，例如： 与用户交谈，向用户提问题 参观用户的工作流程，观察用户的操作 向用户群体发调查问卷 与同行、专家交谈，听取他们的意见 分析已经存在的同类软件产品，提取需求 从行业标准、规则中提取需求 从Internet上搜查相关资料需求分析人员与被调查者建立联系，确定调查的时间、地点、人员等，要特别留意的是不要漏掉典型的用户。在调查过程中随时记录需求信息，格式参见表9-2。表9-2 需求信息记录需求标题调查收集人方式、时间、地点用户信息需求信息记录说明“是什么”、“为什么”等9.2.2 需求分析与定义1）需求分析（1）需求分析的目的：对各种需求信息进行分析、消除错误、刻画细节等。（2）需求分析的方法：常见的有“问答分析法”和“建模分析法”两类。A 问答分析法问答分析最重要的问题是：“是什么”和“为什么”每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。B建模分析法需求建模：指用图形符号表示、刻画需求。对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。2）需求定义需求定义的目的：根据需求调查和需求分析的结果，进一步定义准确无误的软件需求，产生需求规格说明书。后续开发工作将依据需求规格说明书开展。需求分析员按照指定的文档模板撰写需求规格说明书。如果待开发的产品分为软件和硬件两部分的话，则应当分别撰写软件需求规格说明书和硬件需求规格说明书。软件需求规格说明书的格式参加表9-3。表9-3 软件需求规格说明书软件需求规格说明书1. 产品介绍（1）说明产品是什么，有什么用途。（2）介绍产品的开发背景。2. 产品面向的用户群体（1）描述本产品面向的用户的特征（2）说明本产品将给他们带来什么好处及他们选择本产品的可能性有多大。3. 产品应当遵循的标准或规范阐述本产品应当遵循什么标准、规范或业务规则（Business Rules）。违反标准、规范或业务规则的产品通常不大可能被接受。4产品范围阐述本产品“适用的领域”和“不适用的领域”，本产品“应当包含的内容”和“不包含的内容”。5产品中的角色阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。角色名称职责描述6产品的功能性需求60 需求分类功能类别功能名称、标识符描述Feature AFunction A.1Feature BFunction B.16.m.n Function M.N名称、标识符优先级功能描述数据及解释输入、输出操作序列等其它说明参考示例7产品的非功能性需求8其它需求9.2.3 需求评审与确认（1）需求评审项目经理先在项目内部组织人员进行非正式的需求评审，以消除明显的错误和分歧。需求分析人员根据内部评审意见，完善需求规格说明书。在内部评审期间不能解决的问题，留到正式评审时处理。项目经理邀请客户代表和最终用户代表一起评审软件需求规格说明书，大家尽最大努力使需求规格说明书能够正确无误地反映用户的真实意愿。（2）需求确认需求确认是指当需求规格说明书通过双方评审之后，开发方负责人和客户负责任人做书面承诺，使之具有商业合同效力。人们作出书面承诺之前务必要认真阅读文档，一定要明白签字意味着什么。“书面承诺”的示例如下：本需求规格说明书建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该需求规格说明书开展。如果需求发生变化，我们将按照“需求变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进度等。开发方负责人签字客户方负责人签字9.2.4 需求跟踪（1）需求跟踪的目的需求跟踪的目的是建立与维护“需求-设计编程-测试”之间的一致性，确保所有的工作成果符合用户需求。为什么要需求跟踪？即使严格线性顺序的开发模型也不能保证各个开发阶段的工作成果与需求保持一致。因为开发者是人而不是机器。由于人们的表达能力、理解能力不可能完全相同，人与人之间的协作很难达到天衣无缝的境界。（2）需求跟踪的方式A正向跟踪：检查需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。B逆向跟踪：检查设计文档、代码、测试用例等工作成果是否都能在需求规格说明书中找到出处。（3）需求跟踪矩阵正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加上必要的文字解释。表9-4为简单的需求跟踪矩阵示例。表9-4 简单的需求跟踪矩阵示例#需求规格说明书（版本、日期）设计文档（版本、日期）代码（版本、日期）测试用例（版本、日期）1标题或标识符，说明标题或标识符，说明代码名称，说明测试用例名称，说明2使用需求跟踪矩阵的优点是很容易发现需求与后继工作成果之间的不一致，有助于开发人员及时纠正偏差，避免干冤枉活。主要麻烦是，当需求或工作成果发生变更时，开发人员要及时更新需求跟踪矩阵。9.2.5 客户沟通在整个项目周期内，开发方应当与客户进行广泛地交流沟通，尽可能地消除双方对需求、项目计划、软件工作成果的误解和分歧，不断改善双方的人际关系，最终顺利地开发出符合客户需求的软件。客户沟通的主要方式有： 客户互动会议。开发方的项目人员、市场人员和客户代表周期性地开会，开发方向客户方汇报项目进展情况，双方对现阶段存在的问题进行协商，达成共识。 成果评审。项目经理应当邀请客户代表评审重要的工作成果，例如需求评审、用户界面评审，及早地消除双方对工作成果的误解和分歧。 联谊活动。为了不断改善开发方和客户方的人际关系，项目经理在时间、经费允许的前提下，主动邀请客户方人员参加联谊活动，例如运动、聚餐、娱乐等等。9.3 常见问题解答和实施建议9.3.1 如何理解“以客户为中心”人们开发商业软件是为了卖给客户，从客户那里赚钱。所以软件一定要符合客户需求，否则卖不出去。开发商业软件一定要以“客户为中心”，而不能以“技术为中心”。为了得到客户的金钱，企业不得不鼓吹：客户就是上帝，客户永远是正确的。谁都知道这不是真的。事实上，很多时候客户说不清楚需求、说错需求或者提出一些无法实现的需求。所以开发人员不仅要聆听客户讲述他们的需求，在收集到原始的客户需求后，一定要进行需求分析，消除错误、刻画细节，最终产生双方认同的需求规格说明书。之后，开发方要有策略地拒绝客户不合理的需求变更，既不得罪客户，又保护开发方的利益。9.3.2 需求建模工具UML、Rose（1）UML1997年11月，由Rational公司发明的“统一建模语言”UML被国际对象管理组织（OMG）采纳，此后UML成为面向对象建模语言的国际标准。UML的建模能力超过了以往任何一种面向对象方法，当然复杂性也随之膨胀。大多数软件开发人员没有兴趣阅读枯燥乏味的UML文档。（2）RoseRose是Rational公司基于UML的建模工具。Rose易学易用，它能交互式地构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等等，深得开发人员的喜爱。Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节，因此被很多人用于需求建模。需要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。世上不存在一个包罗万象的图它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。9.3.3 如何写好需求文档开发人员写不好需求文档是业界普遍存在的问题，原因和对策如下： 需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。所以要想写出好的需求文档，前提条件是把需求调查工作做好。 开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。可以毫不夸张地说，国内大部分软件开发人员的写作能力远不及开发能力。提高开发人员写作能力的根本办法就是让他们多练习写文档。另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。 开发人员撰写需求文档后，一定要认真检查文档，力求使需求文档达到：正确、清楚、无二义性，一致、必要、完备、可实现、可验证。9.3.4 如何使开发方和客户共同理解需求不论是复杂的项目还是简单的项目，开发人员和客户都有可能误解需求。所以双方的需求评审很重要。严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表，以确保需求文档准确反映客户真实的需求。当开发者理解的需求与客户所提的需求有冲突时，一般应