SPM软件项目需求管理PPT文档格式.ppt
- 文档编号:15559026
- 上传时间:2022-11-05
- 格式:PPT
- 页数:82
- 大小:1.79MB
SPM软件项目需求管理PPT文档格式.ppt
《SPM软件项目需求管理PPT文档格式.ppt》由会员分享,可在线阅读,更多相关《SPM软件项目需求管理PPT文档格式.ppt(82页珍藏版)》请在冰豆网上搜索。
功能需求描述系统所应该提供的功能和服务,包括系统应该提供的服务、对输入如何响应及特定条件下系统行为的描述。
系统做什么?
系统何时做什么?
系统何时及如何修改或升级?
系统需求还包括系统不应该做的事情系统不应该做的事情。
非功能需求领域需求n来源不是系统的用户,n系统应用的领域,反映了领域的特点几个值得重视的问题n用户或人的因素:
用户类型n文档需求:
读者n资源需求2.1.3软件需求质量评价n正确性n无歧义n完备性n一致性n根据重要性和稳定性分级n可验证性n可修改性n可跟踪性n可理解性2.1.4需求工程发展历程n需求工程是将用户非形式化需求转化为形式化需求规格说明书的过程1.对应用问题及其环境进行理解与分析2.为问题涉及的信息和功能建立模型3.将用户需求精确化和标准化4.编写需求规格说明书5.2.1.4需求工程发展历程需求工程发展特点n对象化【需求获取,需求对象化】n形式化【提高精度】n自动化2.1.5需求工程研究内容n是用已经证实有效的技术、方法、确定客户需求,进行需求分析,帮助分析人员理解问题并定义目标系统所有外部特征的一门科学n需求获取、需求分析、规格说明、需求验证【46】24需求工程的组成26需求开发和需求管理之间的界限需求开发和管理的界限2.2需求开发2.2.1需求开发活动2.2.2需求获取2.2.3需求分析2.2.4编写需求文档2.2.5需求验证2.2.1需求开发活动n确定产品所期望的用户类。
n获取每个用户类的需求。
n了解实际用户任务和目标以及这些任务所支持的业务需求。
n分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。
n将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件。
n了解相关质量属性的重要性。
n商讨实施优先级的划分。
n将所收集的用户需求编写成规格说明和模型。
n评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都要弄清楚。
2.2.2需求获取n需求获取的主要目的是从宏观上把握用户的具体需求方向和趋势,了解现有的组织架构、业务流程、系统环境等,对任务进行分析、从而开发、捕获和修订用户的需求,以建立良好的沟通渠道和方式。
建立系统模型确定系统的用户需求。
n软件开发的第一步并不是跑到客户那儿做什么软件需求调查,而是先要确定客户的业务目标,再围绕业务目标分析业务的环境与内容,同时最好能查找相关业务领域的书籍资料,较为全面地认识整个业务领域。
n如果原有的业务流程或组织架构等本身存在问题,这时需要先进行业务重组,重新设计与改造业务,之后才在确定业务内容的基础上展开软件需求调查,显然这样做需求获取将会顺利得多(业务流程再造)。
【优化业务流程】2.2.2需求获取【48-49】需求获取步骤1.确定需求开发过程2.编写项目视图和范围文档3.用户群分类【客户和用户、用户群分类】4.选择产品代表5.建立核心队伍6.确定使用实例7.召开联席会议8.分析用户工作流程9.确定质量属性10.检查问题报告11.需求重用2.2.3需求分析n绘制关联图n创建用户接口原型n分析可行性n确定需求优先级n建立需求模型n编写数据字典n应用质量功能调配2.2.4编写需求文档【52-54】2.2.4编写需求文档使用对象需求文档的作用软件项目客户了解软件项目能够提供的软件产品,检查软件需求是否满足需要项目管理人员根据需求文档制定项目的开发计划和软件过程,初步预测资源的使用软件开发人员理解要开发的产品及具体要开发的内容软件测试人员验证软件系统是否满足了预期的要求软件维护人员使用需求文档帮助理解软件系统内在的逻辑关系软件发布人员在需求文档的基础上编写用户文档,如用户手册软件需求规格说明nn它阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础,也是所有子系列项目规划、设计和编码的基础。
nn需求分析完成的标志是提交一份完整的软件需求规格说明书(SRS)。
nn软件需求规格说明作为产品需求的最终成果必须包括所有的需求。
nn在开发人员的组织中要为编写软件需求文档定义一种标准模板。
n项目经理要让所有的责任者和风险承担者【利益相关者】明白这份需求各内容的来源。
n需求来源可能来自更高层的要求、业务的需要、政策法规的限定、行业或内部标准的约定、或其他外部的来源。
来源也可能来自用户或项目组的意见。
2.2.5需求验证n验证是为了确保需求说明准确、无二义性并完整地表达系统功能以及必要的质量特性。
n需求验证要求客户代表和开发人员共同参与,对提交后的需求规格说明进行验证,分析需求的正确性、完整性以及可行性等。
需求验证中的活动一般包括1.审查需求文档2.以需求为依据编写测试计划与测试用例3.编写用户使用手册4.确定合格的系统验收标准5.最后的签字通过需求评审要验证的内容【对象】n“给定需求”的文档,依据规定为:
1.影响和决定软件项目活动的非技术需求(例如:
协议、条件和/或合同条款)。
具体实例有:
要交付的产品、交付日期、里程碑。
2.软件的技术需求实例有:
最终用户、操作员、支持或综合能力;
性能需求;
设计约束条件;
程序设计语言;
界面需求。
3.用于确认软件产品是否能满足给定需求的验收标准。
要验证的内容【属性】n良好的需求规格说明属性n有效性(可使用性):
可为产品的各阶段,特别是维护阶段,提供充分有用的信息。
n一致性:
需求作为一种要求是一致的,不存在系统内相互冲突的需求要求;
n完整性:
需求包括功能、性能、时间响应要求、限制、接口等属性,不存在没有界定的、以为是隐含或默认而实际存在认知差异的需求;
n现实性n可检验性:
确认需求被按照需求规格说明实现;
n可跟踪性:
需求可追踪;
n可调节性n可读性(不含糊性):
每一个需求只有唯一的一种解释;
2.2.6案例:
某公司“船代”项目的需求开发n注意流程、内容n自学2.3需求管理n2.3.1需求管理的必要性n2.3.2需求管理的困难性n2.3.3需求管理的目标和原则n2.3.4需求管理活动n2.3.5需求变更管理n2.3.6需求状态n2.3.7需求文档版本控制n2.3.8需求跟踪2.3.1需求管理的必要性【需求偏差】客户如此描述需求客户如此描述需求项目经理如此理解项目经理如此理解分析员如此设计分析员如此设计程序员如此编码程序员如此编码商业顾问如此解释商业顾问如此解释项目文档如此编写项目文档如此编写安装程序如此简洁安装程序如此简洁客户投资如此巨大客户投资如此巨大技术支持如此肤浅技术支持如此肤浅实际需求原来如此实际需求原来如此n需求管理是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法,可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。
n一种获取、组织并记录系统需求的系统化方案,一种获取、组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
需求达成并保持一致的过程。
n有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性,以及与其它需求和其它项目工件之间的可追踪性。
需求管理对项目管理的重要性n软件开发的目标按时按预算开发出满足用户真实需要的软件。
n项目需求分析是一个项目的开端,也是项目建设的基石。
n软件项目中40%60%的问题都是在需求分析阶段埋下的“祸根”项目缺陷总结缺陷修复成本项目风险分析项目的风险因素:
需求分析不明确;
业务流程不合理;
用户不习惯2.3.2需求管理的困难性【61】n需求不总是显而易见的,而且它可来自各个方面n需求并不总是容易用文字明白无误地表达n存在不同种类的需求,其详细程度各不相同n如果不加以控制,需求的数量将难以管理n需求相互之间以及与流程的其他可交付工件之间以多种方式相关联n需求既非同等重要,处理的难度也不同n需求涉及众多相关利益责任方n需求会发生变更2.3.3需求管理的目标和原则n目标:
1.使软件需求受控,并建立供软件工程和管理使用的基线;
2.供产品计划、产品活动与软件需求保持一致2.3.3需求管理的目标和原则需求管理的目标和原则需求管理的原则:
1.分类2.分优先级3.文档化4.一旦变化,需评价对需求变更的影响5.需求管理必须需求工程的其他活动紧密整合需求管理策略【62-63】1.一定要与投入有必然的联系2.需求的变更要经过出资者的认可3.小的需求变更也需要经过正规的需求管理流程4.精确的需求与范围定义并不会阻止需求的变更2.3.4需求管理活动需求管理活动【64】1.确定需求变更控制过程2.建立委员会决定目标的优先顺序3.进行需求变更影响分析4.跟踪所有受需求变更影响的工作产品5.定义需求基准版本和控制版本6.维护变更的历史7.跟踪每项需求的状态及其变更情况。
8.衡量需求稳定性2.3.5需求变更管理n需求变更的原因:
不理解、不完备1.因竞争、成本等因素,工期已经确定且极不合理:
2.用户在需求期提不出需求、或用户的需求不明确:
3.项目组对业务不熟悉、或者没有与用户密切结合、需求分析工作不细致:
4.项目组没有很好地实施需求管理需求变更的代价需求变更控制流程需求状态的变迁2.3.6需求状态状态2.3.7需求文档版本控制【70】n简单地说,就是保证项目干系人最新版本的需求文档和记录需求的全部历史版本2.3.8需求跟踪n书中所说的“上步与下步”误解【71】n通过跟踪定义了的需求,我们就能够知道需求在实现过程中的具体实现细节与目标的距离。
在可追踪的需求实现过程中,项目经理才能够有把握地说,需求被正确地实现了。
n需求跟踪有正向跟踪与逆向跟踪两种方式。
n正向跟踪以用户需求为切入点,检查用户需求说明书或需求规格说明中的每个需求是否都能在后继工作产品中找到对应点。
n逆向工作检查设计文档、代码、测试用例等工作产品是否都能在需求规格说明中找到出处n需求跟踪的双向模式可以通过需求链来表示。
n需求链指的是需求能够上传下达,从客户需求传达到需求过程,并从需求过程传达到需求过程的后继开发链,且可以逆向传达。
实现需求跟踪n实现需求跟踪的一种通用方法是采用需求跟踪矩阵n其前提条件是标识需求链中各个过程的元素,如需求的实例号、设计的实例号、编码的实例号、测试的实例号。
通过标识的符号,就可以使用数据库进行管理,需求的变化能够立刻体现在整条需求链的变化上。
n需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。
因而使用需求跟踪矩阵很容易发现需求与后续工作产品之间的不一致,有助于开发人员及时纠正偏差。
n但是,需求跟踪矩阵
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SPM 软件 项目 需求 管理