第2章需求管理.ppt

1、第二章 软件需求管理,1,主要内容,2,一、什么是软件需求？,软件需求概念（2.1.1） 软件需求层次（2.1.2 ） 获取软件需求的重要性 获取软件需求的复杂性和面临的问题 解决的方法和手段,3,1.软件需求概念（2.1.1）,1997版IEEE软件工程标准中需求的定义： 系统或系统部件要满足合同、标准、规范或其它正式文档所需具有的条件或能力； 用户解决问题或达到目标所需的条件或能力； 一种反映上面、所描述的条件或能力的文档说明。,用户角度,开发者角度,4,关于软件需求的注意事项,软件需求关注用户的期望、要求和需要，不是解决方案 要区分what和How 例如，要采用什么算法，不是用户需求 并

2、不是所有方面的要求都是软件需求 功能、性能、设计约束、时间进度等 重量、软件大小等不是用户需求 并不是所有用户的期望和要求都是软件需求 用户需求必须中肯，有意义 例如，记录图书的厚度等不是用户需求,5,2.软件需求层次（2.1.2）,软件需求分成四个抽象层次：,6,软件需求的抽象层次（续1）,7,软件需求的抽象层次（续2）,抽象,具体,原始问题描述和用户需求的抽象层次比较高能帮助我们在较高的抽象层次上进行交流，便于用户和软件开发人员之间的理解和沟通。 系统需求和软件设计描述则是具体的，可以根据它们来进行编码实现。 通常情况下，经常提到的是:用户需求和系统需求,8,A. 用户需求,用户需求从用户

3、的角度描述系统的需求，以便没有专业技术背景的用户能看懂 用户需求只描述系统的外部行为，尽量避免涉及系统内部的设计特性， 用户需求不使用任何实现模型来描述，而只能通过自然语言，图表，图形等来叙述,用户角度,外部行为描述,叙述自然,关键词,9,A. 用户需求（续1）,用户需求在使用自然语言可能出现描述困难、需求混乱等问题 因此写需求文档应遵守一些简单原则： 标准的格式 使用一致的语言 使用特殊文本 尽量避免专业术语,10,B. 系统需求,系统需求是比用户需求更为详细和专业的需求描述，是系统实现的依据一个完整且一致的系统需求描述，是软件设计的起点 系统需求描述通常采用结构化语言和过程设计语言PDL.

4、,11,B. 系统需求（续1）,2.1.2软件需求层次,系统需求的描述语言,12,B. 系统需求（续2）,13,(1) 功能需求-系统需求的三类需求,功能需求描述系统所应提供的功能和服务，包括系统应该提供的服务，对输入如何响应及特定条件下系统行为的描述,14,(2) 非功能需求-系统需求的三类需求,非功能需求是指那些不直接与系统的具体功能相关的一类需求，但它们与系统的总体特性相关，如可靠性、响应时间、存储空间等。 非功能需求定义了对系统提供的服务或功能的约束，包括时间约束、空间约束、开发过程约束及应遵循的标准等。,15,(2)非功能需求-系统需求的三类需求(续),对产品的行为进行描述,描述用户

5、与开发人员所在机构的政策和规定,包括系统的所有外部因素和开发过程,16,非功能需求的类别,17,(3) 领域需求-系统需求的三类需求,领域需求的来源不是系统的用户，而是系统应用的领域，反应了该领域的特点。 领域需求可能是功能需求，也可能是非功能需求，其确定需要领域知识。,18,以下是某软件系统的需求，请区分哪些是功能需求，哪些是非功能需求？ 1提供库房查询功能 2在1分钟内给出季度统计报告 3查询操作延迟时间不大于1秒 4提供统计与打印功能 系统交付日期为2011年12月30日 系统前台必须运行在windows OS下,提问,19,3.获取软件需求的重要性,软件开发的基础和前提 只有在明确了软

6、件需求之后才能开展有针对性的软件开发工作 没有需求无法进行设计和编码 制定软件开发计划的基础 只有知道你想做什么，才能知道做这些东西需要多少工作量？ 不知道软件需求也就不知道工作量的大小，因而不能制定计划 最终目标软件系统验收的标准 只有知道你想做什么，才能知道你最终是否做好了 没有定义明确的需求，就不知道最终基于什么进行验收,20,4.获取软件需求的复杂性,系统复杂和庞大 如何将软件需求得到？描述清楚？ 片面, 不完全 如何保证得到了所有的软件需求？ 模糊, 不准确 如何保证把需求说清楚和准确？ 不一致, 歧义 如何保证所描述的需求是不矛盾的？ 及时性 当需求变更时，如何让相关人员都知道需求

7、已经变更？ 软件需求变动带来的问题 波动性 放大性,21,5.解决的方法和手段,技术层面 需求分析方法、技术和工具 方法：数据流、面向对象 技术：抽象、建模、多视点、原型、 工具：UML，Rose，Word，Excel，RequisitePro 管理层面 对需求分析中的人、活动和产品进行管理 形成新的研究领域：需求工程,22,23,二、如何获取软件需求？,需求工程概念(2.1.4,2.1.5) 需求开发活动(2.2.1) 需求获取(2.2.2 ) 需求分析(2.2.3) 编写需求文档(2.2.4) 需求验证(2.2.5),24,1.需求工程概念,需求工程是一个包括创建和维护需求文档所必需的所有

8、活动的过程，是将用户非形式化的软件需求转变为形式化的需求规格说明的过程。,需求分析活动不再仅限于软件开发的最初阶段，而是贯穿于软件项目开发的整个生命周期。 20世纪80年代，需求工程逐步形成，它属于软件工程的子领域。,25,需求工程发展趋势,26,需求工程研究内容,需求工程可分为需求开发和需求管理，前者测重于需求的生成，而后者测重于需求变更的控制。,27,需求工程研究内容,需求开发和需求管理是有界限的,28,2.需求开发活动,分四个阶段,按项目的大小和特点等实际情况，可以在上述常规过程的基础上定制合适的过程,29,需求开发操作矩阵,30,3.需求获取,用户： 客户(Customer) 最终用户

9、(End user) 间接用户(或称为关系人) 除了客户和最终用户之外，软件开发方不 能疏忽另一类用户-“间接用户”，千万别“大意失荆州”！,间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品 有很大的影响。例如，财务软件开发商在把“财务软件”交给客户之前，这个“财 务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被 政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付 钱给财务软件开发商，反而要收取鉴定费、手续费等。同理，市面上流通的信息 安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴 上“非法经营”的帽子就惨了。

10、,31,4.需求分析,需求分析是指从用户处获得需求、形成与用户需求相一致的、可供阅读的软件需求规格说明书的过程 通过对应用问题及其环境的理解和分析，准确、一致和完全地刻划用户需求，并达成一致，形成软件需求规格说明书SRS,32,5.编写需求文档,根据软件需求初步描述和软件需求模型，撰写软件需求规格说明书SRS SRS精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境（软件，硬件，通信端口和人）接口的简洁完整的描述性文档。,33,关于软件需求规格说明的标准,GB/T9385-2008 计算机软件需求规格说明规范 IEEE标准830-1998,34,需求规格

11、说明模板（参考IEEE 830-1998),35,6. 需求验证,对需求文档中定义的需求执行多种类型的检查 正确性 软件需求是否是用户所需要的 例如，一个读者最多能借10本书 准确 是否把软件需求描述清楚了 例如，一个读者包括诸多信息如名字，单位等等 无歧义性 软件需求描述是否会引起不必要的误解和认识上的偏差 例如，用户和客户 完全性 是否所有的需求都已经包含了 可验证性 是否有手段来验证需求已经实现了 例如，查询结果应该很快得到 一致性 软件需求是否会相互矛度 可理解和可修改性 软件需求描述是否简洁、直观，易于修改和维护 可追踪性 软件需求是否易于追踪,36,需求开发的主要困难,知识技能问题

12、 态度问题 合作问题 用户说不出需求 双方误解需求 开发人员写不好需求文档 用户经常变更需求,37,需求开发的主要困难及对策1,知识技能问题,自学 培训 请既懂软件又懂应用域知识的行家来帮忙,38,需求开发的主要困难及对策(2),态度问题： 开发人员的错误观念： 需求是用户的事情，不是我们的事情; 我们为用户开发软件，用户应该告诉我们应该开发什么； 用户说不清楚需求或经常变更需求，问题是由用户造成的，应当用他们自己负责。,在有限的时间内获取准确而细致的用户需求，是需求分析员的天职，做不到则是失职。,39,需求开发的主要困难及对策(3),合作关系 用户常有的想法： 我回答了你们的问题，该讲的都讲

13、了，我们付钱给你们，难道 还要我伺候你们不成？ 我还要干自己的事，别打扰我了。 你们自己想办法把活干好吧。,需求分析员不是销售人员，出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力，否则会把事情搞砸的。,40,需求开发的主要困难及对策(3续),合作关系 对于重大的、复杂的项目： 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，以协议的方式确定合作关系。,好话和丑话说在前头，能减少今后的摩擦。,41,需求开发的主要困难及对策(4),用户说不出需求 真的不知道需求是什么 对需求只有朦胧的感觉 心里明白，但说不清楚需求，表达能力有问题。,需求分析

14、员不能以此为借口而草率地对待需求开发工作，必须设法搞清用户的真正需求，这是职责所在。,42,需求开发的主要困难及对策(5),双方误解需求 答非所问经常会发生,不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求，所以需求确认工作（属于需求管理）必不可少。,43,需求开发的主要困难及对策(6),开发人员写不好需求文档 需求调查不充分，获取的信息太少或者太乱。 写作能力较差。,做好需求调查工作。 多练习文档写作，熟能生巧，提供合适的文档模板及比较好的示例文档，尽可能地降低写作难度。,44,需求开发的主要困难及对策(7),用户经常变更需求,需求变更并不可怕，可怕的是如果需求变更失去控制，

15、导致项目混乱。所以需求变更控制是需求工程的重要活动。,45,案例,按照初步的项目计划，老钱带领项目组的部分成员(需求分析小组)开始进驻用户场地，开展需求调查工作，但在需求分析和后续开发过程中陆续出现了许多与用户需求有关的一系列问题，影响软件项目的实施 整个项目规模比较庞大，需求分析小组不知如何开展工作？从何处下手？对需求分析的复杂性和难度估计不足。 需求分析小组不能有效工作：不知哪些属于用户需求，哪些不是？不知怎样才能获取用户需求？如何把它分析清楚？ 不知应该按照怎样的规范书写软件需求规格说明书? 得到的软件需求质量不高：说不清，遗漏，矛度，罗嗦. 需求评审不严格，导致遗漏了许多需求，获取的用

16、户需求不一致、描述的不清晰和准确,46,案例,由于用户没有参加需求评审，使得许多软件需求没有得到用户的认可，最终所开发出的软件不能满足用户的要求，用户拒绝接收软件，并拒绝付款 由于软件需求的不准确性、不一致性和二义性，在软件开发阶段，软件设计人员不得不通过用户再次确认需求 在开发过程中，用户的需求仍然在改变，需求分析小组负责获取改变了的用户需求，然而这些改变了的需求没有得到有效的管理和控制，没能将变化的需求及时反馈给软件开发小组，导致这些需求未能在待开发的软件中得到体现 由于需求未能得到有效管理，在最终项目验收过程中出现了令人不愉快的情况，实际开发的软件没能完全反映用户的需求，导致用户不满意，

17、项目延期,47,案例提示我们,需求分析是极为重要的 需求分析是困难和复杂的 用户需求经常性的变更是正常的 为了保证软件需求的质量，必须对需求分析的人、过程和产品进行有效管理 需求管理不善将会导致严重后果,48,49,为什么要管理软件需求？（2.3.1）,软件需求非常重要 获取软件需求非常复杂和困难： 需求过程中，需求的供求双方经常会遇到双方不能达成共识或双方达成共识的内容其实有相当大的出入等情况。 软件需求具有易变性和难以表述性,软件项目中的问题都是在需求分析阶段埋下的祸根。为了确保软件需求处于受控状态,所以需要有科学的方法来管理软件需求。,50,图2.6 需求获取的偏差,51,需求管理的困难

18、性（P61),需求不总是显而易见的，它可来自各个方面 需求并不总是能容易用文字明白无误地表达 存在不同种 类的需求，其详细程度各不相同 如果不加以控制，需求本身的数量都将难以管理 需求之间相互关联，而且需求也和软件工程流程中的其它可交付工作有关。 需求有唯一的特征或特征值。 需求涉及到从多相关方面，由各功能交叉的各组人员管理 会有变更 可能对时间敏感,52,需求管理的内容,参与需求分析和评审的人员 软件需求文档 需求分析过程 需求变更,53,需求管理的目标,需求管理的目标有二个: 使软件需求受控,并建立供软件工程和管理使用的需求基线。 使软件计划、产品和活动与软件需求保持一致。,需求管理的目的

19、是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解。,54,需求管理的原则,需求一定要分类管理 需求必须分优先级 需求必须文档化 需求一旦变化，就必须对需求变更的影响进行评估 需求管理必须与需求工程的其他活动紧密整合,55,需求管理活动,需求管理是一个对系统需求变更了解和控制的过程。需求管理的过程是与其他需求工程过程相互关联的。 初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的草稿版本，需求管理活动就开始了。,56,需求管理活动,按项目的大小和特点等实际情况，可以在上述常规过程的基础上定制合适的过程,57,需求管理活动的具体内容,58,需求变更的原因1,软件项目的需求总

20、是在变化着,一般原因有： (1)在项目的早期所有的问题不可能被完全定义,软件需求是不完全的,注定了需求需要变更。 (2)随着软件项目的进行,软件开发人员对问题的理解会发生变化,这些变化也要反馈到需求中去。,59,需求变更的原因2,大型软件系统还可能存在如下导致需求变更的原因: (1)不同类型的用户的需求可能是冲突的或是矛盾的,最后的系统需求是它们之间的一个妥协.这种妥协的程度在项目进行过程中有可能发生改变,从而导致系统需求的改变。 (2)系统购买者或系统最终用户很少是同一人,有的系统客户对系统提出的一些需求可能和最终用户需求不一致。,60,需求变更带来了,提出需求变更的动机是好的，目的是希望产

21、品更加符合用户的需求。 对项目开发小组而言，变更需求意味着： 调整资源、 重新分配任务、 修改前期成果 开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。,61,需求变更控制的动机,(1)如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 (2)如果需求变更带来的坏处大于好处，那么拒绝变更。,62,需求变更管理过程,变更管理过程分为三个阶段： 变更描述 变更分析 变更实现,63,变更描述,变更描述阶段要对需求问题或变更提议进行分析以检查它的有效性，进而产生一个更明确的需求变更提议。,64,需求变更请求表,

22、65,变更分析,变更分析阶段对被提议的变更产生的影响进行评估。一旦分析完成，就有了对此变更是否执行的决策意见。,66,变更实现,实现变更时，需求文档及系统设计和实现都要做修改。 错误：先对系统做变更然后再回头修改需求文档，这导致需求描述和系统实现不同步。 需求文档应该有一个很好的形式，使得变更不会带来大量文字的修改。对于程序文档的可变性则通过最小化外部引用和尽量使之模块化来实现。,67,变更影响分析,进行需求变更影响分析,应评估每项选择的需求变更,以确定它对项目计划安排和其他需求的影响,同时明确与变更相关的任务并评估完成这些任务需要的工作量。变更影响分析有助于做出信息量充分的变更决策,确定对变

23、更是修改还是抛弃,或者创建新系统以及评估每个任务的工作量.,68,需求变更的代价,图2.9 需求变更的代价,69,2.3.5 需求变更管理,变更对进度的影响，要看变更是否处于项目的关键路径。 如果一个处于关键路径的任务因变更而延期,则项目肯定赶不上预定进度,但如果能避免变更影响关键任务,则变更不会影响项目的进度表,70,需求变更影响分析模板,影响分析报告的模板,用来报告进行需求变更的影响分析。 变更控制委员会仅需要影响分析的总结。,71,需求变更控制流程,72,图2.12 需求变更状态转换图,73,需求属性,(1)需求的创建时间 (2)需求的版本 (3)需求的创建者 (4)需求的批准者 (5)

24、需求的状态 (6)需求的原因或根据 (7)需求涉及的子系统 (8)需求涉及的产品版本 (9)需求的验证方法或测试标准 (10)需求的优先级 (11)需求的稳定性,需要考虑的属性,需求的属性 需求还有一些相关的属性,这些属性的定义及更新是需求管理的重要内容.需求的属性为需求提供了背景资料和上下文关系。,需求的优先级,即从实现需求所涉及的代价、收益、成本、风险四个方面考察需求的优先级,需求的稳定性，表示将来需求可能变更的程度，稳定性越差，意味着需求越容易发生变更，因而应给予较多的关注。,74,何谓需求状态?,需求状态是需求的一项重要属性,跟踪需求的状态是需求管理的一个重要方面。 状态是一种事物或实

25、体在某一个时间点或某一阶段的情况的反映。 需求状态是指某时间点需求的一种情况反映。,75,需求状态,可把需求状态分为如下8种 已建议 已批准 已拒绝 已设计 已实现 已验证 已交付 已删除 跟踪每个需求状态是需求管理的一个重要方面 跟踪需求状态必须要有清晰的要求，且指定允许修改状态信息的人员和每个状态变更应满足的条件。,76,图2.13 需求状态的变迁,需求的状态会随着不同事件的发生而变迁； 状态变迁的一般规则和应满 足的条件如图所示。,77,2.3.7需求文档版本,如果没有很好的需求文档版本管理,就容易造成资源浪费。 需求文档版本控制是需求管理的一个必要方面。,78,做好需求文档版本控制,必

26、须保证如下几点: 统一确定需求文档的每一个版本,保证每个成员都能得到当前的需求版本; 清楚地将变更写成文档,并及时通知项目开发所涉及的人员; 为尽量减少困惑、冲突、误传，应只允许指定的人来更新需求文档。,需求文档版本,版本控制的最简单方法： 在每一个公布的需求文档的版本包括一个修正版本的历史情况： 已作变更的内容 变更日期 变更人的姓名 变更的原因， 根据标准约定手工标记软件需求规格说明的每一次修改。 使用专门的需求管理商业工具,79,需求评审,评审方式： 正式技术评审（同行评审） 非正式技术评审 评审人员主要要开发方和客户方的代表组成,80,严格地讲，应当检查需求文档中的 每个需求 每一行文字 每一张图表 评判需求优劣的主要指标有： 正确性、清晰性、无二义性、一致性、必要性、完备性、可实现性、可验证性。,需求评审的困难及对策,需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后面越马虎。当需求文档很长时，几乎没人能够坚持到最后。 需求评审涉及的人员可能比较多，有些时候要这么多人聚在