需求分析与解决方案设计1PPT课件下载推荐.ppt

需求分析与解决方案设计1PPT课件下载推荐.ppt

《需求分析与解决方案设计1PPT课件下载推荐.ppt》由会员分享，可在线阅读，更多相关《需求分析与解决方案设计1PPT课件下载推荐.ppt（33页珍藏版）》请在冰豆网上搜索。

项目经理：

制定项目计划并带领开发人员获得成功。

法律人员：

确保产品符合所有相关法规。

生产人员：

制造包含该软件的产品。

市场营销:

技术支持及其他与产品和客户打交道的人员。

本章将帮助您：

理解软件需求工程的一些重要术语。

区分需求开发与需求管理。

保持对潜在的与需求相关的问题的警觉性。

了解完善的需求应该具备的特征。

软件或系统项目涉众（stakeholder，产品或项目相关人员）的利益之间的相互作用在需求过程中表现得最为强烈。

项目涉众包括：

31.1软件需求的定义4软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。

4对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。

4客户对需求的定义，在开发人员看来可能只是高级别的产品概念；

而开发人员的需求概念对用户来说也许就是详细的用户界面设计。

4需求必须被记录成文档，这一点很重要。

41.1.1对需求的不同解释4IEEE的软件工程标准术语表将需求定义为:

用户为解决某个问题或达到某个目标而需具备的条件或能力。

系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。

上述第一项或第二项中定义的条件和能力的文档表达。

注意:

不要一厢情愿地认为项目涉众对需求的理解是一致的。

应该事先给出定义，才能保证大家谈论的是同一个问题。

5需求分析定义4需求分析是指理解用户需求，就软件功能与客户达成一致，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化、最终形成需求规格说明的一个复杂过程。

从广义上理解：

需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解：

需求分析指需求的分析、定义过程。

61.1.2需求的层次4软件需求包括3个不同的层次业务需求、用户需求和功能需求:

4除此之外，每个系统还有各种非功能需求。

图1.1中的模型给出了各种需求关系的示意图。

业务需求（Businessrequirement）表示组织或客户高层次的目标。

用户需求（userrequirement）描述的是用户的目标，或用户要求系统必须能完成的任务。

功能需求（funetionalrequirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。

图1.171.1.3不属于需求的内容4需求规格说明中不包括（除已知约束外的）设计和实现的细节、项目的计划信息，以及测试信息。

4项目中通常还包括其他类型的需求，如开发环境需求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的需求。

这些都属于项目需求而不是产品需求。

81.2需求的开发与管理4需求领域的术语问题，有的作者称其为需求工程；

也有人称之为需求管理。

把软件需求工程划分为需求开发和需求管理，如图1.2所示。

图1.2软件需求工程的组成91.2.1需求开发4需求开发可进一步细分为获取（Elicitation）、分析（analysis）、规格说明（specification）和确认（Validation）。

4这些子学科涵盖了为软件和软件相关产品收集、评估和记录需求相关的所有活动，包括：

确定产品将要面对的各类用户。

从各类用户的代表处收集需求。

了解用户的任务和目标，以及这些任务要实现的业务目标。

分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来。

将顶层的需求分配到系统构架内定义好的软件组件中。

了解各质量属性的相对重要性。

协商需求的实现优先级。

将收集的用户需求表述为书面的需求规格说明和模型。

审阅需求文档，以确保在认识上与用户声明的需求相一致。

应在开发小组接受需求之前解决所有分岐。

101.2.2需求管理4需求管理的任务是“与客户就软件项目的需求达成并保持一致”。

4需求管理包括下列活动：

定义需求基线（某一时刻，对特定版本中已达成一致的需求内容的描述）。

审查需求变更请求，评估其可能产生的影响以决定是否批准。

以可控的方式将批准的需求变更融入项目中。

保持项目计划与需求的同步。

估计需求变更的影响，在此基础上协商新的需求约定。

跟踪每项需求，找到与其对应的设计、源代码和测试用例（testcase）。

在项目开发过程中，始终跟踪需求的状态和变更。

111.2.2需求管理4图1.3从另一个角度反映了需求开发与需求管理间的区别。

12本次课结束思考题1.什么是需求分析？

2.软件需求的参与人员有哪些？

3.为什么要需求分析？

131.3所有项目都有需求4需求在软件项目中的重要地位：

软件系统开发过程中最难的部分是对要开发什么作出准确的判断。

所有概念性工作中最难的是建立详细的技术需求，包括所有与用户、机器和其他软件系统的接口。

4在开始开发软件之前，往往无法确定所有的需求。

这种情况下，可以采用迭代和增量方法，每次实现一部分需求，得到用户反馈后再进入下一循环。

141.4优秀的团队遇到糟糕的需求4需求问题导致的主要后果是返工重复做您认为早已做好的事情。

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

4从图1.4可以看出，在项目末期才发现缺陷，对其进行改正的成本要比在缺陷刚产生不久时修改的成本高得多。

图1.4151.4.1用户参与不足4开发人员往往也不重视用户的参与，原因是他们认为与用户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。

4用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。

4在整个项目开发过程中，开发团队必须始终与实际用户直接合作，这种合作非常必要而且不可替代。

161.4.2用户需求扩展4由于开发过程中需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。

4出现这种情况是因为没有依据对需求的规模和复杂度的实际评估来制订计划，而不断修改需求又使情况变得更糟。

4问题的责任部分在于用户不断提出修改需求的要求，部分在于开发人员处理这种要求的方式。

4要控制项目范围的改变：

首先应明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。

然后参考这一框架对所有新特性和需求变更进行评估。

171.4.3有岐义的需求4岐义表现为同一读者可以对一项需求声明作出多种解释，或者不同的读者对同一需求产生不同的理解。

4岐义会导致以下几点：

涉众对产品怀有不同的期望。

因此最终交付的产品会让部分人感到意外。

有岐义的需求使开发人员的时间浪费在解决无需解决的问题上。

有岐义的需求导致测试人员与开发人员对产品功能的理解不同，从而使测试人员也要浪费时间来解决这些差异。

4消除歧义的办法之一是让代表不同观点的人对需求作正式的检查。

181.4.4镀金问题4开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。

这就是所谓的“镀金问题（goldplating）”。

4开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。

4要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。

191.4.5过于抽象的需求营销人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。

这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统。

大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。

201.4.6忽略了某类用户4用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。

4因此，多数产品都拥有不同的用户群。

如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。

确定所有用户群后，还要保证获得各类用户的需求。

211.4.7不准确的计划4不能充分理解需求，就会作出过于乐观的估计，最终不可避免地陷入超支的泥潭。

4造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确，以及对需求的分析不透彻等。

221.5优质需求过程的好处4实现有效的需求工程过程可以让组织受益匪浅。

减少开发后期以及整个维护过程中不必要的返工，可带来极大的回报。

4下面列出的好处并不能完全量化，但确实存在：

减少需求缺陷减少开发过程中的返工减少不必要的特性降低改进成本加快开发进度提高沟通效率控制需求范围的改变项目更有序对系统测试的评估更准确提高客户和开发人员的满意度231.6优秀需求的特点4如何才能将好的需求规格说明与那些有问题的区分开来？

4这一节首先对说明中的单条需求（即需求陈述）特点进行讨论，然后将介绍SRS（需求规格说明）作为整体应具备的特点。

4如果想知道您的需求是否具备这些特点，最好的办法就是请几位项目相关人员仔细审阅您的SRS。

不同的人会发现不同的问题。

例如，需求分析人员和开发人员无法准确判断完备性和正确性，而用户则无法评价技术可行性。

241.6.1需求陈述的特点4每一项用户需求、业务需求和功能需求都应具备下列性质。

完整性|每一项需求都必须完整地描述即将交付使用的功能。

每一项需求都必须完整地描述即将交付使用的功能。

正确性|每一项需求都必须准确地描述将要开发的功能。

每一项需求都必须准确地描述将要开发的功能。

可行性|需求必须能够在系统及其运行环境的已知能力和约束条件内实现。

需求必须能够在系统及其运行环境的已知能力和约束条件内实现。

必要性|每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。

需求或某一标准而必须具备的功能。

有优先次序|为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。

某一版本中的重要程度。

无歧义|一项需求声明对所有读者应该只有一种一致的解释，然而自然语言却极易一项需求声明对所有读者应该只有一种一致的解释，然而自然语言却极易产生歧义。

产生歧义。

可验证性|看看您能否设计一些测试方法或使用其他验证方法，如检查或演示来判断看看您能否设计一些测试方法或使用其他验证方法，如检查或演示来判断产品是否正确实现了需求。

产品是否正确实现了需求。

251.6.2需求规格说明的特点4需求规格说明中所包含的整体需求集还必须具备下列特性。

完整性|不能遗漏任何需求或必要的信息。

不能遗漏任何需求或必要的信息。

|需求遗漏问题很难被发现，因为它们并没有列出来。

需求遗漏问题很难被发现，因为它们并没有列出来。

一致性|需求的一致性是指需求不会与同一类型的其他需求或更高层次的业务、需求的一致性是指需求不会与同一类型的其他需求或更高层次的业务、系统或用户需求发生冲突。

系统或用户需求发生冲突。

|必须在开发前解决需求不一致的问题。

必须在开发前解决需求不一致的问题。

可修改性|必须能够对必须能够对SRS作必要的修订，并可以为每项需求维护修改的历史记作必要的修订，并可以为每项需求维护修改的历史记录。

录。

可跟踪性|需求如果是可跟踪的，就能找到它的来源、它对应的设计单元、实现需求如果是可跟踪的，就能找到它的来源、它对应的设计单元、实现它的源代码以及用于验证其是否被正确实现的测试用例。

它的源代码以及用于验证其是否被正确实现的测试用例。

261.7需求分析的任务、过程和方法需求分析的任务、过程和方法1.7.1需求分析的任务需求分析的任务4简言之,需求分析的任务就是解决“做什么”的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需