需求分析-产出物

2020-07-01 17:55:22 浏览数 (1)

项目需求分析是一个项目的开端,也是项目建设的基石。在以往建设失败的项目中,80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一,就是对需求分析的把握程度。

  • 首先,实施顾问必须充分了解销售阶段是否有过度承诺(包括文字或签约)。
  • 其次,我们在制定实施方案时就要与客户项目负责人确认实施范围、目标、项目风险及本次实施工作的重点。

需求分析是软件计划阶段的重要活动,也是软件生存周期中的一个重要环节,该阶段是分析系统在功能上需要“实现什么”,而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理,确认后形成描述完整、清晰与规范的文档,确定软件需要实现哪些功能,完成哪些工作。此外,软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等),软件设计的约束条件,运行时与其他软件的关系等也是软件需求分析的目标。

需求管理流程:收集,分析,确认

收集

尽快熟悉项目用户方干系人全貌

有些项目在做需求调查时,由于受进度要求等客观因素影响,需求分析员与建设单位的技术部门交流较多,向业务管理部门和实际使用者调查不够深入,造成软件试用后不得不再对需求做较大调整,“从头再来”的部分比例很高,大大超过进度要求时间。因此,熟悉项目用户方干系人全貌是进行需求调查的第一步,也是需求调查的基础。在定制开发项目的项目用户方干系人中,最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构;还应当在相关单位组织结构图基础上画出全体项目用户方干系人结构图,以便更好更全面地进行需求调研分析;用责任矩阵确定各部分的调研对象;建立调研对象通讯录以保证调研及分析期间及时的沟通。

应当从项目的启动开始,需求分析员及其项目成员就要分清项目用户方干系人包含哪些人和组织,通过沟通协调对他们施加影响,驱动他们对项目的支持,调查并明确他们的需求和愿望.

项目需求具有双面性(用户与开发商)和多面性(项目中各干系人),因此,项目经理和系统集成者应了解用户干系人需求,用户干系人也应了解技术方面的需求,两者缺一不可。正确的需求获取需要了解需求的来源、用户的分类、用户的代表性、用户需求谁说了算数等因素。开发人员和项目经理要有足够的耐心聆听用户的讲述,要足够详细地了解每一个细节。项目管理者要善于将需求分类、归类,善于将需求文档化,并有所查询标记。

详细描述各项业务,以便让所有客户确认

  • 对于高层领导,可以提供系统总体框架图;
  • 对于业务管理人员,可以用业务流程图来描述新旧系统的业务流程;
  • 对于客户中的技术人员,可以用数据流图、实体关系图或UMI中的各种图形对系统进行各种角度的描述;
  • 而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户,画出用户界面图来进行需求挖掘,是个比较有效的沟通方式。

目的是消除矛盾,让需求达到完备与一致

分析

目标是给出目标系统的详细逻辑模型,也就是一个信息建模的过程,产出

  • 软件需求规格说明书 (具体分为功能性需求、非功能性需求与设计约束三个方面)
  • 数据要求说明书
  • 初步的用户手册

侧重表达理解问题的数据域和功能域。对新系统程序处理的数据,其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。

建立分析模型。模型包括各种图表,是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系,而非实现细节。由系统运行及处理环境确定物理视图,通过它确定处理功能和数据结构的实际表现形式。

对项目用户方干系人的愿望进行平衡

不同的项目用户方干系人其愿望和追求的目标往往相差甚远,因此对项目用户方干系人的愿望进行平衡可能是非常重要而又相当困难的事情。例如:某医院计算机管理系统项目中,遇到

  • 医院管理层希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析,同时为了对信息进行有效控制而增加一些审批流程;
  • 而门诊、药房等对外办公的基层窗口则因为客流速度的压力希望减少信息项的输人量;
  • 甚至有些不良的基层部门由于害怕建立透明度高的信息系统会影响他们的利益而消极地应付,即所谓反需求;
  • 而客户的客户(就诊的病人)则希望相关机构能够简化工作流程,加快办事速度,增加诊断情况和就诊费用的透明度;
  • 甚至项目组本身因为技术、资源、进度等原因,需要对一些功能进行优先级排序和取舍。

虽然不是所有人的需求都是可以满足的,特别是消极的反需求是不能接受的,但他们的需求都是应当考虑全面并进行平衡的。

如果不同的用户方干系人有不一致的需求,那么必须决策出满足哪一类用户方干系人的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何,将有助于决定哪一个用户类所占份额更大。如果系统分析人员提出的需求与开发者所想要开发的系统发生冲突时,通常由于系统分析人员作为客户的代理人,市场需求具有更重的分量,但是,系统分析人员不能一味地迁就客户需求。

  不同的用户方干系人可能都要求产品按照他们各自的喜好来设计。运用项目的业务目标来决定哪些是你最关心的客户,非核心客户的需求可以安排在下一个版本中开发。当开发者想像的产品与客户需求冲突时,通常应该由客户作出决策,然而,不要陷人“客户总是对的”的陷阱中去,现实中,客户并不总是对的。

确认

  • 提前和客户方项目负责人及提出人一起,对需求的认识达成一致;确认需求时要避免与一般业务人员交谈,因为一般业务人员可能仅仅考虑软件的实际操作或习惯问题,应该与企业的管理层沟通。

软件项目的需求管理是项目成败的关键,尤其是在强调个性化的时代,客户一贯认为软件是万能的,因此对实施顾问考验也很大,但只要能很好管理需求,赢得客户信任,就可以取得项目的成功和客户的认同。

0 人点赞