《软件过程的需求管理.ppt》由会员分享，可在线阅读，更多相关《软件过程的需求管理.ppt（60页珍藏版）》请在三一办公上搜索。
1、软件过程管理,-Ch.4 软件过程的需求管理,软件过程的需求管理,开发软件系统最为困难的部分就是准确说明开发什么。弗雷德里克布鲁克斯,理解,1.什么是需求 2.了解客户、最终用户、间接用户3.需求工程基本概念4.需求开发的主要困难与对策5.如何开展需求调查6.如何进行需求分析7.什么是好的需求规格说明书8.如何定义产品需求9.需求管理：确认、跟踪、变更控制,人们并不清楚应该做什么，却一直忙碌不停地开发。,1.什么是需求,1.1 需求的基本概念 宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。所以如果只有一些零碎的对话
2、、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。1.2 需求的重要性Frederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。,2.了解客户、最终用户、间接用户,
3、2.1 基本概念“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。2.2 客户是掏钱买软件的人，所以他是“上帝”某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。“现代营销学之父”菲利普科特勒所著的市场营销导论是这样描述客户的：客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，
4、而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。与客户打交道的主要目的是：一是获取需求，二是签合同。不要把钱仍到水里。,2.了解客户、最终用户、间接用户,2.3 即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。公司新员工上产品培训课，有位小领导匆匆赶来
5、作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿.。”2.4 重视“间接用户”，千万别“大意失荆州”间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而要收取鉴定费、手续费等。同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公
6、安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。,3.需求工程基本概念,3.1 什么是需求工程把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构图,软件需求工程,所有与需求直接相关的活动统称为需求工程，需求工程分为了两个部分：需求开发和需求管理。其中，需求开发又分为了需求获取、需求分析、需求定义和需求验证4个部分，而需求管理则包含了变更控制、版本控制、需求跟踪和需求状态跟踪,软件需求包括三个不同的层次：业务需求、用户需求和功能需求（也包括非功能需求）。,软件需求工程,业务需求（business requi
7、rement）反映了组织机构或客户对系统、产品的概括的目标要求，它在项目视图与范围文档中予以说明。主要的目的是对企业目前的业务流程进行评估，得出一个业务前景。业务需求的确定对后面的用户需求和功能需求起到了限制作用。,用户需求(user requirement)文档描述了用户使用系统而完成的任务的集合，用户需求在用户案例（user case）文档或方案脚本中予以说明。收集和分析用户需求是不容易的，因为很多需求是隐形的，很难获取，更难保证需求完整，而需求又是易变的，这就要求用户和开发人员进行充分地交流。,功能需求(functional requirement)定义了开发人员必须实现的软件功能，它源
8、于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。非功能需求描述了系统展现给用户的行为和执行的操作等，包括要遵从的业务规则、人机接口、安全性和可靠性等要求。,3.需求工程基本概念,3.4 需求工程的一些感悟 不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求
9、变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。“主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。“领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。,4.需求开发的主要困难与对策,4.1 知识技能问题 应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说
10、“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。当需求分析员缺乏应用域知识时，他该怎么办？首先他要有勇气做事，否则连实践的机会都没有。其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。4.2 态度问题 相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开
11、发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。,4.需求开发的主要困难与对策,4.3 合作关系 如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。倘若用户
12、不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧。对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样
13、风险太大。开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。,4.需求开发的主要困难与对策,用户在需求工程中的“权利”1.有权要求开发方派遣资质合格的需求分析员和相关人员。2.有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。3.有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能
14、准确地反映用户真实的意愿，可以拒绝在需求文档上签字。4.如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。用户在需求工程中的“义务”1.以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。2.乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。3.在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。4.与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。,4.需求开发的主要困难与对策,4.4 用户说不清楚需求 用户说不清楚需求是普遍现象，这是让开发人员头痛的大
15、问题。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧，反正是花公家的钱。有些用户虽然心里明白想要什么，但却说不清楚需求。比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋。需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求，
16、需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。,4.需求开发的主要困难与对策,4.5 双方误解需求 人们在交流的时候，经常会发生“问非所求，答非所问”的事情。有时用户会把开发人员的建议或答复给想歪了：有一个软件开发人员滔滔不绝地向用户讲解在“信息高速公路上做广告”的种种好处，用户听得津津有味。最后，心动的用户对软件开发人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好
17、也白搭。这类错误连高智商的外星人都不能避免：有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。有趣的是，车里住着一种叫作人的寄生虫，这些寄生虫完全控制了车。”不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。,4.需求开发的主要困难与对策,4.6 开发人员写不好需求文档 需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。古时候，一书生在考试前补习“写文章”，成天愁眉苦脸。其夫人甚为不解，问：“相公，你写文章比我生小孩还难吗？”书生
18、长叹一声：“娘子你哪里知道我的难处啊！你生小孩时肚子里有东西，可我写文章时肚子里没东西啊。”所以要想写出好的需求文档，前提条件是把需求调查工作做好。开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。可以毫不夸张地说，国内90以上的软件开发人员，他们的写作能力远不及开发能力。提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧。另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。,4.需求开发的主要困难与对策,4.7 用户经常变更需求 需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。如果在
19、项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。,需求开发,需求
20、开发的目的是通过调查与分析，获取用户需求并定义产品需求。,获取数据,分析、处理,目标系统模型,需求获取,系统分析员,从数据流和数据结构出发，找出系统各元素之间的联系、接口特征及设计限制、能否满足功能需求,需求获取概述,需求获取是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。,需求获取的方法,需求研讨会头脑风暴用例模型访谈角色扮演原型法,基于用例的需求获取,课堂案例：学生学籍处理业务,学生学籍处理业务每学期开学时，各学办进行注册管理，注册信息记录在在校生信息卡中。学生转专业由本人向所在系提出申请，教务处审批。在本系内转专业，由学生所在系考核同意，报教务处审批；在学校范围内转专业
21、（跨系），由学生所在系推荐，拟转入系考核同意，报教务处审批。转专业手续应在每学年开学前办理。,课堂案例：学生学籍处理业务,需求定义,需求定义指的是解释涉众需求,并根据需求规模整理成对要构建系统的明确的说明。前景文档是用一般的语言定义系统特征的文档软件需求规格说明书是用更专业的术语定义系统特征的文档。,软件需求规格说明书,0.文档介绍0.1 文档目的0.2 文档范围0.3 读者对象0.4 参考文档0.5 术语与缩写解释1.产品介绍提示：(1)说明产品是什么，什么用途；(2)介绍产品的开发背景。2.产品面向的用户群体提示：(1)描述本产品面向的用户(客户、最终 用户)的特征；(2)说明本产品将给他
22、们带来什么好处？特们选择本产品的 可能 性有多大？3.产品应当遵循的标准或规范提示：阐述本产品应当遵循什么标准、规范或业务规则。,4.产品的功能需求,5.产品的非功能需求,6.其他需求,软件需求规格说明书,需求确认,为什么需要需求评审？,修订一个缺陷的相关成本,需求确认,如何进行需求评审？（1）分层次评审目标性评审功能性评审操作性评审（2）分阶段评审,2 需求评审面临的困难,需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，
23、有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了，争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。
24、我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。,需求确认,如何保证需求规格说明书的质量？正确性完备性易理解性一致性可行性健壮性易修改性易测试性和可修改性易追溯性兼容性,.什么是好的需求规格说明书,.1 正确 需求规格说明书应当正确地反映用户的真实意图，“正确”是产品需求规格说明书最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对需求规格说明书进行确认。.2 清楚 清楚的需求让人易读易懂
25、。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：文档的结构、段落是否乱七八糟？上下文是否不连贯？文档的语句是否含糊其词、罗里罗嗦？看了半天是否还不明白需求究竟是什么？.3 无二义性“无二义性”是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性，人们在写产品需求规格说明书时措词应当准确，切勿模棱两可。,什么是好的需求规格说明书,.4 一致“一致”（Consistent）是指产品需求规格说明书中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文
26、档的上下文中。.5 必要 产品需求规格说明书中的各项需求对用户而言应当都是必要的。可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在产品需求规格说明书中将那些“锦上添花”的需求设置为较低的优先级。.6 完备“完备”（Complete）是指产品需求规格说明书中没有
27、遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。不完备的产品需求规格说明书将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。,.什么是好的需求规格说明书,7 可实现 产品需求规格说明书中的各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是产品需求规格说明书可是白纸黑字啊。经过双方确认的产品需求规格说明书相当于商业合同，如果开发方不能够实现产品需求规
28、格说明书中的内容，那就是违约，可能会被罚款的。对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。.8 可验证 产品需求规格说明书中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。,.什么是好的需求规格说明书,.9
29、确定优先级 为什么要确定需求的“优先级”？理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了。人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。10 阐述“做什么”而不是“怎么做”产品需求规格说明书的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么
30、做”是系统设计和实现阶段的事情。国内的很多软件公司里，开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。,良好的需求规格说明的例子-1,例子：“产品应在不少于每60秒的正常周期内提供状态信息”分析：这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也
31、可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。弥补缺陷，重写需求的一种方法：n后台任务管理器因以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息；n如果后台进程处理正常，那么应该显示任务已完成的百分数/比；n任务完成时，应显示相关的信息；n后台任务出错应该显示错误信息；为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。,良好的需求规格说明的例子-2,例子：“产品应瞬间在文本中的显示和隐藏不可打印字符间切换”计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没
32、有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些什么动作？而且，在文档中改变显示的范围是多大：选中的文本？整个的文档，或其他的？这也是个模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。像这样编写需求也许更好一些：用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。,良好的需求规格说明的例子-3,例子：“HTML分析器可以产
33、生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没有加进错误报告的定义也是不完整的。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。,需求跟踪,1.需求的标识需求类型可以是：F=功能需求，D=数据需求，B=行为需求，I=接口需
34、求；O=输出需求。,例：需求标识为F03的需求表示编号为3的功能需求。,需求跟踪,2.需求的属性创建需求的时间需求的版本号创建需求的作者负责认可该需求的人员需求状态需求的原因或根据（或信息的出处）需求涉及的子系统需求涉及的产品版本号,需求跟踪,3.需求状态 已建议该需求已被有权提出需求的人建议 已批准该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已有一个确定的产品版本号或编号，软件开发团队已同意实现该项需求 已实现使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。该需求现在被认为完成 已删除计划的需求已被删除，并包含一个原因说明
35、和作出删除决定的人员,4.3.2 需求状态的变化,在需求获取、分析、处理、验证阶段，我们已经得到了获得用户和项目组达成共识的需求，并且，已经建立了需求数据库，建立了需求基线。从需求实现阶段来看，需求在这个阶段，仍然受各种因素的影响，产生不可预料的变化。,需求实现过程需求状态变化,在需求状态的变化中，软件项目经理第一位需要关注的是那些被拒绝、被丢弃的需求。因为如果不是通过有管理的处理过程，这些需求有可能是应该被接受、并被实现的需求，而成为系统的疏忽而遗漏？项目经理也应该关注被交付的需求，因为作为项目经理，他的主要责任是项目阶段的里程碑控制。项目阶段里程碑是应交付成果，交付成果最主要的内容，就是需
36、求的实现。（其他的交付物还有：文档、培训、服务等）。,4.3.3 需求状态变化的追踪,如果我们能够做到软件需求的定义，那么，通过跟踪定义了的需求，我们就能够知道需求在实现过程中的具体实现细节与目标的距离。在可追踪的需求实现过程中，项目经理才能够有把握地说，需求被正确地实现了。,需求跟踪,正向跟踪：以用户需求为切入点，检查用户需求说明书或需求规格说明书中的每个需求是否都能在后继工作产品中找到对应点。逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明书中找到出处。正向跟踪和逆向跟踪合称为“双向跟踪”。,需求跟踪,正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建
37、立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后继工作成果的对应关系。,需求发生变更的起因主要有：随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。需求变更控制的目的：如果需求变更带来的好处大于坏处，那么允许
38、变更，但必须按照已定义的变更规程执行，以免变更失去控制。如果需求变更带来的坏处大于好处，那么拒绝变更。需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。解决这个问题最好的办法是事先建立“游戏规则”：开发方与客户方达成“事不过三”的约定（符合中国人的习惯），即允许客户变更三次需求；如果客户第四此变更需求，开发方有权拒绝，除非客户愿意补偿开发方的损失。如果事先没有“游戏规则”的话，开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。,需求变更控制,4.4.1 需求变更管理的重要性,需求变
39、更的原因多种多样，但管理变更，应确立以下原则：（1）认识到变更是不可避免的，为变更指定计划；（2）确定需求基线；（3）建立控制变更的唯一渠道（4）使用变更控制系统来控制变更过程；（5）分层次地管理变更。,4.4.2 需求变更控制活动,6大需求变更控制活动（1）确定需求变更控制过程：确定需求变更的选择、分析、决策、记录的过程，所有需求的变更，都要在选择、分析、决策、记录环节上，受到机制和责任的保证。（2）建立需求变更控制委员会：组织公司、项目组内部和用户利益和风险承担人员，成立需求变更控制委员会，由他们来决定要变更哪些需求，是否在项目范围之内（包括：项目范围和合同范围。因为有时，在项目范围，但不
40、在合同范围，需要项目进行二期合同开发），评估变更的波及，最后决定变更是可以接受，还是放弃。对变更的需求设置优先级、制定版本规定等。,需求变更 6大需求变更控制活动,（3）进行需求变更影响分析：波及分析有利于对需求变更要求，进行更深入、精确的理解，帮助变更控制委员会做出科学的决策。波及分析还可以帮助项目组对现有系统做出合理的、有前瞻性的调整，使面对日后新的需求变更，有充足的技术准备。波及分析完全依赖于需求的跟踪能力。没有需求形式化记录、没有需求跟踪链，就没有波及分析的可能。如果有，也是主观的、非定量的。由此对项目计划、成本、质量控制的影响分析，其可信度是有疑问的。系统分析师和架构师应评估变更对系
41、统技术实现的影响。项目经理应根据新需求，明确相关任务，评估新的工作量和相应的要求变化。新需求不但导致分析、编码、测试的工作量增加，项目管理有关的各环节（需求管理、计划管理、成本管理、配置管理、质量管理等）都会有所变化。在需求变更评估分析中，也要做需求稳定性评估。频繁地需求变更，应该超出了需求变化的范围。项目经理要考虑项目组织管理方面，是不是发生了什么问题。,需求变更 6大需求变更控制活动,（4）跟踪所有受需求变更影响的工作产品：当确定某一需求发生变更时，根据需求跟踪矩阵，找到与变更需求有关的各层、各环节需求项。例如：涉及需求项的设计模型、代码模块、测试用例等。这些部分全部必须做相应的修改。依据
42、需求跟踪矩阵，可以完整地追踪到需求变更所影响到的所有地方，可以不会发生遗漏，而产生系统BUG，或产品缺陷。甚至包括对软件产品本身以外的影响，如：因需求变更，版本控制没有相应的记录、产品使用手册没有做相应修改等。因为需求变更，需求状态记录应相应地发生变化。每一条记录，反映了需求的现实情况。（5）调整需求基线：需求变化以后，需求变更控制委员会要决定是否调整需求基线。新需求是反映为基线的调整，还是版本的变化。基线是产品的标准，基线变化可以作为产品标准的变化，也可以理解为将发行一个新版本的产品。,需求变更 6大需求变更控制活动,但是，版本并不一定就是新产品。因为，当产品面对不同地区、不同用户群的时候，
43、也可以确定不同的版本。因此，需求变更控制委员会要做的工作，是对新需求，决定是全面升版，还是局部更改。是基线变化，还是个别版本变化。有时，这是一个比较难于做出的决定，他依赖于对新需求的分析，评估它对市场、用户和产品本身的影响。（6）维护需求变更记录和文档：决定变更基线或提升版本以后，就要做好记录，修改相应的文档。变更记录要记录变更原因、变更内容、变更影响、变更实现过程、其他相应变更等。变更记录越完整，对于追溯，甚至以后可能发生的回退，就越有帮助。有一些版本控制工具，可以帮助项目经理来做到记录相应的信息。,4.4.3 需求变更波及分析,变更波及分析的意义 对于项目组来说，一个新的需求提出来以后，这
44、个需求如果接受，可能对系统造成多大的影响？系统结构上的、数据结构上的、涉及的模块、版本上的变更影响有多大？需求波动在技术上有潜伏性，在工程上，也表现为不可预知性。工作量不可预知、成本不可预知。项目经理往往受市场人员的压力，对用户宣称“免费维护”，但在项目组内部，对于需求变更的成本，甚至可能是“巨大”的。这种不理智的“反差”，正好说明了我们软件项目管理的水平，是处在原始和粗放的状态。需求波及分析是软件项目管理的需求管理比较重要的组成部分，在需求变更决策前，通过波及分析，可以达到精确理解需求、评估系统对需求变更要求的接纳程度、变更的代价、变更对系统总体架构、甚至产品发展的影响等。这样的分析，对需求
45、变更委员会做出变更批准还是放弃的决策，具有重要的意义。一旦变更控制委员会批准需求变更的要求，就能比较清晰地知道相应变更的内容、工作范围、需要的时间等。需求变更波及分析也是保证项目组在需求变更以后，可以做到“在计划、成本、质量（不是降低质量标准为代价）范围的变更”。,需求变更 变更波及的内部分析,系统元素波及分析包括：（1）所有涉及到的输入界面有关部分；（2）所有涉及到的报表等输出界面有关部分；（3）所有涉及到的外部接口部分；（4）所有涉及到的内部接口部分；（5）所有涉及到的数据库表结构；（6）所有涉及到的系统数据定义；（7）所有涉及到的公用模块定义、公用子程序库、控件库；（8）所有涉及到的系统
46、常量、宏定义；（9）所有涉及到的已经实现的代码；（10）所有涉及到的已经完成的单元、集成测试；（11）所有涉及到的已经编写完成的用户文档（使用手册、维护手册）；（12）所有涉及到的已经编写完成的帮助文件、培训教材；（13）所有涉及到的第三方软件和工具；（14）所有涉及到的项目管理有关的需求管理、计划管理、成本管理、配 置管理、质量管理有关的数据库、文档库；（15）所有涉及到的其他应该检查的部分；（16）所有涉及到的。,需求变更 变更波及的外部分析,（1）变更是否与基线（已经实现的部分）相冲突（是否是基线内的）；（2）变更是否存在与虽未实现，但已经决定的需求相冲突；（3）不采纳变更是否会有技术上
47、的风险，或者采纳变更会有什么技术上的风险；（4）不采纳变更是否会有业务上的风险，或者采纳变更会有什么业务上的风险；（5）不采纳变更是否会导致质量降低，或者采纳变更会有多大的质量提升；（6）变更在技术实现上是可行的吗？（7）采纳变更是否会导致用户进一步提出更多不合理的要求？（8）采纳变更对现有项目组在人力、技术、工具等方面，是否能够承受，增加资 源是否可能；（9）采纳变更的需求变更量的估计是多少？（以单元为单位、以时间为单位、以 成本为单位）（10）采纳变更后，虽然进行了合理安排，包括采用关键路径法，调整进度安 排，但最后仍然对进度的影响是多少？（11）采纳变更以后使多少实际已经开发完成的单元被
48、废弃，相关的工作量是多 少？（12）采纳变更以后使多少实际已经开发所用的单元时间被浪费，相关的比率是 多少？（13）变更对市场、销售、培训、维护的影响有多大？,需求变更 需求变更波及分析报告,标题：变更描述：分析人 日期：优先级评定：相关收益：相关代价：相关成本：相关风险：增加耗时：增加人力：对进度的影响：对成本的影响：对质量的影响：直接影响的其他部分：间接影响的其他部分：导致的计划变更：导致的成本变更：其他影响：假定前提：条件与约束：评审人意见：,4.4.4 需求稳定性评估,为了了解需求的稳定性情况，可以对需求的稳定性，进行评估。评估的基本过程是：（1）统计基线需求的数量：通过需求数据库，可
49、以按最底层的需求项为单位，统计需求的数量。因为任何上层需求的变化，最终要反映到最底层需求项的变化。比较差的设计，可能使简单的需求变化，带来巨大的系统元素的修改。（2）统计每月/每周基线需求项的增加、删除、修改的数量。如同需求基线一样，根据项目的大小和历史经验，项目经理也要定一个稳定性基线，当需求变化量在一定时间内超过了稳定性基线，项目经理就要分析原因，采取措施。（3）需求变化既可能来自组织外部，也可能来自项目组内部。对需求不稳定的因素和来源进行分析，做出的评估，是获得需求稳定的好办法。这一点，将在以后配置管理和质量管理中，再做详细讨论。对需求稳定性的关注，是软件项目经理经常需要做的工作。需求不稳定，是项目组的“危险警报”。轻则是项目组工作量的增大，重则可能导致项目的严重延误，甚至失败。,需求变更控制流程,需求的变更是不可避免的，因此如何有效控制需求的变化对于项目成功至关重要。,需求变更控制策略,（1）项目启动阶段的变更预防（2）项目实施阶段的需求变更（3）项目收尾阶段的总结,作业,第4章 2、4,Q&A,
