主要内容和7种方法 项目分析的步骤及注意事项( 三 )


6、分析需求可行性
没钱赚的事我们不干;有钱赚但投不起钱的事不干;有钱赚也投得起钱但没有可靠的人选 , 这样的事也不干 。可行性分析主要是针对某一需求决定是做还是不做 。一般可行性主要考虑两个方面的因素:技术和人 。技术方面主要是分析在给定的时间段内是否可实现所需的功能并满足产品的质量要求等相关指标 。很多时候 , 用户的想法在实际实施过程中是不现实的 。若一味地求全和盲目遵从用户的设想 , 将为项目的后续工作带来很大的风险 。因此应尽量避免在需求分析中包含技术实施上有难度的功能 。在曾经负责的一个项目中 , 用户要求新的管理系统应实现和管理系统的数据接口 , 以方便这些系统中的数据导人新的管理系统 。许诺提供系统的数据接口 , 将为新系统的成功实施带来很大的风险 。因为熟悉这些系统需要时间 , 开发与它们的接口也需要时间 , 而且等这些商业系统存在多个不同的版本 。因此与外部系统接口的可行性定义为:不可行 。对于复杂的项目 , 还应从经济方面和环境方面进行考虑 。经济方面主要从投入、收益、短期、长远利益等方面进行分析 。环境方面主要考虑市场环境和政策因素 。需求变更对大型IT开发项目成败有重要影响 , 既不能一概拒绝客户的变更要求 , 也不能一味地迁就客户 , 所以 , 实施需求变更之前必须做好控制 。需求变更控制的目的不是控制变更的发生 , 而是对变更进行管理 , 确保变更有序进行 。
7、确定需求的优先级别
当客户的期望很高、开发时间很短且资源有限时 , 设定需求的相对优先级将有助于项目管理人员解决冲突、安排阶段性交付并做出必要的取舍 。建立每个需求的重要性有助于规划软件的构造 , 以最少的费用提供产品的最大功能 。特别是对渐进式的项目 , 优先级的设定就显得更为重要 , 因为在这些开发中 , 项目时间安排极为紧迫并且交付日期不可改变 , 一些低优先级的需求就需要推迟到后续版本中进行实现或直接取消 。当众多用户因期望不同而就某些需求优先级的设定难以达成一致意见时 , 需求分析者可指出每一需求所需的费用、难度、技术风险或其他特定的与权衡需求有关的指标 , 来客观评价每一需求的优先级 。
8、正确理解需求分析文档确认
需求分析是一项繁琐枯燥的工作 , 需要和用户不断的商讨、确认和反复 。但大部分用户并不只做这项工作 , 特别当他被很多其他的事情缠身的时候 。在需求分析文档上签字确认 , 通常被认为是用户同意需求分析内容的标志行为 。而实际操作中 , 签字确认工作并未得到用户的充分重视 。“他们要求我在需求文档上签名 , 于是我就签了 , 否则开发人员不开始编码 。”用户的这种态度将可能给项目带来潜在的风险 , 如不断地进行需求变更等 。对于需要用户确认的需求分析文档 , 最好在用户确认前 , 就文档内容对用户进行一定的讲解 , 以确保用户完全理解并认可文档中的内容 。若用户对文档中的内容存在修改意见 , 则修改后再与用户进行确认 , 直至用户完全认可文档中的内容为止 。通常为对项目有一个整体、准确的理解 , 需求分析所包含的内容通常大于项目范围所包含的内容 。
因此 , 应让用户理解对于某些功能的讨论并不意味着即将在系统中实现它 。应使用户明白对需求分析文档的签字确认是建立一个需求的基线 , 进一步的变更可在此基线上通过项目定义的变更过程来进行 。需求确认将给初步的需求开发工作画上了双方都明确的句号 , 并有助于形成一个持续良好的用户与需求分析人员的关系 , 为项目的成功奠定坚实的基础 。将知识从一个地方传送到另一个地方并不是一件简单的事情 , 而且原始的需求通常是以不完整的形式呈现的 。它也许只是在某个现有系统的用户脑中 , 甚至有时用户都没有意识到他们知道什么 。同时需求分析工作者也应在日常工作中加强学习 , 不断总结 , 使自己的需求分析能力得到不断的提升 。软件需求管理之所以重要 , 主要是因为绝大多数项目的失败主要由需求的理解不到位、需求的变更没有得到有效控制等原因造成的 。因此 , 这就要求我们在软件项目的需求管理方面 , 要下更大的力气去做好需求的获取、分析、变更控制 , 结合项目管理的相关理论 , 如PMBOOK、CMMI等 , 在项目实践中 , 不断总结经验教训 , 做好需求管理 。


以上关于本文的内容,仅作参考!温馨提示:如遇健康、疾病相关的问题,请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容,希望对您有所帮助: