软件需求工程讲座

1李号彩7月13日Saturday软件需求工程(SRE)

SoftwareRequirementsEngineering——根除软件百病之源软件需求工程讲座第1页关于我基本情况科研情况联系方式2李号彩：大唐华银电力股份有限企业评标教授，湖南大唐先一科技有限企业部门经理；1998年于东北大学计算机专业本科毕业；年于湖南大学软件工程专业硕士毕业；7月取得美国项目管理协会（PMI）颁发专业项目管理师（PMP证书）。电话手机：187-7311-9786；QQ：57335975；Email：lihc@。从事软件咨询、研发、管理，主持研发了20多项大型应用软件，包括发电、电网、移动、联通、电信、钢铁、水利、化工、造纸、汽车、政府、教育、安全等多个业务领域；取得2项实用新型专利，1项创造专利，1项湖南省科技进步奖，中国电力联合会全国电力信息化结果1项一等奖及1项三等奖，1项中国电机工程协会电力建设专委会优异论文二等奖；参加编写了《IT项目管理——从理论到实践》大学教材；在《电力信息化》、《项目管理技术》及《湖南制造业》等国内关键期刊发表了10多篇技术论文。软件需求工程讲座第2页3软件需求工程讲座第3页此次讲座想要解决什么问题？此次讲座将满足什么需求？将怎样提升大家工作方法？经过此次讲座将最终获得哪些收获？以需求分析原理为基础、以实践经验和体会为案例、经过学习需求工程方法、技术和工具，了解和掌握需求过程。0.序言4我们为何要学习软件需求工程？满足社会对软件系统需求、满足软件工程对需求工程需求、满足大家掌握软件需求开发与需求管理本事需求。掌握表述、发现、理解、分析、管理、评估软件需求方法、技术和伎俩，能成功应用到工作中，以此提高软件研发质量，软件研发效率，提升自身能力与综合素质。提升对需求认识，尤其是对软件需求认识。了解软件需求必要性和主要性！软件需求工程讲座第4页议程1软件需求概述2软件需求开发3软件需求管理4结语5软件需求工程讲座第5页1.软件需求概述1.1软件概述软件是计算机系统中与硬件相互依存的另一部分，软件是先进思想与理念的载体，软件是先进技术与方法的体现，优秀的软件是科技、管理和政治的完美结合体；软件=程序+数据+其相关文档；程序是按事先设计的功能和性能要求执行的指令序列数据是使程序能正常操纵信息的数据结构文档是与程序开发，维护和使用有关的图文材料1.2软件工程概述工程：“工程”是科学的某种应用，通过这一应用，使自然界的物质和能源的特性能够通过各种结构、机器、产品、系统和过程，是以时间最短的和精而少的人力做出高效、可靠且对人类有用的东西。软件工程定义：软件工程是开发、运行、维护和修复软件的系统方法；软件工程是一类求解软件的工程；是一门指导软件生产与维护的工程学科。软件工程三要素：方法、工具和过程。软件工程方法为软件开发提供了“如何做”的技术；软件工具为软件工程方法提供了自动的或半自动的软件支撑环境；软件工程过程定义了:方法使用的顺序;要求交付的文档资料;为保证质量和适应变化所需要的管理;软件开发各个阶段完成的里程碑。软件工程基本目标：付出较低的开发成本；达到要求的软件功能；取得较好的软件性能；开发的软件易于移植；需要较低的维护费用；能按时完成开发工作，及时交付使用。软件项目成功的三要素：用户参与，主管层支持，需求的清晰表述。软件人成功的三要素：需求的把握与控制能力，良好的沟通能力，责任心与承担责任的能力。6软件需求工程讲座第6页1.软件需求概述1.3软件需求概述需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人，必须经过分析，确认才是软件需求。1.4软件需求的重要性（正反案例）开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。国内软件业的痼疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。7当局者迷，旁观者清。软件需求工程讲座第7页8第3层功效需求层第1层业务需求层业务需求远景与范围文档第2层用户需求层用户需求用例文档质量属性业务需求功效需求系统需求外部界面约束条件软件需求规范和模型功效性需求非功效性需求1.软件需求概述软件需求层次软件需求工程讲座第8页1.软件需求概述1.5

软件需求工程概述把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构图9软件需求工程讲座第9页1.软件需求概述1.6需求开发过程域需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生《用户需求说明书》。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品需求规格说明书》开展系统设计工作。1.7需求管理过程域需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱，让需求变更有序，可控。10软件需求工程讲座第10页议程1软件需求概述2软件需求开发3软件需求管理4结语11软件需求工程讲座第11页2.软件需求开发—面临困难2.1.1知识技能问题应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可逃避。当需求分析员缺乏应用域知识时，他该怎么办？首先他要有勇气做事，否则连实践的机会都没有；其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。2.1.2态度问题相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。12软件需求工程讲座第12页2.软件需求开发—面临困难2.1.3合作关系如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：我回答了你们的问题，讲了该讲的；我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了；你们自己想办法把活干好吧

。对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力。开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦；如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。13软件需求工程讲座第13页2.软件需求开发—面临困难用户在需求工程中的“权利”1.有权要求开发方派遣资质合格的需求分析员和相关人员。2.有权要求开发方采用用户熟悉的语言来描述需求，即开发方必须提供用户看得懂得需求文档。3.有权审查需求文档，并对有争议的需求作出决策。如果认为需求文档不能准确地反映用户真实的意愿，可以拒绝在需求文档上签字。4.如果用户想要变更需求，有权要求开发方对该变更将产生的影响作出真实可信的评估，以便用户决定是否变更需求。用户在需求工程中的“义务”1.以积极友善的态度与开发方人员交流、协作，尽可能地为开发方人员提供工作和生活上的便利。2.乐意接受需求分析员的采访，在不泄漏机密的前提下尽可能地回答需求分析员的问题。3.在不泄漏机密的前提下，尽可能地向需求分析员提供与需求相关的材料。4.与需求分析员共同评审需求文档，确保需求文档准确地反映用户真实的意愿。14软件需求工程讲座第14页2.软件需求开发—面临困难2.1.4用户说不清楚需求用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求；例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”；例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧。有些用户虽然心里明白想要什么，但却说不清楚需求：比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状；通常拿鞋子去试，试穿时感觉到舒服才会买鞋。需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。15软件需求工程讲座第15页2.软件需求开发—面临困难2.1.5双方误解需求人们在交流的时候，经常会发生“问非所求，答非所问”的事情。有时用户会把开发人员的建议或答复给想歪了：有一个软件开发人员滔滔不绝地向用户讲解在“信息高速公路上做广告”的种种好处，用户听得津津有味。最后，心动的用户对软件开发人员说：“好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。”而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连高智商的外星人都不能避免：有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：“主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。”不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。16软件需求工程讲座第16页2.软件需求开发—面临困难2.1.6开发人员写不好需求文档需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档：古时候，一书生在考试前补习“写文章”，成天愁眉苦脸；所以要想写出好的需求文档，前提条件是把需求调查工作做好。开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来：可以毫不夸张地说，国内90％以上的软件开发人员，他们的写作能力远不及开发能力；提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧；另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。软件人的若干层次：PPT—DOC—PRG—TST—EXE17软件需求工程讲座第17页2.软件需求开发—面临困难2.1.7用户经常变更需求需求变更通常会对项目进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。18软件需求工程讲座第18页2.软件需求开发—需求调查2.2.1准备调查首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。问题表可以有多份，随着调查的深入，问题表将不断地被细化。根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从《用户需求说明书》模板中提取需求问题。其次，需求分析员应当确定需求调查方式，例如：与用户交谈，向用户提问题。向用户群体发调查问卷。参观用户的工作流程，观察用户的操作。与同行、专家交谈，听取他们的意见。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。从Internet上搜查相关资料。最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。19软件需求工程讲座第19页2.软件需求开发—需求调查2.2.2执行调查准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息。需求分析员与用户面谈时应当注意以下事项：如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好感，并为下次打扰他们埋下伏笔。需求分析员应事先了解用户的身份、背景，以便随机应变。IT人士不可貌相，有些大企业的领导其外表很土气，象农民。如果你路上碰到他，以为是个勤杂工，说：“喂，老师傅，来帮我拎东西。”也许这笔生意就泡汤了。需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问题。如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当双方对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。避免片面地听取某些用户的需求而忽视其它用户的需求。20软件需求工程讲座第20页2.软件需求开发—需求调查2.2.3《用户需求说明书》与《产品需求规格说明书》的主要区别与联系前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。21软件需求工程讲座第21页2.软件需求开发—需求分析2.3.1基本概念为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永远是正确的。谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。“问答分析法”比较适合于用户需求调查阶段“建模分析法”比较适合于产品需求定义阶段。22软件需求工程讲座第22页2.软件需求开发—需求分析2.3.2问答分析方法问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。问答分析最重要的问题是：“是什么”和“为什么”。每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。其它常见的问题有：需求存在二义性吗？需求文档的上下文有矛盾吗？需求完备吗？需求是必要的吗？需求可实现吗？需求可验证吗？需求的优先级确定了吗？23软件需求工程讲座第23页2.软件需求开发—需求分析2.3.3建模分析法人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人一目了然，所谓“一图低千言”就是这个道理。在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。恰当地使用图形符号：现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱；世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。24软件需求工程讲座第24页2.软件需求开发—需求分析252.3.4作出决策当需求从四面八方收集来后，需求冲突在所难免。对于那些难以达成共识的需求而言，经常会发生“公说公有理，婆说婆有理”的现象。那么需求分析员究竟应该听谁的呢？如果一群人对需求有争议，并不是谁声音最响就听谁的。根据生活经验，最保险的办法是：先听官儿大的或者威望高的，如果大家的职位和威望都差不多，那么采用“少数服从大多数”的原则。如果一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的喜好来开发。此时对需求的决策应当以商业利益为导向，即哪一类客户出钱最多就先满足他们的需求，以后再做那些获利相对较少的需求。当开发者想象中的产品与客户所提的需求有冲突时，一般应当尊重客户的观点。但是不要陷入“客户总是对的”陷阱里，需求分析员应当纠正明显不合理的客户需求。如果产品很复杂，双方都不太明白需求，此时最好请开发人员快速构造软件原型，双方看着软件原型再分析需求。软件需求工程讲座第25页2.软件需求开发—需求规格说明书2.4.1正确需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。2.4.2清楚清楚的需求让人易读易懂，不在于文档的厚度。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：文档的结构、段落是否乱七八糟？上下文是否不连贯？文档的语句是否含糊其词、罗里罗嗦？每句话都是对的，但是看了半天是否还不明白需求究竟是什么？2.4.3无二义性“无二义性”是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。为了使需求无二义性，人们在写《产品需求规格说明书》时措词应当准确，切勿模棱两可。26软件需求工程讲座第26页2.软件需求开发—需求规格说明书2.4.4一致“一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。2.4.5必要《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是“画蛇添足”要么是“锦上添花”。“画蛇添足”显然是坏事，会导致开发人员多干一些吃力不讨好的工作。所以要尽量剔除需求规格说明书中“画蛇添足”的那些需求。“锦上添花”是好事，也叫镀金，可能会让用户获得比期望更多的喜悦，但是眼前用户不会为此多付钱。开发者应当集中精力先完成必要的需求，如果条件允许则再做“锦上添花”的需求。为了避免主次颠倒，应当在《产品需求规格说明书》中将那些“锦上添花”的需求设置为较低的优先级。2.4.6完备“完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。不完备的《产品需求规格说明书》将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。27软件需求工程讲座第27页2.软件需求开发—需求规格说明书2.4.7可实现《产品需求规格说明书》的各项需求对开发方而言应当都是可实现的（Attainable）。“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。营销人员和用户谈生意时，为了能拿到“单子”，他们往往对用户提出的需求“来者不拒”。吹牛皮虽然不犯法，但是《产品需求规格说明书》可是白纸黑字啊。经过双方确认的《产品需求规格说明书》相当于商业合同，如果开发方不能够实现《产品需求规格说明书》中的内容，那就是违约，可能会被罚款的。对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户协商，达成一致的处理意见，避免将来发生商业纠纷。2.4.8可验证《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。例如，摩天大楼的一项需求是“抗十二级台风”，这个需求看起来堂而皇之，但是如何验证呢？当摩天大楼完工后验收时，用户又不是巫师，他怎能造个十二级台风来试验？如果双方都认可“采用计算机模拟十二级台风”等效于实际测试，那么这项需求就是“可验证”的。28软件需求工程讲座第28页2.软件需求开发—需求规格说明书2.4.9确定优先级为什么要确定需求的“优先级”？理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。在项目刚开始的时候，开发方和客户比较乐观，什么都要做，可是做着做着，人们常常会面临“进度延误、费用超支、人员不足”等问题，这时就乱套了；人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。2.4.10阐述“做什么”而不是“怎么做”《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。国内的很多软件公司里，包括我们公司的开发人员常常身兼数职，可能把需求开发、系统设计、编程等工作从头做到尾。所以他们在调查、分析、定义需求时，自然会想到“怎么做”，这并没有什么过错。如果在调查、定义需求时想好了“怎么做”，当然应该写下来，否则岂不浪费！关键是不要将“怎么做”写到需求规格说明书里面，记录在其它文档里就行了。29软件需求工程讲座第29页2.软件需求开发—定义产品需求2.5规程第一步：细化并分析用户需求：需求分析员首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational的Rose工具进行需求的建模分析，建模分析产生的文档可以作为《产品需求规格说明书》的附件。第二步：撰写产品需求规格说明书：需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。第三步：进行需求确认：项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿；需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺（即签字确认）。30软件需求工程讲座第30页议程1软件需求概述2软件需求开发3软件需求管理4结语31软件需求工程讲座第31页3.软件需求管理3.1需求确认（评审和承诺）需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评审，双方对需求达成共识后作出承诺，形成了需求基线。需求确认包含两个重要工作：“需求评审”和“需求承诺”。3.2需求评审面临的困难需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易。需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了。人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。

32软件需求工程讲座第32页3.软件需求管理3.3需求承诺需求承诺是指开发方和客户方的责任人对通过了正式技术评