讲座5 目标、范围管理与需求工程

为什么实施该项目？ 项目要达到什么样的结果？ ？ 项目工作的具体内容是什么？ 如何实施该项目？ 如何定义该项目完成？

主要内容 目标管理 范围管理 需求管理 管理需求的目的 需求管理的困难性 软件需求特性 需求工程 如何获取需求 需求规格说明 需求管理工具

目标管理的早期发展 一般认为，目标管理的思想是得鲁克在1954年发表的《管理实践》一书中提出来的。 在此之前，一些企业也提出了类似的管理思想 如通用电气公司1954年为进行改组而拟订的广泛计划中，提出“管理决策的分散进行，要求用客观目标和对目标完成进度的客观测定来代替主观的评价和个人的监督。通过实行一种客观的测定计划，可把主观人员从具体事务中解脱出来……” 因此，目标管理的思想是管理学家和企业界共同努力的结果

目标管理的概念 目标管理是参与管理的一种形式：上下级目标形成“目标－手段”链 强调“自我控制”：人们应“控制”的是行为的动机而不是行为本身 促进下放权力：有助于协调集权与分权的矛盾 注重成果第一的方针：目标考核体系

项目目标 项目目标就是实施项目要达到的期望结果 特点 多目标性：时间，成本和性能 优先性:不同的目标有不同的优先级，在生命周期的不同时刻，优先级也不同（如性能是初始阶段考虑的重点，实施阶段重点考虑成本，时间在结束阶段显得更紧迫。） 层次性（总体目标，具体目标，具体计划） 如上大学，总体目标：自我实现－为将来获得更高的社会地位，取得更高收入，实现个人追求 具体目标 （1）在交纳一定学费的基础上，4年取得学位； （2）掌握软件工程方面知识和理念 （3）结交新朋友 具体计划:4年内的课程安排

项目目标的描述 应该 不应该 例子：如一个医疗部门的目标描述可能是“治愈所有的疾病”，或“治愈所有的病人”，两者表面相同，实质差别很大 应该 不应该 定量的，可度量的 定性的、不可度量的 使每个成员都能清楚认识 与项目成员无关 现实的 理想化的 简单的 复杂的 面向结果的 面向成本的 能够起激励作用 无激励作用 例子：如一个医疗部门的目标描述可能是“治愈所有的疾病”，或“治愈所有的病人”，两者表面相同，实质差别很大

目标管理的一些建议 目标要分等级层次 社会经济方面的总目标 使命 组织的总目标（长期的、战略的） 更详细的总目标 分公司目标 部门和单位的目标 个人的目标成效，个人的培养目标

目标要形成一个网络 如果各具体目标之间互相不关联，彼此不支持，人们就会采用对自己的职能似乎是有益的方法，但对公司整体而说可能是巨大的损失 注重目标的多样性 可以有多个目标 但是目标过多就等于没有目标

长期目标和短期目标互为整体 培养管理者的素质 目标管理的实践经验 选择短期目标的过程也是评定长期目标先后次序的过程 有效的管理者的共同之处不在于他们拥有什么，也不在于他们是什么样的人，而在于发挥有效性的实践 善于利用时间 注意贡献 善于发现和使用他人的长处，能用人之长，容人之短 要善于分清工作的主次先后 要善于作出有效的决策 目标管理的实践经验 对美国500家最大的工业公司调查，在403家中188家实施了目标管理方法，36家认为非常成功，占188家的19％左右。

目标 范围管理

项目范围管理 项目范围是指为了成功达到项目的目标，项目所规定要做的工作。 在项目环境中，“范围” 产品范围，即一个产品或一项服务应该包含哪些特征和功能 产品规格，即产品所包含的特征和功能具体是怎样的 项目范围，即为了交付具有所指特征和功能的产品所必须要做的工作。

项目范围的管理过程 启动：指组织正式开始一个项目或继续到项目的下一个阶段。启动过程的一个输出就是项目章程。项目章程正式承认项目的存在并对项目提供一个概览。 范围计划：指进一步形成各种文档，为将来项目决策提供基础。包括用以衡量一个项目或项目阶段是否已经顺利完成的标准等。 范围定义：指项目主要的可交付成果细分为更小的，更易管理的成分 范围核实：指对项目范围的正式认定。项目主要涉及人员，如客户或发起人要在这个过程中正式接受项目可交付成果的定义 范围变更控制：指对有关项目范围的变更进行控制。主要的过程输出是范围变更、纠正行动与教训总结。

软件项目的范围管理 需求管理

为什么要管理需求 系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。 为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。

需求管理的重要性 真的很重要吗？ 例：Our real-time example is based on the embedded software in the Ariane-5, a space rocket belonging to the European Space Agency (ESA). On June 4, 1996, on its maiden flight, the Ariane-5 was launched and performed perfectly for approximately 40 seconds. Then, it began to veer off course. At the direction of an Ariane ground controller, the rocket was destroyed by remote control. The destruction of the uninsured rocket was a loss not only of the rocket itself, but also of the four satellites it contained; the total cost of the disaster was $500 million (Newsbytes home page 1996; Lions et al. 1996).

需求分析的重要性 The reason: there was no discussion in the requirements documents of the ways in which the Ariane-5 trajectory would be different from Ariane-4. 统计资料： In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to find out how well they were faring. The results are sobering. Thirty-one percent of the software projects were canceled before they were completed. Moreover, in large companies, only 9% of the projects were delivered on time and cost what they were budgeted, and 16% met those criteria in small companies (Standish 1994).

需求管理的重要性

需求分析的重要性 5点事实 软件生命周期中，一个错误发现得越晚，修复错误的费用越高

需求管理的重要性 许多错误是潜伏的，并且在错误产生后很长一段时间才被检查出来 在需求过程中会产生很多错误 DeMarco在一份研究报告中指出，被检查出来的错误的56％产生的根源可以追溯到需求阶段。 AIRMICS所进行的一项调查发现，在一份美国军方大型管理信息系统的需求现格说明书(SRS)中存在着500多个错误，当然这仅仅是一个软件项目中的一次调查。 在需求阶段，代表性的错误为疏忽、不一致和二义性 美国海军研究实验室从20世纪70年代起就对软件开发技术不断地进行研究。得出的研究数据表明：A—7E项目中77％的需求错误特点是不明确：疏忽、不一致和二义性。按错误类型对这些错误分布进行分析的结果是：49％不正确的事实，31％疏忽，l 3％不一致，5％二义性

需求管理的重要性 需求错误是可以被检查出来的

需求管理的重要性 在需求过程中会产生很多错误(事实3和4)。 许多错误并没有在早期被发现(事实2)。 这样的错误是能够在产生的初期被检查出来的(事实5)。 如果没有及时检查出来这些错误，软件费用会直线上升(事实1)

需求管理的困难性

需求管理的困难性 需求不总是显而易见的，而且它可来自各个方面。 需求并不总是能容易用文字明白无误地表达。 存在不同种类的需求，其详细程度各不相同。 如果不加以控制，需求的数量将难以管理。 需求之间相互关联，而且需求也和软件工程流程中的其他可交付工件有关。 需求有唯一的特征或特征值。例如，它们的重要性和容易满足的程度都各不相同。 需求涉及众多相关方面，这意味着需求要由功能交叉的各组人员管理。 需求会变更。

什么是软件需求 需求为用户解决问题或达到目标所需的条件或权能 系统或系统部件要满足合同、标准、规范和其它正式规定文档所需具有的条件或权能 一种反映上述条件或权能的文档说明

需求的层次性 业务需求 质量属性 其它非功能需求 项目视图与范围文档 约束条件 用户需求 Use Case文档 系统需求 功能需求 软件需求规格说明

产生不合格需求的原因 产生不合格的需求说明的原因 无足够的用户参与，原因 用户需求的不断增加 模棱两可的需求 不必要的特性 感到与用户合作不如编写代码有意思 因为开发人员觉得已经明白用户的需求了 用户需求的不断增加 模棱两可的需求 不必要的特性 过于精简的规格说明 忽略了用户分类 不准确的计划

优秀需求具有的特性 完整性 正确性 可行性 必要性 划分优先级 无二义性 可验证性

需求工程的概念 需求工程 需求开发 需求管理 问题获取 分析 编写规格说明 验证

需求工程涉及人员

需求获取 需求的来源 访问并与有潜力的用户探讨 把对目前的或竞争产品的描述写成文档 系统需求规格说明 对当前系统的问题报告和增强要求 市场调查和用户问卷调查 观察正在工作的用户 用户任务内容分析

用户分类 用户及其分类 各种用户对系统具用不同的要求，如一个没有经验的用户关心系统是否简单易用，对于高级用户则关心产品的易用性和高效性。 因而需要对用户进行分类，每一个用户类将有自己的一系列功能和非功能要求 在项目中，要尽早为产品确定并描述不同的用户类，这样就能从每一个重要的用户类代表中获取不同的需求。

寻找用户代表 寻找用户代表 每个一个用户类必须有一名和几名用户代表参与软件开发项目周期 对于直接面向客户的项目，用户代表相对容易找到，对于商品化软件,用户代表（此时称为产品代表）比较难找到。 产品代表者必须是真正的用户，而不是用户的代理人，如主办者，产品客户，市场人员 必须给产品代表者足够的尊重，否则将挫伤他们的积极性

产品代表者 如何寻求产品代表者 与大公司建立联系 通过产品打折或者免费使用的方式来吸引产品代表者 要注意技术泄漏问题 真正聘请具有丰富经验的合适的产品代表者

“谁说了算” “谁说了算？”问题 如果个别用户不能在需求方面达成一致的意见，那么必须由产品代表者作出决策。这种方法的实质是授权给产品代表者，由其解决他们所代表用户的需求冲突问题 如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于呢决定哪一个用户类所占份额最大

“谁说了算” 不同公司的客户可能都要求产品按照他们各自的喜好来设计。运用项目的业务目标来决定哪些是你最关心的客户。非核心客户的需求可以安排在下一个版本中开发。 客户经理与真正用户的需求相冲突。用户需求必须与业务需求一致，因此，必须说服那些没有亲自使用过产品的经理服从代表他们用户的产品代表者提出的详细的用户需求和功能性规格说明。 当开发者想像的产品与客户需求冲突时，通常应该由客户作出决策，然而，不要陷入“客户总是对的”的陷阱中去，现实中，客户并不总是对的。

“谁说了算” 如果市场部门提出的需求与开发者所想要开发的系统发生冲突时，通常由于市场人员作为客户的代理人，市场需求具有更重的分量，但是，市场人员可能会一味地迁就客户需求。 没有简单的正确答案

聆听客户的需求：访谈 访谈 要点： 事先需调查涉众或用户以及公司的背景。 访谈前对问题进行复审。 在访谈期间要参照一定的格式，以确保提出正确的问题。 在访谈结束时总结两、三个最为重要的问题。重复您听到的内容，以确认您的理解是否正确。

聆听客户的需求：访谈 寻求客户 业务流程 客户是谁？ 用户是谁？ 他们的需要是否不同？ 他们具有什么背景、能力和环境？ 问题是什么？ 想要解决该问题的原因是什么？ 是否存在其他想要解决该问题的原因？ 成功解决方案的价值是什么？ 现在您如何解决问题？ 时间和价值之间如何折衷？ 在其他什么地方可以找到此问题的解决方案？

聆听客户的需求：访谈 产品特点 该产品解决什么问题？ 该产品会引起什么业务问题？ 对于用户来说，存在着什么危险？ 产品将处于什么环境？ 您对可用性有什么期望？ 您对可靠性有什么期望？ 需要何种性能/精度？

聆听客户的需求：访谈 通用问题 我是否提问了太多问题？ 我的问题是否与主题相关？ 您是回答这些问题的合适人选吗？ 您的答案是必需的吗？ 稍后我可以提出更多问题吗？ 您愿意参加需求复审吗？ 还有其他应该向您提出的问题吗？

聆听客户的需求：访谈 注意： 进行访谈对话时，要记住： 不要让对方说明他们不经常说明的事情。 不要提出假设用户可以说明复杂活动的问题。 一般来说，人们能做许多自己无法说明的事情。 经验主义的根据 - 缺少相关性。 提出可以自由回答的问题。 回避以“为什么”开头的问题，因为这类问题会让对方采取防范的态度。 进行访谈对话时，要记住： 不要期望获得简单的答案。 不要只求得到对方的回答而匆忙草率地进行访谈。 倾听，倾听，再倾听！

聆听客户的需求：研讨班 研讨班 研讨班开始前 协调员需要邀请应该参加研讨班的涉众，从而确定参加研讨班的小组。应该向参加者提供“热身”材料，供他们在到会之前阅读。协调员负责研讨班的后勤工作，比如发出邀请、申请带有会议所需设备的适当会议室，以及分发研讨班议程等。

聆听客户的需求：研讨班 召开会议 整理结果 协调员主持会议，其中包括： 给每个人发言的机会。 确保会议不脱离正题。 收集关于适用的需求属性的意见 记录调查结果。 总结会议并得出结论。 整理结果 需求研讨班结束后，协调员与系统分析员需要花些时间对调查结果进行综合，并将信息精简为可介绍的形式。

聆听客户的需求 如何知道你已经完成了需求的获取，一些线索 如果用户不能想出更多的需求 如果用户提出新的需求，但你可以从其它需求的相关功能需求重获得这些新的需求 如果用户开始重复原先讨论过的问题 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品

编写需求文档 需求文档要求 完整性 一致性 可修改性 可跟踪性

软件需求规格说明 软件需求规格说明的作用 客户和营销部门依赖它了解他们所能提供的产品 项目经理根据包含在软件需求规格说明重描述的产品来制定规划并预测进度安排、工作量和资源 软件开发小组依赖它来理解他们将要开发的产品 测试小组利用它来制定测试计划，测试案例 软件维护人员和支持人员依据它了解系统的功能 产品发布组根据它编写客户文档，包括用户手册和帮助 培训人员根据它编写培训教材

软件需求规格说明 文档可读性 对节、小节和单个需求的号码编排必须一致 在右边部分留下文本注释区 允许不加限制地使用空格 正确使用各种可视化强调标志 创建目录表和索引表有助于读者寻找所需信息 对所有图和表制定号码和标识号

软件需求规格说明 需求的标识 不完整的需求 用户界面与软件需求说明 序列号，如UR-2,SRS13 层次化编码，如3.2.4 层次化文本标签，“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。” print.copies.confirm 不完整的需求 进行特殊的标识TBD(to be determined)，在继续进行构造需求集合之前，必须处理完所有TBD 用户界面与软件需求说明 用户界面是解决方案，而不是需求，但是可以更清楚的定义需求。 可以画一些草图

软件需求规格说明 a 引言 b.综合描述 a.1目的 a.2文档约定 a.3预期的读者和阅读建议 a.4产品的范围 a.5参考文献

软件需求规格说明 C.外部接口需求 b.3用户类和特征 b.4运行环境 b.5设计和实现上的限制 b.6假设和依赖 c.1用户界面

软件需求规格说明 D.系统特性 其它非功能需求 其它需求 附录A:词汇表 附录B:分析模型 附录C:待确定问题的类标 d.1说明和优先级 e.1性能需求 e.2安全设施需求 e.3软件安全性需求 e.4软件质量属性 e.5业务规则 e.6用户文档 其它需求 附录A:词汇表 附录B:分析模型 附录C:待确定问题的类标

软件需求规格说明 需求说明语句 保持语句和段落的简短 采用主动语态的表达方式 编写具有正确的语法和标点的完整句子 使用的术语应该和词汇表中定义的一致 需求陈述应该具有一致的式样，例如“系统必须……”，或者“用户必须……”，并紧跟一个行为动作和可观察的结果，例如“仓库管理子系统必须显示一张在所请求的仓库中有存货的药品名单。”

软件需求规格说明 为了减少不确定性，避免采用模糊的、主观的术语，例如，用户友好、容易、简单、迅速、有效、支持、许多、最新技术、优越的、可接受的和健壮的。 避免使用比较性的词汇，例如：提高，最大化，最小化和最佳化。定量地说明所需要提高的程度或者说清一些参数可接受的最大值和最小值。

节选自目前我国的一些实际系统中的功能性需求的说明方式：“根据详细的系统调研和需求分析，……系统的功能必须满足以下需求： 1)编制计划、计划工程拨款管理，……，工程批复管理，工程进度统计； 2)工程项目管理； 3)计划拨款、征费收缴信息及其他收拨款信息查询统计； 4)路产管理，违章建筑管理，工程材料管理，……，超限运输管理； 5)养征信息查询管理，收费站信息管理； 6)文档管理，会议管理，合同管理，……，驾驶员外勤管理，常用管理； 7)养护信息管理，公路维护预警； 8)路况信息管理，交通量信息管理，科研项目信息管理；

需求表达 “产品必须在固定的时间间隔内提供状态消息，并且每次时间间隔不得小于60秒” 后台任务管理器应该在用户界面的指定区域显示状态消息 在后台任务进程启动之后，消息必须每隔60（+_10）秒更新一次，并且保持连续的可见性。 如果正在正常处理后台任务进程，那么后台任务管理器必须显示后台任务进程已完成的百分比 当完成后台任务时，后台任务管理器必须显示一个“已完成”的消息。 如果后台任务中止执行，那么后台任务管理器必须显示一个出错信息。

需求表达 “产品必须在显示和隐藏非打印字符之间进行瞬间切换” “用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有HTML标记之间进行切换。”

需求表达 “分析程序应该能生成HTML标记出错的报告，这样就可以使HTML的初学者使用它来迅速排错” 如果分析过程中未发生任何错误，就不必生成任何错误报告

需求优先级 关键（或首要）。该等级的需求与系统的主要任务、基本功能以及待开发的功能有关。如果这些关键需求缺失，系统将无法完成主要任务。 重要（或其次）。该等级的需求与系统功能的支持有关，比如统计数据编译、报告生成、监督和功能测试等。如果它们缺失，系统仍然可以（在一段时间内）完成基本任务，但服务质量有所下降。 辅助（不错）。这些需求着重“舒适性”方面的功能，与系统主要任务无关，但有助于系统的使用或市场定位。

需求评审 以原来的需求为基础的工作完成后，要修补需求错误需要大量的工作，研究表明：比起在需求开发阶段由客户发现的一个错误，然后更正这一错误需要多花68到110倍的时间。

需求评审 进入审查的标准 文档已经符合标准化 文档已经经过了语法检查 作者已经审查了文档在版面上的错误 已经得到了审查员所需的先前或参考文档 所有未解决的问题都被标记为TBD 包括了文档中使用过的术语词汇表

需求评审 审查结束 已经明确阐述了审查员提出的所有问题 已经正确修改了文档 修订过的文档已经进行了语法检查 所有TBD问题都已经解决 文档归档

需求管理 需求管理 变更控制 建议变更 分析影响 作出决策 交流 合并 测量需求的稳定性 版本控制 确定需求文档版本 确定单个需求文档版本 需求跟踪 定义对其它需求的连接链 定义对其它系统元素的连接 需求状态跟踪 定义需求状态 跟踪需求每一个状态

需求管理工具 Caliber-RM http://www.tbi.com DOORS http://www.qssinc.com QSSrequireit: http://www.qssrequireit.com RequisitePro: http://www.rational.com RTM Workshop: http://www.chipware.com Vital Link: http://www.complianceautomation.com