软件需求分析_掌握需求过程

软件需求分析过程，分享给有需要的人34用户—一理解他们235风险承担者和顾问353.6需求限制条件37为您的宝宝命名363.8设定范围4139该产品的成本会是多少3.10风险业务3.11继续还是终止312启动会议替代方案.13小结45第4章事件驱动的用况如何确定产品的合适组成部分(使用业务事件作为起始点)以及如何确定要构造的最好产品454.1理解工作4742用况和它们的范围4843工作44业务事件514.5发现业务事件5346工作对事件的响应5447相邻系统的角色48确定要构建的最佳产品6249创新的产品4.10技术重要吗411事件驱动的用况412小结第5章网罗需求如何收集需求。我们讨论了发现、提取和创造需求的技巧,51职责52网罗活动53当前状况扮演的角色7554做学徒765.5观察结构和模式56用户访谈57找出系统的本质8058业务事件研讨会8259头脑风暴510思维图:一个有用的工具511录像:秘密武器512电子化需求553文档考古学85514白卡87515发现最佳工作5t6小结88第6章功能性需求91功能性需求指产品必须完成的任务。这里我们讨论发现和明确产品的功能61功能性需求9262小结96第7章非功能性需求非功能性需求指产品必须具备的属性。这里我们讨论如何发现和明确它们。7.1非功能性需求7.2观感需求:类型10·10173易用性需求:类型1174性能需求:类型1210675可操作性需求:类型13·1077.6可维护性和可移植性需求:类型14··77安全性需求:类型1511078文化和政策需求:类型161129法律需求:类型171137.10发现非功能性需求1144711不要写解决方案712小结117第8章编写需求规格说明书119如何将所有需求安排在需求说明规范中8 Volere需求规格说明书模板,12082产品限制条件122.3需求项框架8.4编写需求规格说明书1338.5非功能性需求13686项目问题1367小结140第9章验收标准143g,卡为了消除模糊之处,我们引入了需求的度量。这使需求变得可测试,这样就可以知道实现是否与需求相符。91为什么验收需要标准92度量的尺度1459.3功能性需求的验收标准94非功能性需求的验收标准9.5用况和验收标准9.6限制条件的验收标准15397小结154第10章质量关157防止模糊需求成为需求说明规范的一部分的一种机制。10.1使用质量关15810.2完整性15910.3测试可追踪性10.4一致地使用术语.16110.5是否与目标相关16210.6检查验收标准16310.7在限制条件下是否可行10.8是需求还是解决方案16510.9顾客价值10.10镀金需求16710.1需求蔓延10.12实现质量关17010.13小结171第11章原型和场景173如何让需求活起来,以发现遗忘的和未曾期望的需求111低保真原型1751.2高保真原型178113场景模型114故事板181115对象生命历史181116原型循环18217小结第12章重用需求产品极少是完全独一无二的。我们向您展示了如何利用已经写好的一些需求。121什么是重用需求187122可重用需求的来源18923需求模式19012.4通过抽象形成模式19612.5领域分析198126重用的趋势·199127小结第13章鉴定需求规格说明书完整回顾您所写下的东西,这也是一次重新测度和评估需求的机会31发现遗漏的需求13,2是否已发现所有的用况133冲突的需求210134验收标准21213.5二义性的规格说明21313.6风险分析21313.7度量所需的工作量b21513.8功能点计算简介216139客户价值21913.10评估您的产品22013.11小结第14章需求向何处去221写好需求之后做什么?我们讨论了需求工具、出版需求说明规范、可跟踪性、更改和管理需求141需求工具如何22114.2工具对照目标143剪裁过程223144发布规格说明书··225145·需求可追踪性勹14.6处理变化230147需求事后分析232148结束235附录 a Volere需求过程模型237个完整的需求过程模型附录 b Volere需求规格说明书模板个编写需求说明规范的模板,它可作为您的需求文档的基础词汇表323参考文献327第1章什么是需求本章我们考虑为什么我们对需求感兴趣需求就是那些您必须在开始构建产品之前发现的东西。如果在构建的过程中才发现需求或者更糟糕,直到客户已经开始使用您的产品了才发现需求,那么代价将是很大的,并且效率将极其低下。因此我们假定,任何思维正常的人都不会这样做,对此以后将不再赘述。让我们开始吧。假设您将要构建一个新产品。该产品必须做些什么?控制一架飞机?预测您的组织的赢利能力?将卫星数据转换成适合播出的图像?这些可能描述了您的产品可以达到的目的,但是为了达到该目的应该做哪些事?这些就是产品的功能性需求。产品必须有怎样的品质?它必须快速吗?或需要易于使用?能在黑客进攻下保证安全?它所必须具备的品质就是它的非功能性需求本书将告诉您如何发现这些需求。而且,它还将告诉您如何得知您发现的需求是否正确。对于任何结果重要的工作来说,最好使用某种有序的过程来完成。本书展示了 Volere,是一个过程和一个需求规格说明书模板,用于收集、确认和文档化产品的需求。我们的例子预期产品将包含某个重要的软件组件,或是用户定制的,或是商业上架销售( commercialoff-the-shelf,CoTS)的,也许是一个维护项目。但是,本书介绍的过程可用于任何类型的产品。目前,该过程与其他技术一起,被用于收集很多不同产品的需求,诸如潜艇系统、银行系统、电话网络系统。很明显,需求必须在构造产品之前就知道。我们提供咨询的大多数组织都通过一些系统分析来发现产品必须做什么。就是说,他们使用 DeMarco的数据流表示法,或是 McMenamin和 Palmer的事件-响应模型来为系统建模。也有人使用这两种技术的一些变种,今天,越来越多的组织使用某种类型的面向对象分析技术,通常使用统一建模语言(UML)的符号表示法。我们对此并不作争论。实际上,如果您还没有在系统分析中使用某种建模技术,我们建议您去使用,马上使用。如果您已经在做系统分析工作了,那么请继续读下去。需求不是一项额外的负担,而是可以对您的分析师职业生涯有所促进。为了看看它是如何起作用的,请看图11所示的开发生命周期。两个初始活动,即需求过程和系统分析,决定了要解决的业务问题或需关注的机会,以及该产品能为整个解决方案提供些什么。掌握需求过程目标操作风险承担者的环境想法和需要产品反馈需求处理过程产品使用需求规格说明书构建反馈分析反馈产品设计反馈系统分析构建分析规格说明产品设计书和需求规格说明书设计规格说明书图11该图展示了需求在整个开发生命周期中所承担的角色。需求过程研究业务工作,以期设计出有助于业务工作的更加完善的产品。作为该过程的结果,需求规格说明书是对产品的功能和行为的完整的描述。系统分析得到关于产品所需的功能和数据的一个可工作的模型,将该模型作为产品的规格说明书。产品设计将来自于需求和分析的抽象规格说明转变为面向真实世界的设计。一构建完成,该产品就会投入使用,同时会不可避免地产生更多的新需求需求过程与分析活动之间有相当程度的重叠。在本书中您会发现这点。分析建模对于设定工作的范围和其他一些事来说是必要的。实际上我们利用了分析模型来描述需求过程。同时我们将使用分析模型来解释一些需求方面的概念。我们不假设您具备分析建模方面的知识,但我们也不打算完整介绍这方面的知识。伴随模型的补充说明应该足以帮助您理解这些模型当您完成了我们的需求过程,系统分析就正式开始了。您在需求过程中发现的那些功能通过建模以验证其正确性。也就是说,您通过模型展示功能与数据将正确地协同工作,并将得到客户期望的结果。大多数系统分析方法提供模型帮助您实现这个任务。旦已知功能和数据是正确的,设计师的任务就是发明一种方法让它在技术世界中实现。产品设计将需求转换为构建某种物理实现系统的计划,该物理实现系统将在真实世界中做需要做的事。设计决定了使用哪些设备,需要哪些软件组件,以及它是如何构建的。它推导出一些方法,将所需的特征转化为真实世界的制品。但是请注意,设计过程需要需求作为其输入。没有需求的设计无异于发明某物却不知道该发明是否有用。对产品的成功来说重要的是,不要在了解相关的需求之前就进行设计决策。产品构造好之后,就会投入使用,并立即开始演进。用户要求越来越多的功能,产品必须发展以满足这些要求。(还记得 Microsoft的Word曾经放在一张软盘上吗?)演进不是我们可以控制或指定的过程,而是一个我们必须接受的过程。一个产品的需求从产品被构建好那一刻第1章什么是需求起就不再是冻结的了。它们会经过一段时间的演化,任何需求过程必须考虑到这一点。1.1需求与系统分析需求收集和系统分析有一定程度的重叠—需求收集者使用分析模型来帮助发现需求,系统分析师使用需求来帮助对功能和数据的建模。在开始时,需求活动占主导地位。创建的仅有的分析模型是上下文范围图( contextdiagram),也许还有探索性的数据模型。需求收集者忙于发现业务目标、产品必须做什么、它必须具备怎样的品质、它必须满足怎样的限制条件以及必须提供怎样的外部接口。时间需求收集工作量的比例统分析图12需求收集与系统分析之间的重叠随着产品开发过程的推进而发生变化。最初,只完成少量的分析工作,大量的工作在收集和验证需求上。随着开发工作的继续,分析活动在工作中占的比例变得越来越大,直到所有需求都已知。接下来的工作就将进入系统分析。随着我们对产品了解的深入,业务事件和使用情况从模糊的意图逐渐量化,系统分析可以为它们进行更为精确的建模,并为需求过程提供有价值的反馈。类似地,对需求的了解增加也为分析过程提供反馈,使分析过程变得更有效。随着时间的推移,工作的重点逐渐转向系统分析,直到最终需求被确定下来,系统分析还将持续一段较短的时间直至我们完全理解产品。图12展示了这一点系统分析的过程通过良好的文档记录下来。有一些书介绍了这方面的内容,下面提到了两本。需求活动以前没有很好地文档化。本书阐明了一个得到正确需求的过程,随着本书的深入,我们将它逐渐展开。参考阅读Robertson, James and Suzanne. Complete Systems Analysis: the Workbook, the Textbook, theAnswers Dorset House 1994