1、软件项目管理软件项目管理需求开发与需求管理需求开发与需求管理Page 2目录目录1. 什么是需求什么是需求 2. 了解客户、最终用户、间接用户了解客户、最终用户、间接用户3. 需求工程基本概念需求工程基本概念4. 需求开发的主要困难与对策需求开发的主要困难与对策5. 如何开展需求调查如何开展需求调查6. 如何进行需求分析如何进行需求分析7. 什么是好的需求规格说明书什么是好的需求规格说明书8. 如何定义产品需求如何定义产品需求9. 需求管理：确认、跟踪、变更控制需求管理：确认、跟踪、变更控制Page 31. 什么是需求什么是需求1.1 需求的基本概念需求的基本概念 u宽泛地讲，需求来源于用户的
2、一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 u所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。1.2 需求的重要性需求的重要性uFrederick Brooks在他1987年经典文章“No Silver Bullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。u需求是产品的根源，需求工作的优劣对产品影响最大。u国内软件业的痼
3、疾：人们并不清楚究竟该做什么，但却一直忙碌不停地开发。 Page 42. 了解客户、最终用户、间接用户了解客户、最终用户、间接用户2.1 基本概念基本概念u“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。u掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。2.2 客户是掏钱买软件的人，所以他是客户是掏钱买软件的人，所以他是“上帝上帝” u某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位： 如果顾客先点鸡，那么就先有鸡；
4、如果顾客先点蛋，那么就先有蛋。u“现代营销学之父”菲利普科特勒所著的市场营销导论是这样描述客户的：客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。u与客户打交道的主要目的是：一是获取需求，二是签合同。Page 52. 了解客户、最终用户、间接用户了解客户、最终用户、间接用户2.3 重视重视“间接用户间接用户”，
5、千万别，千万别“大意失荆州大意失荆州” u间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。u例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。u同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。 Page 63. 需求工程基本概念需求工程基本概念3.1 什么是需求工程什么是需求工程u把所有与需求直接相关的活动通称为需求工程。u需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。 u需求工程的结构图 Page 73. 需求工程基本概念需求
6、工程基本概念3.2 需求开发过程域需求开发过程域 u需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 u需求调查的目的是通过各种途径获取用户的需求信息（原始材料），产生用户需求说明书。 u需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 u需求定义的目的是根据需求调查和需求分析的结果，进一步定义准确无误的产品需求，产生产品需求规格说明书。系统设计人员将依据产品需求规格说明书开展系统设计工作。 3.3 需求管理过程域需求管理过程域 u需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一
7、致性，并控制需求的变更。 u需求确认是指开发方和客户共同对需求文档进行评审，双方对需求达成共识后作出书面承诺，使需求文档具有商业合同效果。 u需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 u需求变更控制是指依据“变更申请审批更改重新确认”的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。 Page 83. 需求工程基本概念需求工程基本概念3.4 需求工程的一些感悟需求工程的一些感悟 u不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。 u开发者对待需求工程的态度可分“被动型”、“主动型”和“领
8、先型”三种，只有后两种才有可能开发出成功的产品。 “被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。 “主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。 “领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产
9、品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。 Page 94. 需求开发的主要困难与对策需求开发的主要困难与对策4.1 知识技能问题知识技能问题 u应用域的知识是无边无际的，任何人都不可能是“万事通”。u当需求分析员缺乏应用域知识时，他该怎么办？ 首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习应用域知识。 4.2 态度问题态度问题 u相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。很多开发人员错误地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发
10、什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。 u用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。 u软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。 Page 104. 需求开发的主要困难与对策需求开发的主要困难与对策4.3 合作关系合作关系 u如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程
11、中会很疲惫。 4.4 用户说不清楚需求用户说不清楚需求 u用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。 u有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。 u有些用户虽然心里明白想要什么，但却说不清楚需求。 u需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。u无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。 Page 114. 需求开发的主要困难与对策需求开发的主要困难与对策4.5 双方误解需求双方误解需求 u人们在交流的时候，经常会发生“问非所
12、求，答非所问”的事情。 u有时用户会把开发人员的建议或答复给想歪了。u而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。 u不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。 Page 124. 需求开发的主要困难与对策需求开发的主要困难与对策4.6 开发人员写不好需求文档开发人员写不好需求文档 u需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。 古时候，一书生在考试前补习“写文章”，成天愁眉苦脸。其夫人甚为不解，问：“相公，你写文章比我生小孩还
13、难吗？”书生长叹一声：“娘子你哪里知道我的难处啊！你生小孩时肚子里有东西，可我写文章时肚子里没东西啊。” 所以要想写出好的需求文档，前提条件是把需求调查工作做好。 u开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出好的需求文档来。 提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧。 另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。 Page 134. 需求开发的主要困难与对策需求开发的主要困难与对策4.7 用户经常变更需求用户经常变更需求 u需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。u如
14、果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。u如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。 u其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动。 Pa
15、ge 145. 如何开展需求调查如何开展需求调查 5.1 准备调查准备调查 u首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则调查工作将变得漫无边际。 问题表可以有多份，随着调查的深入，问题表将不断地被细化。 根据经验，用户通常没有耐心回答复杂的论述题，所以问题表应当以“选择题”和“是非题”为主。 制定问题表最简便的方法就是从用户需求说明书的模板中提取需求问题。 u其次，需求分析员应当确定需求调查的方式，例如： 与用户交谈，向用户提问题。向用户群体发调查问卷。 参观用户的工作流程，观察用户的操作。 与同行、专家交谈，听取他们的意见。 分析已经存在的同类软件产品，提取需求
16、。 从行业标准、规则中提取需求。 从Internet上搜查相关资料。 u最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需求调查计划。要特别留意的是不要漏掉典型的用户。 Page 155. 如何开展需求调查如何开展需求调查 5.2 执行调查执行调查 u准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息 。u需求分析员与用户面谈时应当注意以下事项： 如果与用户约好了时间，切勿迟到或早退。 需求分析员应事先了解用户的身份、背景，以便随机应变。 需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细节问题。 如果双方气氛融洽，可以采
17、用灵活的访谈形式，轻易不要打断用户的谈话。 尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。 避免片面地听取某些用户的需求而忽视其它用户的需求。 Page 165. 如何开展需求调查如何开展需求调查 5.3 用户需求说明书与产品需求规格说明书的主要区别与联系用户需求说明书与产品需求规格说明书的主要区别与联系u前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。u后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软件系统设计的直接依据。 u两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状
18、况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据产品需求规格说明书来开发当前产品。 5.4 撰写撰写用户需求说明书用户需求说明书Page 17用户需求说明书的参考模板用户需求说明书的参考模板Page 186. 如何进行需求分析如何进行需求分析6.1 基本概念基本概念 u需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。 u分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保
19、你一学就会），很有实用价值。 u“问答分析法”比较适合于用户需求调查阶段u“建模分析法”比较适合于产品需求定义阶段。 Page 196. 如何进行需求分析如何进行需求分析6.2 问答分析方法问答分析方法 u问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。 u问答分析最重要的问题是：“是什么”和“为什么”。 每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。 如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。 追究“
20、是什么”和“为什么”的目的是获得正确、清楚的需求。 u其它常见的问题有： 需求存在二义性吗？ 需求文档的上下文有矛盾吗？ 需求完备吗？ 需求是必要的吗？ 需求可实现吗？ 需求可验证吗？ 需求的优先级确定了吗？ Page 206. 如何进行需求分析如何进行需求分析6.3 建模分析法建模分析法 u在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。u需求建模就是指用图形符号来表示、刻画需求。u建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。 6.4 作出决策作出决策 Page 217. 什么是好的需求规格说明书什么是
21、好的需求规格说明书7.1 正确正确 u需求规格说明书应当正确地反映用户的真实意图，“正确”是产品需求规格说明书最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对需求规格说明书进行确认。7.2 清楚清楚 u清楚的需求让人易读易懂。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚： 文档的结构、段落是否乱七八糟？上下文是否不连贯？ 文档的语句是否含糊其词、罗里罗嗦？ 看了半天是否还不明白需求究竟是什么？ 7.3 无二义性无二义
22、性 u“无二义性” 是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。u为了使需求无二义性，人们在写产品需求规格说明书时措词应当准确，切勿模棱两可。 Page 227. 什么是好的需求规格说明书什么是好的需求规格说明书7.4 一致一致 u“一致”（Consistent）是指产品需求规格说明书中各个需求之间不会发生矛盾。矛盾常常潜伏在需求文档的上下文中。 7.5 必要必要 u产品需求规格说明书中的各项需求对用户而言应当都是必要的。u可以把“必要”比喻为“雪中送炭”。“必要”往前一步，要么是
23、“画蛇添足”要么是“锦上添花”。7.6 完备完备 u“完备”（Complete）是指产品需求规格说明书中没有遗漏一些必要的需求。u人们往往倾向于关注系统的特色功能，而忽视了其它一些不起眼的但却是必需的功能。 u不完备的产品需求规格说明书将导致产生功能不完整的软件，用户在使用该软件时可能无法完成预期的任务。 Page 237. 什么是好的需求规格说明书什么是好的需求规格说明书7.7 可实现可实现 u产品需求规格说明书中的各项需求对开发方开发方而言应当都是可实现。u“可实现”意味着在技术上是可行的，并且满足时间、费用、质量等约束。u对于合同项目，如果开发方不能确信某些需求是否可实现，则应事先与用户
24、协商，达成一致的处理意见，避免将来发生商业纠纷。 7.8 可验证可验证 u产品需求规格说明书中的各项需求对用户方用户方而言应当都是可验证的（Verifiable）。 Page 247. 什么是好的需求规格说明书什么是好的需求规格说明书7.9 确定优先级确定优先级 u为什么要确定需求的“优先级”？ 理论上讲，软件的所有需求都应当被实现。但是在现实之中，项目存在“进度、费用、人力资源”等限制。 人们想出了“取舍”办法：先做优先级高的需求，后做（甚至放弃）优先级低的需求，这样可以将风险降到最低。 u需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共
25、同确定需求的优先级。 7.10 阐述阐述“做什么做什么”而不是而不是“怎么做怎么做” ” u产品需求规格说明书的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实现阶段的事情。 Page 258. 如何定义产品需求如何定义产品需求8.1 规程规程 u第一步：细化并分析用户需求第一步：细化并分析用户需求 需求分析员首先对用户需求说明书进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析，建模分析产生的文档可以作为产品需求规格说明书的附件。补充说明：建模分析的技术难度比较高，需求分析员应当根据自身
26、水平进行取舍。 u第二步：撰写产品需求规格说明书第二步：撰写产品需求规格说明书 需求分析员按照指定的文档模板撰写产品需求规格说明书。如果待开发的产品分为软件和硬件两部分的话，则应当撰写软件需求规格说明书和硬件需求规格说明书。u第三步：进行需求确认第三步：进行需求确认 项目经理邀请同行专家和用户（包括客户和最终用户）一起评审产品需求规格说明书，尽最大努力使产品需求规格说明书能够正确无误地反映用户的真实意愿。 需求评审之后，开发方和客户方的责任人对产品需求规格说明书作书面承诺。 8.2 软件需求规格说明书的参考模板软件需求规格说明书的参考模板 Page 26软件需求说明书的参考模板软件需求说明书的
27、参考模板Page 279. 需求管理：确认、跟踪、变更控制需求管理：确认、跟踪、变更控制9.1 需求需求确认（评审和承诺）确认（评审和承诺） u需求确认是指开发方和客户方共同对产品需求规格说明书进行评审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作：“需求评审”和“需求承诺”。 9.2 需求评审面临的困难需求评审面临的困难u需求评审的一个通病是“虎头蛇尾”。 u需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。 u开评审会议时经常会“跑题”，导致评审效率很低u开评审会议时经常会发生争议。适当的争议有利于澄清问题，比
28、什么东西都一致赞成要好。然而当争议变为争吵时就坏事了。u人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。 Page 289. 需求管理：确认、跟踪、变更控制需求管理：确认、跟踪、变更控制9.3 需求需求承诺承诺 u需求承诺是指开发方和客户方的责任人对通过了正式技术评审的产品需求规格说明书作出承诺，该承诺具有商业合同的效果。 u需求承诺格式如下： 本产品需求规格说明书建立在双方对需求的共同理解基础之上，我同意后续的开发工作根据该产品需求规格说明书开展。如果需求发生变化，我们将按照“变更控制规程”执行。我明白需求的变更将导致双方重新协商成本、资源和进
29、度等。甲方签字 乙方签字u人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。 Page 299. 需求管理：确认、跟踪、变更控制需求管理：确认、跟踪、变更控制9.4 需求需求跟踪跟踪u需求跟踪的目的是建立与维护“需求设计编程测试”之间的一致性，确保所有的工作成果符合用户需求。 u需求跟踪有两种方式： 正向跟踪。检查产品需求规格说明书中的每个需求是否都能在后继工作成果中找到对应点。 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在产品需求规格说明书中找到出处。 u正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵
30、保存了需求与后继工作成果的对应关系。 Page 309. 需求管理：确认、跟踪、变更控制需求管理：确认、跟踪、变更控制9.5 需求变更控制需求变更控制 u需求发生变更的起因主要有： 随着项目的进展，人们（包括开发方和客户方）对需求的了解越来越深入。原先的需求文档可能存在这样那样的错误或不足，因此要变更需求。 市场发生了变化，原先的需求文档可能跟不上当前的市场需求，因此要变更需求。 u提出需求变更的动机是好的，目的是希望产品更加符合用户的需求。对项目开发小组而言，变更需求意味着要调整资源、重新分配任务、修改前期工作成果等，开发小组要为此付出较重的代价。如果每次需求变更请求都被采纳的话，这个项目也许永远不能按时完成。 u需求变更控制的目的： 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。 u需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。u开发方需要一些社交技巧来减缓矛盾。例如建议在开发该产品新版本时修改需求。Page 31需求变更处理流程需求变更处理流程
