需求分析师2011(最新版)

《需求分析师2011(最新版)》由会员分享，可在线阅读，更多相关《需求分析师2011(最新版)（230页珍藏版）》请在装配图网上搜索。

1、需求工程讲义 软件工程专业高级软件需求分析师 第一部分目录前言- 6 -第一章 需求工程的理念与方法论- 8 - 1.1 高质量需求工程的意义- 8 -一、需求工程与需求开发- 8 -二、优秀需求具有的特性- 11 - 1.2 需求管理及其过程定义- 14 -一、对于软件工程方法的重新思考- 14 -二、需求管理的目标- 21 -三、需求管理的实践- 21 -四、稳定边界防止需求蔓延- 26 - 1.3 需求开发过程定义- 30 - 1.4 从系统工程的角度分析与组织需求信息- 32 -一、应用系统工程帮助分析问题- 33 -二、系统工程中的需求分配- 33 -三、组织复杂软硬件系统的需求-

2、35 - 1.5 项目外包及其需求管理- 36 -一、理解采用外包方式的原因- 36 -二、外包项目的需求管理- 37 - 1.6 利用需求模式重构问题- 39 -一、对功能分解的再讨论- 39 -二、利用模式解决划分中的困难- 39 -三、需求模式与需求复用- 40 -四、通过业务事件发现模式- 42 -五、通过抽象形成模式- 43 -六、模式与反模式- 45 -第二章 需求开发第一阶段：项目启动- 49 - 2.1 项目启动过程说明- 49 - 2.2 从问题分析开始需求开发- 54 - 2.3 问题域与问题框架- 57 - 2.4 分析客户问题思考产品愿景- 64 -一、从行业的视角思考

3、产品愿景- 64 -二、从产品战略的视角思考愿景- 67 - 2.5 初步定义解决方案的边界与约束- 69 -一、定义解决方案的边界- 69 -二、确定解决方案将受的约束- 70 - 2.6 项目的陈述- 71 -一、项目的陈述- 71 -二、愿景文档- 73 -第三章 需求开发第二阶段：客户需求的收集与分析- 76 - 3.1 需求获取过程说明- 76 - 3.2 通过建立模型来理解业务- 79 -一、在建立业务模型的过程中获取需求- 79 -二、业务的上下文范围与视图- 81 -三、过程分解与事件分解- 81 -四、为什么业务用例是好想法- 83 -五、发现业务事件和“无事件”- 84 -

4、六、建立业务用例的案例- 85 -七、基于领域建模的业务分析- 87 -八、基于控制系统的状态变迁模型- 90 -九、需求项框架- 95 - 3.3 用创新思维发现潜在需求- 96 -一、理解客户思维- 96 -二、相邻系统的角色- 97 -三、找出工作的本质- 101 -四、解决正确的问题- 102 -五、关注应用层面的创新- 102 - 3.4 创新的产品定义的初步策划- 105 -一、明确产品定义的类型- 105 -二、分析与澄清产品关键特征的价值- 106 -三、有目的有组织的系统化创新- 107 -四、通过产品组合策略实现创新- 110 - 3.5 需求获取中如何理解用户和涉众的需要

5、- 112 -一、引出需求方法论问题- 112 -二、创建用户代表- 112 -三、交流的能力与面谈技巧- 113 -四、理解用户的思维过程- 115 -五、文档考古学- 117 -六、业务用例研讨会- 118 -七、创造性研讨会- 119 -八、头脑风暴会议- 120 - 3.6 通过原型法挖掘需求- 122 -一、原型是“什么”和“为什么”要原型- 122 -二、水平和垂直的原型- 123 -三、抛弃型原型或进化型原型- 124 -四、通过原型挖掘需求- 125 -五、原型法的风险评价- 126 -六、如何使原型法获得成功- 127 - 3.7 产品边界的最后确定- 127 -一、确定项目

6、的最小目标- 127 -二、最终确定产品的价值与范围- 128 - 3.8 需求获取问题总结- 129 -一、需求获取的指导方针- 129 -二、需求获取中的挑战- 131 -三、需求获取中的注意事项- 132 -四、何时知道你完成了需求的获取- 132 -第四章 需求开发第三阶段：产品需求定义- 134 - 4.1 软件需求的严格定义及思考- 135 -一、软件需求的严格定义- 135 -二、需求的两难问题- 136 -三、迭代的需求和设计过程- 137 - 4.2 深入理解用例方法- 138 -一、用例的完整概念- 138 -二、用例是规范行为的契约- 139 -三、用例的目标层次- 14

7、1 -四、用例模型及其创建- 142 - 4.3 用例的结构化及其文档描述- 145 -一、包含、扩展与泛化- 145 -二、包含的场景描述- 146 -三、扩展的场景描述- 147 -四、用例的泛化关系及场景描述- 148 -五、正确编写用例的提示- 149 -六、用例的范围- 152 - 4.4 用例问题的进一步讨论- 155 -一、用例的益处- 155 -二、避免用例陷阱- 156 -三、用例和功能需求- 156 -四、发现变更规律- 157 - 4.5 控制需求与状态转换关系- 157 -一、状态转换- 158 -二、产品行为- 161 - 4.6 新产品开发项目中的需求问题- 162

8、 -一、有限的需求来源- 162 -二、模糊的需求界定- 163 -三、避免CPD陷阱- 163 -四、防止NV陷阱- 164 -第五章 需求开发第四阶段：归纳功能与非功能性需求- 165 - 5.1 发现和归纳功能性需求- 165 -一、从用例模型中发现和归纳功能性需求- 165 -二、细节程度和粒度- 166 -三、异常和可选方式- 167 -四、避免二义性- 167 -五、需求分组- 167 -六、功能性需求的替代方式- 168 - 5.2 发现和归纳非功能性需求- 168 -一、用例与非功能性需求- 169 -二、非功能性需求类型与软件质量模型- 170 -三、定义质量属性- 173

9、-四、冲突性的属性与取舍- 176 -五、不要编写解决方案- 178 - 5.3确定验收标准- 178 -一、验收需要标准的原因- 179 -二、测量的尺度- 179 -三、明确理由- 179 -四、非功能需求的验收标准- 180 -五、功能性需求的验收标准- 182 -第六章 需求开发第五阶段：编写需求规格说明- 183 - 6.1 需求编写过程说明- 183 - 6.2 需求规格说明书模板- 185 - 6.3 项目驱动与问题描述- 187 -一、项目目标- 187 -二、客户、顾客和其它风险承担者- 188 -三、产品的用户- 188 - 6.4 产品限制条件的确定- 188 -一、强制

10、的限制条件- 188 -二、命名惯例和定义- 189 -三、相关事实和假定- 189 - 6.5 功能性和非功能性需求的描述- 189 -一、工作的范围- 189 -二、产品的范围- 190 -三、功能性需求和数据需求- 190 -四、非功能性需求- 191 - 6.6 阐述项目问题- 191 -一、开放式问题- 191 -二、立即可用的解决方案- 191 -三、新问题- 191 -四、任务- 191 - 6.7 开发补充规格说明- 191 -一、在补充规格说明中表达需求- 192 -二、理解设计约束- 192 -三、补充规格说明模板- 192 - 6.8 设定需求优先级- 193 -一、为什

11、么要设定需求的优先级- 193 -二、不同角色的人处理优先级- 194 -三、设定优先级的规模- 194 -四、确定主题的价值- 195 -五、设定优先级的矩阵方法- 197 -六、评估优先级的风险识别与分析方法- 199 - 6.9 需求文档编写的若干建议- 202 -一、为什么要书写文档- 202 -二、走捷径及其风险- 203 -三、文档编写的建议- 204 -第七章 需求质量控制一：非正式需求评审- 206 - 7.1 产品质量保证体系中的复审- 206 - 7.2 需求质量与质量关的使用- 210 - 7.3 质量关过程- 210 - 7.4 质量关测试的有关问题- 211 -一、测

12、试需求的完整性- 211 -二、测试需求的可追踪性- 212 -三、测试术语的统一性- 213 -四、确定是否与目标相关- 213 -五、测试验收标准- 214 -六、确定在限制条件下是否可行- 215 -七、区分需求还是解决方案- 215 -八、顾客价值- 216 -九、镀金需求- 216 - 7.5 组织中如何实现质量关- 216 -第八章 需求质量控制二：正式需求评审- 218 - 8.1 需求评审是需求的确定过程- 218 - 8.2 复查规格说明- 218 - 8.3 需求评审方法- 219 -一、审查过程- 220 -二、发现遗漏的需求- 223 -三、确定是否发现所有的业务用例-

13、 224 -四、顾客价值- 226 -五、冲突的需求- 227 -六、二义性的规格说明- 227 -七、风险分析- 227 -八、优先级审查设定- 229 -九、需求评审的困难- 229 - 8.4 时代呼唤优秀的软件分析师- 230 -高质量软件需求分析与过程中科院计算所培训中心 谢新华前言在软件组织中，需求分析师的作用举足轻重。统计表明，软件缺陷一半以上的原因来自于需求分析中的问题。仅凭这个数字，就足以告诉我们要提高软件的质量、增强产品的竞争力，培养高水平的分析师队伍，建立有效的需求团队，定义合理的需求过程，坚持正确的需求规范是多么重要。但是目前在软件需求分析领域，还存在着过程粗糙、方法随

14、意、分析欠深入等问题，进而极大的影响产品质量，这正是在软件项目中，我们需要对需求分析下功夫的最大原因，我们有理由认为需求分析是奠定优秀软件的基础，本课程的主要思想如下：1，需求工程在整个软件工程中的地位十分特殊，良好的需求将支撑整个工程项目有序而高效的进展，并对产品质量控制提供依据。目前在创新成为重要主题的环境下，软件开发已演变成通过反馈逐步求精的过程，在这个过程中需求变更不可避免，因此我们不再认为需求仅仅是一个前期的工作，而几乎在每一个具体过程域中都在发挥作用。这就必须通过需求管理确保需求变更不至于对开发造成混乱，由此对需求管理提出了苛刻的要求。2，软件需求是一项在复杂环境中高风险、高影响力

15、的活动，所以单靠经验肯定是不行的，我们需要把问题抽象出来进行理论分析，发现它们之间的逻辑，通过缜密的逻辑思维，从系统的观点把方方面面的问题都关注到。这就需要以工程学的方法来处理需求，这要求分析师对需求过程有透彻的理解。3，需求分析的本质是在问题域中，为现实世界中的问题找到解决方案。事实上软件工程学就是发现问题并提出解决方案的一种工程方法。为了对“问题”这个主题有更加透彻的理解，我们需要更加理性的来探讨“问题”。需求分析师对于问题域的理解应该非常深入，需要有能力技巧性的处理问题域和问题框架，从而提出解决问题的产品构思。4，需求分析师不能仅仅是记录员，他需要理解客户思维，帮助客户理清问题。这就需要

16、分析师的工作有一整套方法论来支撑。包括业务建模、产品建模、在建模的过程中收集与理清想法，把握问题的关键，发现需求背后的需求，从而构思出真正符合客户需要的产品。在这样的过程中，要求分析师应该具有相当强的归纳能力。5，软件产品的价值在于其不断的创新，企业唯有将创新纳入有效的管理规划之中，遵循明确的指导原则和方法论，进行持续不断的系统化创新，才能长久地保持竞争优势。分析师的作用不仅仅是了解客户的需要，更需要在早期以一种创新思维参与产品构思，帮助客户从自己的现状中释放出来，这就要求分析师具有很强的创新能力。6，为了提高需求分析的质量，除了要系统研究需求分析中的方法论以外，更要研究需求过程中的质量控制问

17、题。需求的质量控制不仅仅是评审，在整个需求分析过程中都需要有可控制的质量保证，我们必须对每一种需求开发方法的优点与局限性理解深刻，把合适的方法用在合适的地方，从而极大的提升需求分析的质量，以得到高质量的软件产品。7，目前在需求分析中广泛使用着用例方法，但这也是误解最多的一种方法。我们必须对用例有深刻而正确的理解。如果编写恰当，不需要把用例转换为需求的其它形式，就可以准确地对系统行为进行详细地描述。编写有效用例，正确而专业的书写需求文档，完整定义功能性、非功能性需求及其测试条件，都是提升需求分析质量的重要控制点。8，近年来，由于项目越来越大、越来越复杂，应对软件的易变性就不可能完全从需求分析方法

18、本身解决问题，而需要有更加合理的项目过程。需求分析师需要对软件开发过程及其相应的需求分析方法有深刻的理解，从而主动使需求分析成为整个软件开发过程有效的一环，为高质量软件开发提供关键的支撑，这一切都对需求分析人员提出了十分苛刻的要求。本课程的授课特点是在理论指导下进行案例教学，通过汇集许多专家多年来理论和实践的总结，使课程既有理论高度，又通过“沙盘推演”提升实践技巧，使理论与实践完美结合，达到从根本上提升企业需求分析能力的目的。在授课过程中还根据不同项目特点提出不同的建模与需求分析方法，毕竟一个高级分析人员最重要的特征，就是根据具体环境，寻找更加合适的方法，从而避免死板僵化毫无生气的分析模式，代

19、之以生动活泼富有创造性的分析过程，通过学习，希望国内IT企业项目开发达到一个新的水平。 中科院计算所培训中心 谢新华 2011年5月 北京第一章 需求工程的理念与方法论1.1 高质量需求工程的意义最有用的产品是这样一些产品，这些产品的开发者理解产品应该具备什么样的功能，也了解产品必须以何种方式实现其目的，为了理解这一些，首先必须理解客户希望完成哪种类型的工作，而我们开发出的产品将会以何种方式影响这些工作。产品为用户所做的事情，以及产品在这种上下文背景中必须满足的约束，就是产品的需求。在本课程讲义一次又一次的重构当中，应该说第一章的变化是最大的，我们一直在思索，正确的、符合实际的需求工程理念到底

20、应该是什么样的？和需求的本质一样：这一方面反映了人们认识事物的螺旋上升观念；另一个方面，也反映了社会环境和实践过程的不断变化，使我们对问题的理解也发生很大变化。我们在实际工作中遇到了很多问题，这些问题无论给项目还是我们自己都带来了很大的困惑，但我不准备被这些具体问题拖着走，就好像掬起水面上漂浮的渣滓和水泡一样，如果过于关注眼前的事情，往往就不能发现问题的本质。我们需要更深入的提炼出一些东西，凡事都有逻辑，我们需要理解一种体系和内在的逻辑关系。本课程针对的是有工作经验的分析师，讨论的大思维，并不准备手把手的教一步步怎么做或者文档怎么写，因为那是对于初涉分析的人所为，而我们现在所需要的是一种思想和

21、方法论，是需要站在更高的角度想问题。需求工程并不可能是一套约定俗成的概念和知识，用削足适履的方式，按着某些固定的方法到处套用就可以成功的了。相反，它体现为一种观察问题的观念和解决问题的方法，最终体现为理解和实施的能力，因此这一章的内容就显得举足轻重。如果在一开始就站到一个宏观把握时空优化理念的高度，那么当进入后面细节讨论的时候，就会觉得心有灵犀、游刃有余了。一、需求工程与需求开发1，需求工程模型为什么软件需求需要一套完整的工程方法呢？程序设计的有效性依赖于规格说明，规格说明的有效性依赖于对问题域的理解。没有好的需求，就没有办法验证程序设计的正确性，也就没有办法把程序与客户的期望用一种逻辑性的方

22、法联系起来。特别是当项目比较大需要很多人共同工作的时候，良好的需求可以保证整个开发团队沿着规定的目标一起前进。其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误带来的。出现的问题涉及到非正式信息的收集，未确定的或不明确的功能，未发现或未经交流的假设，不完善的需求文档，以及突发的需求变更过程。这一切都告诉我们，必须深入地研究和建立良好的需求工程方法。需求开发过程建立了一套需求收集、建模、分析、和描述的循序、方法和模版，使需求可以以一种有序而深入的方式进行。另一方面，由于需求在开发过程中会发生若干变化，会对管理过程的方方面面产生影响，所以从工程的

23、角度，我们又可以把整个需求工程分为需求开发和需求管理两部分，下图为需求工程的结构图。 2，需求开发 需求开发的流程以及它与需求管理的关系如下。它主要包括客户需求的收集与分析以及产品需求定义两部分，主要的输出是“客户需求说明书”和“产品需求规格说明书”，整个过程有一系列的技术和技巧，这是本课程的重点内容。需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。所谓需求分析，是把软件系统的功能表示成单一的信息变换过程，需求分析也是一个分解的过程。需求的表达常常是抽象的，以一种与技术无关的方式表达，这样做的目的是为了避免解决方案对技术产生影响，需求是对业务方面的说明，而不能有任何技术实现

24、上的偏好，产品设计的角色是把需求翻译成一个计划，按这个计划就可以构建出一个实体。为什么在软件开发中最需要关注的是需求开发呢？1）需求是产生软件缺陷的最大原因随着经济全球化进程的不断推进，要增加产品的国际竞争力，产品质量作为经济发展的战略问题变得越来越重要。软件质量问题相当程度上是以软件缺陷（defect）的形式出现的。软件缺陷是由很多原因造成的，但从整个开发周期的统计结果来看，我们会意外的发现规格说明书是软件缺陷出现最多的地方，如下图所示。换句话说，需求分析的不到位，是产生软件缺陷的最大原因。产生这种情况的原因如下：l 客户一般是非计算机专业人员，软件开发人员与客户沟通存在着比较大的困难，对要

25、开发的产品功能理解也不一致。l 由于软件产品还没有设计、开发，完全靠想象去描述系统的实现结果，所以有些特性还不够清晰。l 客户的需求总是在不断的变化，容易引起前后文、上下文的矛盾和需求描述的不一致。l 需求分析没有得到足够的重视，在规格说明书的设计和写作上投入的人力、时间都不足。l 没有在整个开发队伍中进行充分的沟通，有时只有架构师得到比较多的信息，造成人们对问题理解的不一致。2）软件开发最困难的工作是编写需求需求开发在软件项目中扮演的角色非常重要：开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向客户、面向机器和其它软件系统的接口。同时

26、这也是一旦做错，将最终会给系统带来极大损害的部分，并且以后再对它进行修改也极为困难。3）需求开发是定义产品的投资花在了解客户需要上所花的时间，是使项目成功的一种高层次的投资。这对于用户应用程序、企业信息系统和作为大系统的一部分的软件产品是显而易见的。对于开发人员来说，没有编写出客户认可的需求文档，我们如何知道项目于何时结束？如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？4）需求有利于内部理解的一致有些并非出于商业目的的软件，例如软件库、组件和工具这些供开发小组内部使用的软件，偶尔不需要文档说明就能与其他人意见较为一致。但更常见的还是出现重复返工这种不可避免的后果，而重新

27、编制代码的代价远远超过重写一份需求文档的代价。5）正确的需求是测试的基础假如我们为一个要集成到“商业错误跟踪系统”中的简单电子邮件界面写了一页需求说明，而Unix系统管理员在为处理电子邮件写脚本时，就会发现简单的一张需求清单竟是如此有用。我们还会发现，当依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且可以轻易发现任何最终的错误。正确的需求是测试的基础，在最普遍意义上都是正确的。3，正确的需求与有缺陷的需求需求获取的方法很多，那么什么样的需求获取方法才是正确的呢？ 1）关键是关注规律而不仅仅是记录需求过程之难并不在于某些书写标准或规范，也不是仅仅了解客户需要什么，而是需要深

28、入地从各个角度探究客户需求，总结出客户需求的本质和将来变化的规律，这就对需求分析师提出了很高的要求。需求分析非常重要，如果事情说不清楚，就没有办法做好。2）实行有效的通力合作正确的需求过程强调产品开发中的通力合作，包括在整个项目过程中多方风险承担者的积极努力。收集需求能使开发小组更好地了解市场，而市场因素是任何项目成功的一个关键因素。在产品开发前了解这些比在遭到客户批评后才意识到要节约很多成本。让客户和用户积极参与需求收集过程能使产品更富有吸引力，而且能拥有忠实的客户关系。3）全方位考虑需求问题将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成，也能确

29、保软硬件系统功能匹配适当。有效的变更控制和影响分析过程也能降低需求变更带来的负面影响。最后，将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量，以使所有风险承担者感到满意。但是，现实中我们会遇到太多的有缺陷的需求收集方法，归纳起来原因不外是下面几点： 1）无足够用户参与客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视客户的参与。究其原因：一是因为与客户合作不如编写代码有意思；二是因为开发人员觉得已经明白客户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。2）客户需求的不断增加在开发中若不断地补充需求

30、，项目就越变越庞大以致超过其计划及预算范围。计划并不总是与项目需求规模与复杂性、风险、开发生产率及需求变更实际情况相一致，这使得问题更难解决。实际上，问题根源在于客户需求的改变和开发者对新需求所作的修改。产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作不完善的话，收回变更和删除特性会带来问题。如果能够尽早发现可能带来变更的特性，我们就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。3）模棱两可的需求模棱两可是

31、需求规格说明中最为可怕的问题。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例并重做许多测试。4）不必要的特性“画蛇添足”是指开发人员力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能。经常发生的情况是客户并不认为这些功能性很有用，以致在其上耗费的努力“白搭”了。开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路

32、，具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡，开发人员应努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而实现这些功能只能徒耗时间和成本。5）过于精简的规格说明有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。但在大多数情况下，这会给开发人员带来挫折，也会给客户带来烦恼，因为他

33、们无法得到他们所设想的产品。二、优秀需求具有的特性怎样才能把好的需求规格说明和有问题的需求规格说明区别开来？如何才能让风险承担者从不同角度对SRS需求说明进行评审？只要我们在编写、评审需求时把下面这些特点铭记于心，就会写出更好的（尽管并不十分完美）需求文档，同时也就有可能开发出更好的产品。 1，需求的层次与演进 一个优秀的需求应该具备很强的层次感，并且能够在发展过程中不断演进。 1）需求的层次下面我们定义在需求工程领域中常见术语，软件需求各部分关系如下图所示。软件需求包括三个不同的层次：客户需求、产品需求、功能需求以及非功能需求。客户需求：（目标需求）反映了组织机构或客户对系统、产品高层次的目

34、标要求，它们在项目视图与范围文档中予以说明，有时候客户需求是以任务书的方式表达的。客户需求一般表述比较抽象，缺乏很多必要的细节。产品需求：（业务需求）描述用户使用产品必须要完成的任务，也称之为用户需求。这种需求需要考虑产品的运行方案，在用例（use case）文档或方案脚本（scenario）说明中予以说明。功能需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了客户需求。所谓特性（feature）是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足客户需求。非功能需求：（性能需求，约束与限制）描述了产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计

35、或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。软件需求规格说明（Software Requirements Specification，SRS）：中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于软件部件。 所有的用户需求必须与客户需求一致。产品需求使需求分析者能从中总结出功能需求以满足客户对产品的要求从而完成其任务，而开发人员则根据

36、功能需求来设计软件以实现必须的功能。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。2）需求的演进需求开发是一个演进的过程，也是对问题理解不断深化的过程。在项目开始的时候，需求分析师关注的是产品将要支持的业务（或者称之为工作），在这个阶段，分析师研究场景及其它模型，与客户以其讨论在业务上应该做什么?要解决什么问题?在这些问题上达成一致意见，这时候的需求可以称之为“客户需求”。随着对业务理解的加深，风险承担者对有助于自己工作的最佳产品做出了决定，现在需求分析师开始确定产品的详细功能，并且编写“产品需求”。非功能性

37、需求几乎是在同一个时间导出来的，包括质量属性和限制条件一起被记录下来。此时，需求使用一种与技术无关的方式写下来，它规定了产品应该为业务做些什么，但没有规定应该用什么技术方法来实现。如下图所示。 2，需求说明的特征我们可以归纳出好的需求说明应该具备如下特征，这也是需求分析的目标：l 完整性：每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。l 正确性：每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如客户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。l 可行性：每一项需求都必须是在已知系统和环境的限

38、制范围内可以实施的。为避免不可行的需求，最好在获取需求过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。l 必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。l 划分优先级：给每项需求、特性或用例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。l 无二义性：对所有需求说明的读者都只能有一个明确统一的解释，避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原

39、型等。l 可验证性：检查一下每项需求是否能通过设计测试用例，来确定产品是否确实按需求实现了。如果需求不可验证，则确定其是主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。3，需求规格说明的特点需求分析的交付物是“需求规格说明”，好的需求文档应该具备如下特点：l 完整性：不能遗漏任何必要的需求信息。注重用户的任务而不是系统的功能将有助于你避免不完整性。l 一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。l 可修改性：在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求

40、区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。l 可跟踪性：应能在每项软件需求与它的业务和设计元素、源代码、测试用例之间建立起跟踪链，这种可跟踪性要求每项需求以一种结构化的，粒度好的方式编写并单独标明，而不是大段大段的叙述。上述对于需求开发的宏观描述非常重要，有了这些宏观理解，我们就为自己下一步工作设定了一个目标和界限，在出现困惑的时候，就不至于迷茫或者无从下手，思路也会更加清晰。一个好的需求分析人员所具备的素质，包括理念、方法论、性格以及正确的哲学观念，对这些问题的融会贯通，是我们成功之本。1.2 需求管理及其过程定义在开始讨论这一节内容的时候，人们会有一

41、个很好奇地问题：作为一个分析师课程，应该先谈需求开发，然后才是需求管理。这里先谈需求管理，从秩序上说似乎是搞反了（应该是先有开发后有管理呀）。但是无数事实告诉我们，如果没有很好的需求管理，就不可能很好的完成需求开发工作，而且需求开发也无法寻找到正确的方法。因此，我们首先给出需求管理的推荐实践，然后逐步推进到有组织的方式与顾客共同开发需求，这个顺序是合理的。很多专业人员都相信需求管理对于任何项目管理者来说都是最重要的工作。因为人们普遍面对着范围蔓延、偏离方向的期望、放弃、迷茫的顾客，这些情况都使项目的前景变得暗淡。因此，我们应该认识到需求管理是一项最基本、最基础的管理职责。需求不断变更是我们常常

42、遇到的情况，由于人们认识事物的规律，是不可能早期把一切都描述清楚的，需求变更是不可避免的。在一个健全的需求管理方法之下，我们和顾客就可以使用一种机制来同步，共同运作，并且不会产生分歧。一、对于软件工程方法的重新思考 1，瀑布方式的问题要研究需求首先就需要研究需求在软件过程中的位置。传统的软件工程认为，需求是一个前期的工作，这个观念源自于瀑布式过程。这是一种顺序的、基于活动的思维定势，这些活动包括：需求收集、设计、编码、测试、集成一直到验收。通过这种一级一级进行的活动，来确保开发过程的有序。经典的瀑布开发过程这个过程要求在任何设计和实现工作之前，尽可能的推敲，把需求完全定义清楚，并把它稳定下来（

43、冻结需求），然后建立系统高层模型，包括系统和子系统的框架以及基于服务的层等。在底层设计阶段，可以精细的把客户需求转换为系统模型。然后在实现诸如编码、测试、系统集成以及部署等下游模型。 瀑布式过程有8条经典法则：l 在设计之前先要冻结需求。l 在详细设计之前不要编码。l 在集成之前要完成单元测试。l 必须有详细的文档。l 所有的交付文档都需要详细并且维护可追朔性。l 质量评估必须是单独的团队（QA）。l 高度精确的对所有的事情做计划。l 审查所有的事情。确实，这是一种非常好的工作方式，除非你是要做软件。至少，在现实中很少有客户承认需求已经被冻结了，也同意在这个被冻结的需求上签字，承诺今后如果需求

44、变更了客户将负全部责任。如果这一条做不到，那后面所有的条条都将成为无木之本。一个典型的瀑布式场景如下：一群利益相关人与分析师从一组高层需求开始讨论，5个月后，分析师根据根据条客户要求把需求细化到了一定程度，他们书写出了需求规格说明书作为这个阶段的结束。需求规格说明书经过客户评审，他们认为这基本可以达到要求。管理层认为他们已经充分理解了需求，可以进入设计阶段了。需求规格说明书被发送到了设计团队，设计师依据需求规格说明书设计产品，2个月后，完成的设计又经过了设计评审，被认为符合要求，于是设计说明书被发送到了编码团队。几个月后，代码开始陆陆续续交给测试团队，测试团队开始寻找代码中的缺陷。项目经理对这

45、种有序的按计划进行的项目甚是满意，但是历经一年后客户看到了初步的版本，他们的反应让项目经理大吃一惊，他们认为这并不像他们当初在需求规格说明中规定的东西，于是客户至上主义使项目经理答应进行修改，问题是不仅仅是编码，一直到需求、设计、测试条件都发生了修改，找谁？于是开始发生混乱，到后来，客户又提出加入新的需求（因为一年中很多想法和环境变了），混乱开始加剧，最终项目经理失去了耐心，开始与客户争吵，这种混乱降低了效率、增加了成本、破坏了质量，开发方的损失谁来承担？客户没有按期得到有用的产品，这个损失又是谁来承担？这种混乱到底是谁造成的？到底发生了什么错？历史上曾经长期认为需求是一种前期工作，但是在今天

46、创新成为重要主题的环境下，我们对于需求的看法也发生了很大的改变。在这个背景下我们有理由质疑先有需求后有设计的观念。无数事实告诉我们，无论人们对前期需求收集下了多么大的功夫，后期的需求变更都不可避免。这一方面来自于人们认识事物的螺旋上升性，也来自于外部世界变化的快速性。2，需求的滚动式循序渐进模式1）需求在动态中的滚动完善正是由于无数个瀑布过程项目的失败，才促使人们仔细研究需求过程的本质。需求并不是一个独立的东西，也不仅仅是一个前期的工作。需求是一个对客户需要不断理解和加深认识的过程，因此我们必须理解关于认识论的本质。人们认识事物，总是一种由粗而精，螺旋上升的过程，因此在项目过程中需求的变更是不

47、可避免的。从另一方面说，需求又和项目计划息息相关，需求的变化必然会引起项目计划的变更，这就需要用集成的观点看问题。当我们尝试用动态的观点看问题时，软件项目自然就会有一种独特的渐进特点，需求以及它所影响的项目计划必然也会经历一个由粗而精、不断完善的过程。也就是项目的需求在频繁反馈中不断变更、滚动完善的模式，如下图所示。一个项目初期需求可能比较粗糙，经过实施校正、控制反馈之后，提出变更需求，再将变更后的需求输入实施过程，在进一步的控制反馈之后，再一次提出变更完善的需求这个循环往复的过程可能会贯穿项目始终。正是这个原因，在现代软件开发理念中，需求的变更和变更申请占有很重要的地位。我们应该深刻理解项目

48、需求的两难境地，当前景不确定因素太多的时候，一种倾向是：通过猜测构造一个似乎详尽面面俱到的需求规格说明，由于这个需求相当繁复，在发生变化的时候根本无法更新这个复杂的需求文档，结果原始的需求被束之高阁。另一种倾向是：初期需求编的太粗，以便留下变更的弹性，结果是需求的粗糙又为实施过程制造了大量新的不确定性因素，迫使需求反复修改，这种按下葫芦浮起瓢的局面，最后导致了一个灾难性的后果，也就是需求变成了一个毫无威信的文字游戏，谁也不认真对待了。需求的滚动完善模式，把需求失控的被动变更，变成了可控的主动变更，可以有效地解决上述矛盾。整个过程有点像编写书的提纲，一本书有部、章、节三级提纲，后面的二级提纲会随

49、着一级大纲的推进而逐步展开，而三级提纲将随着二计提纲的推进而逐步细化。这种把不确定性因素逐步明朗、有粗变细、循序展开的方法，可以同时兼顾需求的刚性和弹性、前瞻性、反馈性、准确性等诸多要求。2）变更点放在哪里更合适？问题在于这个需求的变更点应该在什么地方？需求的变更要求是随时都可能发生的，把项目开发变成昆虫，把需求变更变成了刺激，刺激到来昆虫就一跳，这样的开发除了造成混乱以外没有其它作用。为了减少需求变更对于开发的不利影响，防止随着需求变更项目也不断随需而变，我们可以制定如下的规则：首先：以每个里程碑为一个单元，建议一个里程碑的时间长度为项目整个生命周期的1/12左右，每个里程碑是一个完整的计划

50、、实施与控制过程，其任务就是交付一定数量的产品。其次：在一个里程碑时间段内需求是不能变更的（如果客户有变更要求可以说：现在离里程碑点已经不远了，先记下来，到那个时候一起讨论），所有团队成员全力以赴达到里程碑目标。最后：在每个里程碑点上，除了传统的检查评审以外，还需要加上一项，就是与客户一起主动寻求新的需求，进而制定新的计划，化被动为主动。这样一来，需求管理与项目管理之间的集成关系就变得清晰了，如下图所示。从顺序上来说，在需求分析与计划制定上要分三个层次来考虑问题：首先考虑远期目标，先有目标分析，确定最终成功交付的一个稍稍模糊但是具有宏观指导意义的目标。远期宏观需求不能没有，不然会形成一个目光短

51、浅随需而变的开发；也不能太详细，否则会形成靠猜测形成的Glass Case Requirements（玻璃柜需求），既无法更新，也 无法应对需求变更，最后这个需求被束之高阁，计划也不会被遵循。然后是中期目标，也就是里程碑目标，根据需求的优先级，设定每个里程碑需要交付的功能，也就是说，里程碑计划关注的是该点的结果，而不是活动。最后才是近期目标，以目前的里程碑（很多情况下还包括下一个里程碑）为界，进行详细的需求细化分析，然后再规划里程碑期间的任务和活动，这就可以根据现有的状况来应变，使计划可以落实。 从宏观上说，里程碑实施是动态的，而里程碑评审是静态的。对于变化而言，动态过程中实施变化要比静态过程

52、实施变化难得多，所以坚持了这个规则，就有可能在动态实施与静态变化之间实现了良好平衡。3，迭代的软件工程过程模型1）现代软件过程域之间的关系现代软件工程各个过程域之间的关系不再是一个线性的关系，而是一种迭代的关系，中间必须有计划的加入各种反馈、控制和修正，如下图所示（此图取自于GJB 5000A-2008，基于军标的软件工程描述，可以认为很好的诠译了现代软件工程思想）。2）软件工程过程中的需求管理需求管理本质上具备管理学的一切要素。但是，我们也要看到在项目开发中，需求管理并不是独立存在的，而是需要与项目管理的其它领域整合在一起，形成一种集成管理体系。事实上未经整合的各个领域管理规划，是不宜于指导

53、项目的实施和控制的，只有整合成一套集成管理之后，才具备指导实践的实质性意义，对此我们要有充分的理解。3）需求开发与各个领域之间的互动关系为了更好的把需求管理集成在软件开发管理中，就需要关注需求开发与各个领域之间的互动关系。在整个项目的进展过程中，需求不可避免的会与各个要素产生互动影响，而且大多数情况下处在一个主动位置：l 需求的变化会引起重新设计，进而影响计划、时间、成本和质量。l 需求的变化也会影响确认和验证，质量标准的变化会影响工期和成本。l 实践中我们会发现，设计影响需求的情况也屡见不鲜。所以，需求对项目其它领域的影响可能是被动的，也可能是主动的，这种因果关系极其复杂，弄得不好会使项目一

54、片混乱，这一切都构成了项目开发中中最具挑战性的内容。因此，加强需求管理的能力就需要从各个要素相互作用力的角度想问题：到底是谁在影响谁？影响后又发生了什么？会有什么样的结果？怎么来解决？这种解决方案是正反馈还是负反馈？如果是正反馈的话，如何改变反馈通道使其变为负反馈呢？这是一个睿智的高级技术与管理人员必须时时缠绕在脑海中的问题，这样一来我们就有了大思维，有了解决问题的能力。一般来说，对于需求管理的能力可分为三个层次：第一层次：可以看到需求与各个要素之间的互动关系。这是算术级，能够发现变化的产生。第二层次：能够区别需求与其它互动要素中主动和被动关系。这是代数级，能够发现变化之间的因果关系，由因果关

55、系更深一步发现反馈通道。最高层次：能够判断出各类要素在不同时间段的主要和次要关系的转化。这是导数级，能够发现变化要素的变化趋势。这些都对需求分析师与项目管理人员提出了更高的要求。2，迭代式开发的阶段正是由于不确定性是今天软件开发所固有的，所以人们提出了迭代式开发方式，其特点是：并不监督一个长期的计划执行，而是研究如何引领软件项目通过“不确定性”所带来的壕沟。“引领”一词隐含着这样一层意思：管理层主动参与，不断纠正航向，目标是生产出更好的软件。而这个对于目标的“瞄准”是由利益相关人相互合作达成的。这种迭代过程由于其本身的不确定性，在管理上是有难度的。特别是在极其复杂的环境下，如果没有经过整体设计

56、和构思，直接进入螺旋迭代风险将会很大。为了平衡这种演进减少管理上的难度，需要有一种对于不确定性和风险进行管理的策略。典型的生命周期包括四个大的阶段，每个阶段都具有可验证的结果以及若干子阶段。这几个阶段分别为：初始阶段：愿景、业务用例的定义以及原型化。架构阶段：对于架构基线的综合、论证和评估。构建阶段：按子系统分成若干项目组，增量式的对有用的功能进行开发、论证和评估。交付阶段：可用性评估、最终部署以及发布。这些阶段是以一个大的项目状态为标志的，是结果驱动的，而不是以顺序的“需求、设计、编码、测试、交付”的一个活动序列为基础，这种方法整体上主要是一种顺序周期。对于设计、开发和大部分测试使用了迭代方

57、法，如下图所示。 图中也标出了在各个阶段建议的文档，文档的略语表如下。软件工程策略略语表CSCI计算机软件配置项DBDD数据库设计说明SRS软件需求规格说明STD软件测试说明IRS接口需求规格说明STR软件测试报告ARS架构需求规格说明HWCI硬件配置项ADD架构设计说明SVD软件版本说明ATD架构测试说明SPS软件产品规格说明SDD软件设计说明STrP软件移交计划IDD接口设计说明1）初始阶段这个阶段主要工作是调查，并通过调查研究生成一个项目的愿景。其工作方法是通过业务上下文和收集业务事件来确定解决方案的边界。对环境进行彻底的搜索，以寻找位于边界之内或在边界之上进行交互的潜在输入。这些输入构

58、成现场调查的一部分，这个阶段的结束时得到了一个工程规划，这个规划确定了接下来的迭代工程周期的结构。在这个阶段，我们的精力集中于系统级的需求收集，在这个层面，我们关注于整个系统的功能和非功能需求，但是要站在更为抽象的角度描述问题。对于非功能需求的收集和协调是这个阶段一个重要的关注点，这对于项目最后的成功极其重要，有一些原型化的初始方案也可以在这个阶段进行评估。我们还可以对系统级需求进行划分，从而引发一些派生的需求（例如子系统需求与接口需求等）。这个阶段的需求必须经过评审，以期把整个项目完整的定义下来，同时可以用这样的需求信息对项目进行早期的估计。2）架构阶段根据初始阶段的结论，进行架构概念设计，

59、寻找架构最需要解决的问题和重点，明确解决方案。在这个基础上，以实现的方式完成初始架构设计与实现。再进行架构基线的综合、论证和评估。在架构阶段结束以后，项目规划需要估计构造阶段实际的迭代次数、每次迭代的周期，在这个阶段，我们需要把精力集中于架构级别的需求收集，进一步精化和优化系统划分。这时候需求收集的重点是各个子系统和模块的需求定义，确定它们如何协调和通讯，以及架构如何满足系统质量属性的等。架构设计一般经过几次迭代，设计的结果需要经过评审，从而确定整个产品的体系结构已经完成。架构阶段所关注的是系统高风险的部分，力争早期缓解高风险。要鼓励团队集中注意力，设定一个近期的最终工作目标是很重要的。架构要

60、进行实际的测试，这一点很重要，否则，软件架构能否达到质量属性要求不得而知，这就埋下了众多技术风险。3）构建阶段在软件架构完成以后，需要根据已有的需求信息进行整个项目的规划和估计，针对每个子系统分配资源，组织适当数量的开发团队，使每个开发团队进入各自的迭代周期。此时，架构设计噢能够架构的优化和改进组成员参加各个小组工作，主要任务包括：介绍系统架构概念，收集系统架构问题，进行系统架构优化。构建阶段将采用多次循环迭代模式，它遵行“发现、重构、生成和测试”这样一个过程，其中伴随着反馈。在这个阶段，对问题描述、解决方案和用于支持解决方案的模式进行增量的精化。在第一次迭代结束以后，需要把细化阶段结束时的迭

61、代次数估计重新进行修正。在每个迭代周期的开始，需要根据需求的优先级选择适当数量的的增量功能，在迭代开始以后，首先是对这些增量功能进行详细的需求收集与分析，这个级别的需求是由迭代小组中的需求人员带领小组全体成员共同来完成，然后编写详细级别的需求文档并经过确认。以此为基础顺序的进入设计、编码、测试等各个阶段。每次迭代交付的是可以提交的功能增量。要注意的是，每次变更都必须修改相应的需求文档，并做下记录。在这样复杂的过程中，良好的软件配置管理是非常必要的。4）交付阶段此阶段首先通过完成任何剩余的测试来执行正式的系统验收。重点应该放在验收和操作测试上，因为其它部分已经完成了。这个阶段的主要输出包括：测试报告、教育和培训资料。然后把已验收的解决方案被移交给服务交付和应用程序维护人员。开始新解决方案的培训和教育。此后解决方案开始运行。这个阶段的主要输出包括：应用程序维护移交包、服务交付移交包。 在这个阶段我们需要关注产品集成。产品集成的关键是管理产品和产品部件的内外部接口，确保接口间的一致性。要注意的是，产品集成不只是在设计和制造结束时一次性的产品部件组装。产品集成可以在迭代过程中增量地进行并评价，然后组装更多的产品部件，并通过日益增多的实际递增，功能稳定地前进，直至完成最终产品。在每个迭代的逐次构造阶段结束的时候，都需要基于评价在这个阶段所获