软件需求分析重点
第1 章 软件需求基础知识
返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是
国需求错误引起的。（11）
在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需
求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）
造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用
户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14）
第2 章 客户眼中的需求
某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需从产品的实际用户处收集需求这一过程是不可替代的。（18）
求）。（19）
要想开发出优秀的软件产品，必须以优质需求为基础精心制定计划。（20） 不要指望项目涉众天生知道如何合作进行需求开发。必须花时间讨论如何最
有效地进行协作。（22）
需求审阅是最有价值的保证软件质量的活动之一。（25）
需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问
题。（25）
不可能在项目初期就能明确所有的需求，需求肯定要随时间的推移而发生变
化。（26）
第3 章 需求工程的推荐方法
熟练的需求分析员应具备以下特点：耐心，思维条理性强，有良好的交际和
沟通能力，理解产品应用领域，并且掌握丰富的需求工作技术。（29）
为每类用户选择代言人（31）
观察用户工作的过程（31） 跨项目重用需求（32）
过早地以尚不明确的需求为基础进行开销和进度评估是非常不可靠的。（37） 38图表
不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需
求开发活动。（38）
第4 章 需求分析员
相比缺乏经验的需求分析员，使用经验丰富的需求分析员能使项目所需求的
工作量减少三分之一。（42）
优秀的需求分析员应同时具备出色的交流、引导和人际交待能力，具备技术
和业务领域的丰富知识，以及适合这项工作的相应个性。耐心和真诚的合作愿望是关键的成功因素。（44）
需求分析员必须研究可能出错的情形。（44）
第5 章 确定产品前景与项目范围
第6 章 获取客户的需求
能否让开发人员更准确地了解用户需求，将决定软件需求工作能否取得成功，进而影响到软件开发的成功。（62）
项目伊始就应确定谁来担任问题的决策人。（72）
第7 章 聆听客户的需求
需求开发工作的成果就是项目涉众之间就被处理的需求达成共识。（75） 需求获取的参与者在理解问题之前要抵制住诱惑，不要急于设计系统。 要强调用户任务，而不是用户界面，要强调根本需要，而不是用户表达出来的期望，这样有助于项目团队避免过早是制定设计的细节。
在软件开发中，需求获取也许是最困难、最关键、最容易出错和最需要沟通的一个环节。（76）
作为一名分析员，对于客户所提出的需求，必须深究隐藏在其表面背后的真正意思。（76）
有创造性的分析员在需求获取期间还能为用户提出一些建议和可供选择的方案。（77）
每一次面谈之后，都要将小组所讨论的需求条目编写成文档，并请参与面谈的人员对所有条目进行评审，以确保其正确性。
需求分析员必须将所听到的大量需求信息分门别类，以引以为方便编档和使用。（79）
很多被用户作为需求提出来的意见都属于解决思路，而非真正的需求。需求分析员应该透过解决思路的表面去探寻用户真正的需求。（82）
用多种方法表达需求信息。（84）
第8 章 理解用户需求
凡是写过计算机程序的人都知道异常处理常常占去了他们大部分的编码精力，最终产品中的很多缺陷都归结于异常处理程序（或缺少异常处理程序）。开发健壮的软件产品的方法之一就是在需求获取过程中定义异常条件。（91）
不要等到需求获取工作完全结束后才去征求用户、开发人员及其他涉众的反馈意见。
第9 章 遵守规则
需求分析员应该把在需求获取讨论中提出的业务规则记录成文档，然后打到合适的人证实它们的正确性并补充遗漏的信息。
第10 章 编写需求文档
即使是最详细的需求规格说明也决不能取代贯穿整个项目的项目人员间的
讨论。（112）
开发人员和客户不能作任何假设。如果所期望的功能或质量没有写入达成共
识的需求中，那么就不应该指望产品中会具有这些功能或满足这些质量要求。（113）
第11 章 一图胜千言
项目团队很少需要创建整个系统的完整的分析模型集。建模时只需关注系统
最复杂和风险最大的部分，以及最容易产生歧义和不确定性的部分。（133）
第12 章 软件质量属性
第13 章 通过制作原型减少项目风险
通过制作软件原型，可以使需求更加真实，使用例更加生动，并且可以减小
在需求理解上的差异。（162）
建立原型的主要原因是为了解决在产品开发的早期阶段不能确定的一些问
题。（163）
水平原型（演示性模型） 垂直原型 废弃型原型 演化型原型
不允许将废弃型原型中质量低的代码移植到生产系统中，否则，用户和维护人员将在产品生命周期中遭遇种种麻烦。（164）
不要过于详细地构建废弃型原型，只要能够满足原形制作的目标就够了。要
抵制住诱惑，或顶住用户的压力，不要向原型添加更多的功能。（165）
演化型原型必须设计得易于进行扩展和频繁改进。
当用户在评估原型时，让用户尽量把自己的想法大胆地说出来。（169） 把原型评估中获得的信息编写成文档。 170
第14 章 设定需求优先级
每一个受资源限制的软件项目都必须对需求的产品功能定义相对优先级。设
定优先级有助于项目经理解决冲突、安排阶段性交付、并且做出必要的取舍。（172）
一种评估优先级的方法是从重要性和紧迫性两个方面进行考虑。（174）
第15 章 需求确认
修正客户发现的需求缺陷所需的工作量，大约是更正需求开发期间发现的错
误所需的工作量的100倍。（181）
检测到需求规格说明中的错误所采取的任何措施，都可以节省相当可观的时
间和费用。
优秀需求陈述的特征（完整，正确，可行，必要，具有优先级，无二义性和
可验证）（182）
对需求文档的审查是现有技术中最有效的软件质量技术。
在审查需求文档上花费一个小时，可节省多达10小时的工作时间。（184）
如果审查参与者自己还没有对工作产品进行检查，那么就先不要召开审查会
议。无效的会议可能得出审查纯粹是浪费时间这样错误的结论。（187）
第16 章 需求开发面临的特殊难题
如果不将需求具体记录下来，而只是通过心灵感应，就不要期望项目一定能
取得成功。（206）
项目团队成员和相应的客户之间要时常进行交流，这是解决许多需求问题效
率最高的一种方法。编写的需求文档无论有多么详细，也法取代这些随时的交流。
尽早地而且是经常地设定优先级（207）
第17 章 超越需求开发
有经验的项目经理和开发人员都知道把软件需求转化为健壮的设计和合理
的项目规划的重要性。（207）
对于小型项目而言，团队在需求工程上所花费的工作量占整个项目所有工作
量的12％-15％。
最成功的项目在需求工程中所耗费的资源占到项目总资源的28％，其中需求
软件需求分析重点_
