软件过程的需求管理PPT.ppt

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