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


4 。正确分类用户
组织中的用户之间存在许多差异,如使用系统的频率和程度、计算机系统知识、业务流程以及个人素质和偏好 。根据用户的特点,可以对用户进行一定程度的分类 。对用户进行分类并总结他们各自的特点,详细描述他们的个性特征和任务状态,将有助于需求的获取和分析 。不同的问题需要由不同的人来问 。对于运营的细节,要和实际负责运营的用户沟通,对于关系全局的问题,要和相应的管理用户沟通 。
5 。现场了解用户工作流程
现场观察用户执行业务任务的过程 。了解用户什么时候获取什么数据,如何使用数据,业务处理时需要处理哪些单据,用户需要关联哪些角色 。这将有助于阐明产品的功能需求 。经验证明,面试人如何完成任务有很多局限和不准确的地方,可以通过任务观察直接解决 。尤其是对于一些组织普遍接受的规则和方法,当用户认为你理所当然应该知道,而没有提及的时候 。在用户需求被确认之后,用户需求被逐项列出,每个需求被形成一个需求开发任务 。借助软件项目管理平台,直接推送给需求分析师,需求分析师的分析结果可以通过平台导出成格式化的需求规格说明书 。一旦需求说明书编写任务完成,管理平台直接将需求评审任务推送给相关人员 。设计、编码和测试等后续任务以类似的方式集成到流程中 。
6 。分析需求可行性
没有钱我们什么都不会做;不要做赚钱但买不起的事情;如果你赚了钱,你有能力投钱,但是没有一个可靠的候选人,你不会做这样的事情 。可行性分析主要是根据某种需求来决定做与不做 。一般可行性主要考虑两个因素:技术和人 。技术方面主要分析在给定的时间内能否实现所需的功能,能否满足产品的质量要求 。很多时候,用户的想法在实际执行过程中是不切实际的 。如果一味的追求完美,一味的跟随用户的假设,会给项目的后续工作带来很大的风险 。所以在需求分析中要尽量避免将技术实现上的困难功能包含在内 。曾经负责一个项目,用户要求新的管理系统实现和管理系统的数据接口,以便于这些系统中的数据通向新的管理系统 。承诺提供系统的数据接口会给新系统的成功实施带来很大的风险 。因为熟悉这些系统需要时间,开发与之接口也需要时间,而且这些商业系统有很多不同的版本 。因此,与外部系统接口的可行性被定义为不可行 。对于复杂的项目,我们还应该考虑经济和环境方面 。经济主要从投入、收益、短期和长期效益等方面进行分析 。环境主要考虑市场环境和政策因素 。需求变化对大型IT开发项目的成败有着重要的影响 。我们既不能完全拒绝客户的变革需求,也不能一味迁就客户 。所以在实施需求变更之前一定要做好控制 。需求控制的目的不是控制变更的发生,而是管理变更以保证变更的有序进行 。
7 。确定需求的优先级
当客户的期望很高,开发时间很短,资源有限时,设置需求的相对优先级将有助于项目经理解决冲突,安排分阶段交付,并进行必要的权衡 。确立每个需求的重要性有助于规划软件的结构,并以最小的成本提供产品的最大功能 。特别是对于渐进式的项目,优先级的设置更为重要,因为在这些开发中,项目进度极其紧张,交付日期无法更改,一些低优先级的需求需要推迟到后续版本中实现或者直接取消 。当多个用户因公众期望不同而难以就某些需求的优先级设置达成共识时,需求分析师可以针对每个需求指出成本、难度、技术风险或其他与权衡需求相关的具体指标,以客观评价每个需求的优先级 。
8 。正确理解需求分析文档确认
需求分析是一项繁琐枯燥的工作,需要不断的和用户讨论、确认、重复 。但是大多数用户并不只是做这份工作,尤其是当他们痴迷于许多其他事情的时候 。在需求分析文档上签字确认通常被认为是用户同意需求分析内容的标志 。然而,在实践中,签名确认工作并没有得到用户的足够重视 。“他们让我签需求文档,我就签了,不然开发人员就不开始编码了 。”用户的这种态度可能会给项目带来潜在的风险,比如不断变化的需求 。对于需要用户确认的需求分析文档,最好在用户确认之前向用户说明文档的内容,以保证用户完全理解并认可文档中的内容 。如果用户对文档中的内容有修改意见,修改后与用户确认,直到用户完全认可文档中的内容 。通常情况下,为了对项目有一个整体的、准确的了解,需求分析所包含的内容通常要大于项目范围所包含的内容 。


推荐阅读