软件需求分析重点-

软件需求分析重点

第1 章软件需求基础知识

返工的成本占了总开发成本的30%-50%，而对于返工的情况，70%-80%是国需求错误引起的。（11）

在对所有讨论问题有了更深入的了解之前不要急于回答。不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。（13-14）造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确以及地需求的分析不透彻等。给出估算结果时，应该提供范围（最好的情况，最可能的情况和最糟的情况）或把握程度（“我有九成把握在三个月内完成”）。（14）

从产品的实际用户处收集需求这一过程是不可替代的。（18）

第2 章客户眼中的需求

某些需求问题源于混淆了不同层次的需求（业务需求、用户需求和功能需求）。（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 章设定需求优先级

每一个受资源限制的软件项目都必须对需求的产品功能定义相对优先级。设