软件需求分析重点-

软件需求分析重点第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 章设定需求优先级每一个受资源限制的软件项目都必须对需求的产品功能定义相对优先级。

设定优先级有助于项目经理解决冲突、安排阶段性交付、并且做出必要的取舍。

（172）一种评估优先级的方法是从重要性和紧迫性两个方面进行考虑。

（174）第15 章需求确认修正客户发现的需求缺陷所需的工作量，大约是更正需求开发期间发现的错误所需的工作量的100倍。

（181）检测到需求规格说明中的错误所采取的任何措施，都可以节省相当可观的时间和费用。

优秀需求陈述的特征（完整，正确，可行，必要，具有优先级，无二义性和可验证）（182）对需求文档的审查是现有技术中最有效的软件质量技术。

在审查需求文档上花费一个小时，可节省多达10小时的工作时间。

（184）如果审查参与者自己还没有对工作产品进行检查，那么就先不要召开审查会议。

无效的会议可能得出审查纯粹是浪费时间这样错误的结论。

（187）第16 章需求开发面临的特殊难题如果不将需求具体记录下来，而只是通过心灵感应，就不要期望项目一定能取得成功。

（206）项目团队成员和相应的客户之间要时常进行交流，这是解决许多需求问题效率最高的一种方法。

编写的需求文档无论有多么详细，也法取代这些随时的交流。

尽早地而且是经常地设定优先级（207）第17 章超越需求开发有经验的项目经理和开发人员都知道把软件需求转化为健壮的设计和合理的项目规划的重要性。

（207）对于小型项目而言，团队在需求工程上所花费的工作量占整个项目所有工作量的12％-15％。

最成功的项目在需求工程中所耗费的资源占到项目总资源的28％，其中需求获取占11％，需求建模占10％，需求确认和验证占7％，一般情况下，需求工程的工作量占项目总工作量的15.7％，占用时间是项目总时间的38.6%。

（210）如果不将预估的情况与实际的项目结果进行比较，并提高自己的预估能力，那么其预估就永远只能是一种猜测。

（211）在做出预估和许下诺言之前，分析人员应该先探索需求，评估项目范围和判定项目规模大小。

（212）不确定的需求不可避免地会导致对软件的规模、工作量和进度的预估也不确定。

进度和预算安排中，应考虑到一些意外情况，留出一定的余量，以适应某些需求的增加。

主要的规划失误包括，忽略了普通的任务，低估了需的工作量和时间，没有考虑项目风险，没有考虑返工所需求的时间，以及对自己的盲目乐观。

（213）不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。

在有些项目中，软件设计并没有受到重视，但是，在软件设计上花费的时间是一种极好的投资。

（214）虽然试图理解大量的甚至是优秀的需求会令人望而生畏，但是，如果忽视它们，则是向项目失败迈出了决定性的一步。

无论如何，在编写代码之前先阅读需求，比起构建错误的系统之后再重新构建系统，还是快一些。

更快的方法是，让开发团队在项目早期就参与需求工作，可以尽早完成项目原型。

（217）如果不以高质量的需求作为项目规划、软件设计和系统测试的基础，那么在试图发布优秀产品的过程中将浪费大量的工作。

第18 章需求管理的原则和实践必须有人来控制需求管理活动。

（223）在人们手中流通的每一个需求文档版本都应该包括这样一些内容：变更的内容，每一个变更发生的日期，变更人的姓名和每一次进行变更的原因。

我们可以考虑在每一个单独的需求文档标签后面追加一个版本数字，可以在每次修改需求之后相应地递增这一数字的值。

（224）过于乐观的估计和过于放松的状态跟踪绝对是项目超支的原因。

（227）第19 章变更管理表面上很简单的一个变更，结果却比预想的复杂得多。

有时，开发人员没有—或者不能—对已提议的变更所需的费用和其他由此衍生的结果做出切合实际的估计。

（230）这种对变更的失控是造成项目混乱、进度拖延和质量问题的常见原因。

软件变更也并非总是坏事，实际上，提前定义所有的产品需求是不可能的。

如果一个高产的软件团队能够敏捷地对必需的变更做出反应，他们所构建的产品就可以及时满足客户需求。

离交付日期越近，就越不应该轻易对要发布的版本做出变更，因为变更的后果会很严重。

开发人员不应该将变更控制过程作为障碍而阻止变更，变更是不可避免的，应该正确处理它。

所有软件项目都会面临需求变更，但是，遵循一定的变更管理实践活动可以减少变更引起的混乱。

（245）第20 章需求链中的联系链简单的需求变更也常常会产生深远的影响，迫使产品的许多地方都需要进行修改。

要找出受某一需求变更影响的所有系统组件并非易事。

（247）如果有一张路线图就可以展示每一条需求或业务规则是在软件的哪些地方实现的，那么进行变更影响分析会更加容易。

需求跟踪机制将单个需求和其他系统元素之间的依赖关系和逻辑联系编写成文档，这些元素包括各种类型的其他需求、业务规则、系统体系统结构、和其他设计组件、源代码模块、测试用例以及帮助文件等。

在许多项目中，我们只需要付出大约20％的工作，就可以获得80％的期跟踪收益。

（248）第21 章需求管理工具第22 章改进需求过程需求是每个软件项目成功的核心所在，它支持其他技术活动和管理活动。

（269）在开发团队力图弄清楚系统应该做什么，而不断地重新编写代码时需要付出高昂的代价。

（272）请牢记下面4条软件过程改的原则：（272）1.过程改进应该是不断演化的、连续的、周期性的。

不要期望一次就能改进全部过程。

我们不应奢求完美。

2.只有人们和组织具有变更的动机时才可能实施变更。

引起变更的最强烈的动机来源于痛苦。