SPM软件项目需求管理.ppt

SPM软件项目需求管理.ppt

《SPM软件项目需求管理.ppt》由会员分享，可在线阅读，更多相关《SPM软件项目需求管理.ppt（82页珍藏版）》请在冰点文库上搜索。

第2章软件项目需求管理,2.1需求工程2.2需求开发2.3需求管理,2.1需求工程,2.1.1软件需求概念2.1.2软件需求层次2.1.3软件需求质量评价2.1.4需求工程发展历程2.1.5需求工程研究内容,2.1.1软件需求,IEEE软件工程标准词汇表（1997年）中将需求定义为：

1用户解决问题或达到目标所需的条件或能力；2系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力；一种反映上面

（1）或

（2）所描述的条件或能力的文档说明。

通过定义以下五项内容来确定一组完整的软件需求：

输入、输出、功能、属性、系统环境的属性,2.1.2软件需求层次,原始问题描述是对要解决的问题的叙述，它是软件需求的基础。

用户需求是用自然语言和图表给出的关于系统需要提供的服务及系统的操作约束。

系统需求用详细的术语给出系统要提供的服务及受到的约束。

系统需求文档应该是精确的，可以为系统的实现提供依据，因而系统需求文档也称为功能描述，可能成为用户和软件开发组织之间合同的重要内容。

软件设计描述是在系统需求的基础上加入更详细的内容构成的，它作为软件详细设计和实现的基础，是对软件设计活动的概要描述。

原始问题描述和用户需求能够帮助供需双方在较高的抽象层次上进行交流，便于用户和开发人员之间的理解与沟通。

系统需求和软件设计描述是具体的，可以根据它们来进行编码实现，并且二者应该是足够明确和可测试的，即应该能够对系统进行测试以确认它是否实现了需求。

软件需求各组成部分关系,业务需求（businessrequirement）用户需求（userrequirement）功能需求（functionalrequirement）非功能需求、软件需求规格说明（softwarerequirementsspecification，SRS）等。

3.1软件项目需求管理概述,用户需求,通过自然语言、图表、图形等工具描述系统的外部行为，尽量避免涉及系统内部的设计特性，以便没有专业技术背景的用户能看懂用自然语言描述用户需求可能出现的问题：

描述困难、需求混乱编写用户需求应遵守的几个原则：

标准的格式、使用一致的语言、使用特殊文本、尽量避免专业术语,系统需求,系统需求主要包括功能需求；功能需求描述系统所应该提供的功能和服务，包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。

系统做什么？

系统何时做什么？

系统何时及如何修改或升级？

系统需求还包括系统不应该做的事情。

非功能需求,领域需求,来源不是系统的用户，系统应用的领域，反映了领域的特点,几个值得重视的问题,用户或人的因素:

用户类型文档需求:

读者资源需求,软件需求类型,UP（统一过程）中，需求根据FURPS+分类Functional（功能性）Usability（可用性）Reliability（可靠性）Performance（性能）Supportability（可支持性）“+”是指一些辅助性的和次要的因素：

Implementation（实现）,2.1.3软件需求质量评价,正确性无歧义完备性一致性根据重要性和稳定性分级可验证性可修改性可跟踪性可理解性,2.1.4需求工程发展历程,需求工程是将用户非形式化需求转化为形式化需求规格说明书的过程对应用问题及其环境进行理解与分析为问题涉及的信息和功能建立模型将用户需求精确化和标准化编写需求规格说明书,2.1.4需求工程发展历程,具体需求模型【45】探讨,17,设计活动改变客观世界状态,18,将问题与解决方案分开,理解问题需求获取问题的形式化表示形式规约，形式建模就问题性质达成共识验证,冲突及矛盾消解,磋商需求管理维护双方的共识,软件需求工程的任务,已知环境E（问题领域分析），已知需求R（需求抽取，对环境的作用，客户希求的目标），构造规格说明S（可实现的）使得：

期望引入目标系统后环境将满足的约束（需求R）,规格说明S,满足规格说明S的目标系统,环境说明E,软件需求和软件规格说明分离,理解问题抽取、需求获取、等形式地描述问题规格说明、建模、等获得对问题本质的一致意见证明有效、矛盾归结、协商需求管理维护一个一致的意见,软件需求和规格说明的交织,客户需求,规格说明,需求工程发展特点,对象化【需求获取，需求对象化】形式化【提高精度】自动化,2.1.5需求工程研究内容,是用已经证实有效的技术、方法、确定客户需求，进行需求分析，帮助分析人员理解问题并定义目标系统所有外部特征的一门科学需求获取、需求分析、规格说明、需求验证【46】,24,需求工程的组成,需求管理,定义需求基线（迅速制定需求文档的主体）。

评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。

以一种可控制的方式将需求变更融入到项目中。

使当前的项目计划与需求一致。

基于估计变更需求所产生影响的基础上，协商新的承诺（约定）。

让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。

在整个项目过程中跟踪需求状态及其变更情况,26,需求开发和需求管理之间的界限,需求工程也叫做需求过程,主要责任人：

项目技术经理、项目系统组负责人或系统设计师。

项目经理的责任是关注这个阶段的过程和结果。

需求开发和管理的界限,2.2需求开发,2.2.1需求开发活动2.2.2需求获取2.2.3需求分析2.2.4编写需求文档2.2.5需求验证,2.2.1需求开发活动,确定产品所期望的用户类。

获取每个用户类的需求。

了解实际用户任务和目标以及这些任务所支持的业务需求。

分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。

将系统级的需求分为几个子系统，并将需求中的一部份分配给软件组件。

了解相关质量属性的重要性。

商讨实施优先级的划分。

将所收集的用户需求编写成规格说明和模型。

评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都要弄清楚。

2.2.2需求获取,需求获取的主要目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、系统环境等，对任务进行分析、从而开发、捕获和修订用户的需求，以建立良好的沟通渠道和方式。

建立系统模型确定系统的用户需求。

软件开发的第一步并不是跑到客户那儿做什么软件需求调查，而是先要确定客户的业务目标，再围绕业务目标分析业务的环境与内容，同时最好能查找相关业务领域的书籍资料，较为全面地认识整个业务领域。

如果原有的业务流程或组织架构等本身存在问题，这时需要先进行业务重组，重新设计与改造业务，之后才在确定业务内容的基础上展开软件需求调查，显然这样做需求获取将会顺利得多（业务流程再造）。

【优化业务流程】,2.2.2需求获取【48-49】,需求获取步骤,确定需求开发过程编写项目视图和范围文档用户群分类【客户和用户、用户群分类】选择产品代表建立核心队伍确定使用实例召开联席会议分析用户工作流程确定质量属性检查问题报告需求重用,2.2.3需求分析,绘制关联图创建用户接口原型分析可行性确定需求优先级建立需求模型编写数据字典应用质量功能调配,2.2.4编写需求文档【52-54】,2.2.4编写需求文档,软件需求规格说明,它阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。

需求分析完成的标志是提交一份完整的软件需求规格说明书（SRS）。

软件需求规格说明作为产品需求的最终成果必须包括所有的需求。

在开发人员的组织中要为编写软件需求文档定义一种标准模板。

项目经理要让所有的责任者和风险承担者【利益相关者】明白这份需求各内容的来源。

需求来源可能来自更高层的要求、业务的需要、政策法规的限定、行业或内部标准的约定、或其他外部的来源。

来源也可能来自用户或项目组的意见。

2.2.5需求验证,验证是为了确保需求说明准确、无二义性并完整地表达系统功能以及必要的质量特性。

需求验证要求客户代表和开发人员共同参与，对提交后的需求规格说明进行验证，分析需求的正确性、完整性以及可行性等。

需求验证中的活动一般包括,审查需求文档以需求为依据编写测试计划与测试用例编写用户使用手册确定合格的系统验收标准最后的签字通过需求评审,要验证的内容【对象】,“给定需求”的文档，依据规定为：

影响和决定软件项目活动的非技术需求（例如：

协议、条件和/或合同条款）。

具体实例有：

要交付的产品、交付日期、里程碑。

软件的技术需求实例有：

最终用户、操作员、支持或综合能力；性能需求；设计约束条件；程序设计语言；界面需求。

用于确认软件产品是否能满足给定需求的验收标准。

要验证的内容【属性】,良好的需求规格说明属性有效性（可使用性）：

可为产品的各阶段，特别是维护阶段，提供充分有用的信息。

一致性：

需求作为一种要求是一致的，不存在系统内相互冲突的需求要求；完整性：

需求包括功能、性能、时间响应要求、限制、接口等属性，不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求；现实性可检验性：

确认需求被按照需求规格说明实现；可跟踪性：

需求可追踪；可调节性可读性（不含糊性）：

每一个需求只有唯一的一种解释；,2.2.6案例：

某公司“船代”项目的需求开发,注意流程、内容自学,2.3需求管理,2.3.1需求管理的必要性2.3.2需求管理的困难性2.3.3需求管理的目标和原则2.3.4需求管理活动2.3.5需求变更管理2.3.6需求状态2.3.7需求文档版本控制2.3.8需求跟踪,2.3.1需求管理的必要性【需求偏差】,需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。

一种获取、组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性，以及与其它需求和其它项目工件之间的可追踪性。

需求管理对项目管理的重要性,软件开发的目标按时按预算开发出满足用户真实需要的软件。

项目需求分析是一个项目的开端，也是项目建设的基石。

软件项目中40%60%的问题都是在需求分析阶段埋下的“祸根”,项目缺陷总结,缺陷修复成本,项目风险分析,项目的风险因素：

需求分析不明确；业务流程不合理；用户不习惯,2.3.2需求管理的困难性【61】,需求不总是显而易见的，而且它可来自各个方面需求并不总是容易用文字明白无误地表达存在不同种类的需求，其详细程度各不相同如果不加以控制，需求的数量将难以管理需求相互之间以及与流程的其他可交付工件之间以多种方式相关联需求既非同等重要，处理的难度也不同需求涉及众多相关利益责任方需求会发生变更,2.3.3需求管理的目标和原则,目标：

使软件需求受控，并建立供软件工程和管理使用的基线；供产品计划、产品活动与软件需求保持一致,2.3.3需求管理的目标和原则,需求管理的原则：

分类分优先级文档化一旦变化，需评价对需求变更的影响需求管理必须需求工程的其他活动紧密整合,需求管理策略【62-63】,一定要与投入有必然的联系需求的变更要经过出资者的认可小的需求变更也需要经过正规的需求管理流程精确的需求与范围定义并不会阻止需求的变更,2.3.4需求管理活动,需求管理活动【64】,确定需求变更控制过程建立委员会决定目标的优先顺序进行需求变更影响分析跟踪所有受需求变更影响的工作产品定义需求基准版本和控制版本维护变更的历史跟踪每项需求的状态及其变更情况。

衡量需求稳定性,2.3.5需求变更管理,需求变更的原因：

不理解、不完备因竞争、成本等因素，工期已经确定且极不合理：

用户在需求期提不出需求、或用户的需求不明确：

项目组对业务不熟悉、或者没有与用户密切结合、需求分析工作不细致：

项目组没有很好地实施需求管理,识别问题和分析影响的元素,输入界面、报表等输出界面；内部接口、外部接口；数据库表结构；系统常量、宏定义、已经实现的代码；已经完成的单元、集成测试；公用模块定义、公用子程序库、控件库、第三方软件和工具；已经编写完成的用户文档（使用手册、维护手册）；已经编写完成的帮助文件、培训教材；,需求变更的代价,需求变更控制流程,需求状态的变迁,2.3.6需求状态,2.3.7需求文档版本控制【70】,简单地说，就是保证项目干系人最新版本的需求文档和记录需求的全部历史版本,2.3.8需求跟踪,书中所说的“上步与下步”误解【71】通过跟踪定义了的需求，我们就能够知道需求在实现过程中的具体实现细节与目标的距离。

在可追踪的需求实现过程中，项目经理才能够有把握地说，需求被正确地实现了。

需求跟踪有正向跟踪与逆向跟踪两种方式。

正向跟踪以用户需求为切入点，检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。

逆向工作检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处,需求跟踪的双向模式可以通过需求链来表示。

需求链指的是需求能够上传下达，从客户需求传达到需求过程，并从需求过程传达到需求过程的后继开发链，且可以逆向传达。

实现需求跟踪,实现需求跟踪的一种通用方法是采用需求跟踪矩阵其前提条件是标识需求链中各个过程的元素，如需求的实例号、设计的实例号、编码的实例号、测试的实例号。

通过标识的符号，就可以使用数据库进行管理，需求的变化能够立刻体现在整条需求链的变化上。

需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。

因而使用需求跟踪矩阵很容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差。

但是，需求跟踪矩阵并没有规定的实现办法，只要能保证需求链的一致性和可跟踪性就可以了。

案例自学,2.3.9案例：

需求变更的代价2.4案例故事解析2.4.1需求开发的注意事项2.4.2需求管理的注意事项,作业2,请分析需求开发活动。

请分析需求管理活动。