u9u8网站建设,网站开发实战 王,wordpress图片广告代码,台州自助建站系统接前一篇文章#xff1a;软考 系统分析师系列知识点之需求管理#xff08;1#xff09; 所属章节#xff1a;
第11章. 软件需求工程 第8节. 需求管理 11.8.2 需求风险管理
人们做事情总希望一帆风顺#xff0c;做项目也是如此#xff0c;总是希望项目进展顺利#xff…接前一篇文章软考 系统分析师系列知识点之需求管理1 所属章节
第11章. 软件需求工程 第8节. 需求管理 11.8.2 需求风险管理
人们做事情总希望一帆风顺做项目也是如此总是希望项目进展顺利按照计划如期交付。但现实却总是残酷的会有许多潜在威胁和阻碍项目按计划进行的因素这就是风险。风险可能会给项目成本、进度、质量和团队工作效率等方面带来负面影响。当然所谓“塞翁失马焉知非福”风险有时候也能给项目带来机会。
风险管理的目的就是希望让项目管理人员能够“掌控”风险风险事件一旦发生能够按照预先制定的应对计划有条不紊地处理风险。
1. 带有风险的做法
系统分析师在进行需求开发的过程中有时也会“陷自身于困境”无意之中给项目带来风险。这些做法列举如下
1无足够用户参与
在需求获取的过程中如果没有足够的用户参与系统分析师所获得的需求就是片面的和不完整的。这样在需求开发之初就埋下了风险。
2忽略了用户分类
用户不止一个人各类用户有其自身的特点和需求。如果系统分析师不能针对所有主要用户进行分类就必然会导致有的用户对产品感到失望。例如菜单驱动操作对高级用户来说太低效了但命令和快捷键又会使不熟练的用户感到困难。
3用户需求的不断增加
需求蔓延有可能引起项目范围蔓延而这是项目中的大忌因为它会对项目成本、进度和质量等方面带来很大的负面影响甚至直接导致项目失败。
4模棱两可的需求
模棱两可的需求会使不同的项目干系人产生不同的期望会使开发人员为错误问题而浪费大量时间。
5不必要的特性
这是技术人员的一个通病喜欢画蛇添足。经常发生的情况是用户并不认为这些添加的“足”很有用以致在其上耗费的努力白搭浪费项目资源。
6过于精简的SRS
过于精简的SRS为用户和开发人员提供了“无限遐想”的机会却给项目带来了无限的麻烦导致不断地修改项目完工遥遥无期。
7不准确的估算
系统分析师在信息不充分的情况下如果未经深思就对需求做出估算则这种估算通常只是一种猜测而已。一旦传递给用户他们却认为这是一种承诺。
2. 与需求有关的风险
项目风险管理的一个主要过程是识别风险也就是要“预知”项目进展过程中可能会发生的风险然后对其进行分析制订相应措施。根据业内人士的经验与需求有关的主要风险及其应对措施如下表所示
阶段主要风险风险应对措施需求获取产品试图与范围在项目早期写一份项目视图与范围文档将业务需求涵盖在内并将其作为新的需求及修改需求的指导需求开发所需时间记录所参与的每个项目中实际需求开发的工作量这样就能知道所花的时间是否合适并改进将来项目的工作计划忽略市场对产品的反馈信息强调市场调查研究建立原型并运用客户核心小组来获得产品的反馈信息没有非功能需求编写非功能需求文档和验收标准作为可接受的标准客户反对产品需求确定出主要的客户并采用产品代表的方法来确保客户代表的积极参与确保在需求决定权上有正确的人选期望需求尽量识别并记录用户的期望提出大量的问题来提示用户以充分表达他们的想法和建议将已有的产品作为需求基线将在逆向工程中收集的需求编写成文档并让用户评审以确保其正确性给出期望的解决办法从用户描述的解决方法中提炼出其本质需求需求分析划分需求优先级评估每项新需求的优先级并与已有的工作对比以做出相应的决策带来技术困难的特性分析每项需求的可行性以确定是否能按计划实现不熟悉的技术、工具、平台明确那些高风险的需求并留出充裕时间进行学习、实验和测试原型需求定义系统分析师和用户对于需求的不同理解使用高水平的系统分析师使用模型和原型使一些模糊的需求变得清晰时间压力对待确定因素的影响记录解决每项待确定因素的负责人的名字、如何解决的以及解决的截止日期SRS的完整性和正确定以用户的任务为中心采用用例技术获取需求根据场景写需求测试用例建立原型让用户代表对SRS和分析模型进行正式评审具有二义性的术语建立一本术语和数据字典用于定义所有的业务和技术词汇需求说明中包括了设计仔细评审SRS以确保它是在强调“做什么”而非“怎么做”需求验证未经验证的需求评审从用户代表方获得参与需求正式评审的承诺并尽早通过非正式评审审查的有效性对参与需求评审的所有人员进行培训以使评审工作更加有效需求管理需求变更将项目视图与范围文档作为变更的参照用户积极参与需求获取过程将那些易于变更的需求用多种方案实现并在设计时注意其可修改性需求变更过程建立规范的变更控制流程并严格执行未实现的需求使用需求跟踪能力矩阵或相关工具项目范围蔓延在项目早期编制视图与范围文档并得到用户确认采用迭代式开发方法
系统分析师和项目管理人员可以利用上表来识别项目中的需求风险。但要注意的是上表只是一个总结性的风险清单。具体到每一个项目可能都会有些不同需要根据实际情况进行增加或删减。在风险应对措施方面也需要根据经验和项目约束进行调整或改进。 更多内容请看下回。
