当前位置:文档之家› 项目管理之需求分析

项目管理之需求分析


6
开发人员对需求及产品实施提出建议和解决方案
•通常客户所说的‚需求‛已经是一种实际可行的实施方案,分析人员应 尽力从这些解决方法中了解真正的业务需求,同时还应找出已有系统与 当前业务不符之处,以确保产品不会无效或低效;分析人员应提出相当 好的改进方法,有经验且有创造力的分析人员还能提出增加一些用户没 有发现的很有价值的系统特性。
1 分析人员要使用符合客户语言习惯的表达
•需求讨论集中于业务需求和任务,因此要使用术语。客户应将有关术语 解释给分析人员,而客户不一定要懂得计算机行业的术语。
2 分析人员要了解客户的业务及目标
•为帮助开发和分析人员,客户可以考虑邀请他们观察自己的工作流程。 如果是切换新系统,那么开发和分析人员应使用一下目前的旧系统,有 利于他们明白目前系统是怎样工作的,其流程情况以及可供改进之处。
No. 7
C
ontent
I. II. III.
什么是需求 如何寻找需求 分析需求的难点
IV.
V. VI.
需求分析20条准则
需求确认 案例讨论
No. 8
如何寻找客户的需求
如果你赞成客户的参与是发布一个优秀软件的关键因素,在项目的开 始阶段就会努力致力于为你的项目征求各个客户的意见。为了征求客 户的意见,必须采取以下几步:
需求分析报告——报告所说明的功能需求充分描述了系统所应具有的 外部行为。‚需求分析报告‛在开发、测试、质量保证、项目管理以及相 关项目功能中起着重要作用。
No. 6
什么是好需求
需求要从客户的角度去寻找 需求是客户要求的抽象,而不是具体的表现,这样做的需 求才能对以后的设计产生积极的影响。而一些具体的要求 可能都是易变的,这些可能是商业政策,而不是真正的需 求。 需求总是易变的 这就要求架构要有灵活性,灵活性不是靠提前设计实现 ‚你认为将来会有的需求‛,而是靠抽象,这样可以在需 求变化时,架构做最少的修改。 从开发者角度说,需求是架构必须要实现的要求 要把抽象的需求再扩展到具体。这样需求就经历了从具体 (客户的描绘)到抽象(架构,好的需求)再到具体(实 现)的一个过程都是自己的理解。
No. 12
项目需求分析难在哪里
有几种原因使需求分析变得困难: 分析人员或客户理解有误 有个外星人间谍潜伏到地球刺探情报,它给上司写了一份 报告:‚主宰地球的是车。它们喝汽油,靠四个轮子滚动 前进。嗓门极大,在夜里双眼能射出强光。……有趣的是, 车里住着一种叫作‘人’的寄生虫,这些寄生虫完全控制 了车。‛ 网站需求分析人员不可能都是全才。客户表达的需求,不 同的分析人员可能有不同的理解。如果分析人员理解错了, 可能会导致开发人员白干活,吃力不讨好。所以分析人员 写好需求说明书后,要请客户方的各个代表验证。 由于客户大多不懂网站建设,他们可能觉得网站是万能的, 会提出一些无法实现的需求。有时客户还会把需求分析人 员的建议或答复给想歪了。 有一个软件人员滔滔不绝地向客户讲解在‚信息高速公路 上做广告‛的种种好处,客户听得津津有味。最后,心动 的客户对软件人员说:‚好得很,就让我们马上行动起来 吧。请您决定广告牌的尺寸和放在哪条高速公路上,我立 即派人去做。‛
4 要求得到需求工作结果的解释说明
•分析人员可能采用了多种图表作为文字性‚需求分析报告‛的补充说明, 因为工作图表能很清晰地描述出系统行为的某些方面;客户可能对此并 不熟悉,因此客户可以要求分析人员解释说明每个图表的作用、符号的 意义和需求开发工作的结果
5
开发人员要尊重客户的意见
•如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍。 共同合作能使大家‚兼听则明‛。参与需求开发过程的客户有权要求开 发人员尊重他们并珍惜他们为项目成功所付出的时间,同样,客户也应 对开发人员为项目成功这一共同目标所做出的努力表示尊重。
No. 5
需求内容
功能需求——定义了开发人员必须实现的系统功能,使用户利用系统 能够完成他们的任务,从而满足了业务需求。 例如:系统需要具有网站统计分析功能,需要统计出每日,每月,每 年的点击量,PV值,用户来源。 非功能性的需求——描述了系统展现给用户的行为和执行的操作等, 它包括系统必须遵从的标准、规范和约束,操作界面的具体细节和构造上 的限制。 例如:系统是按照W3C标准进行开发制作;首页BANNER区以FLASH 形式展现;首页新闻区域采用JAVASCRIPT效果以标签形式展现。
明确项目用户需求的来源 —访问并与有潜力的用户探讨
—把对目前的或竞争产品的描述写成文档 —系统需求规格说明 —对当前系统的问题报告和增强要求指导用户和提供技术支持 的工作人员是最有价值的需求来源 —市场调查和用户问卷调查 —用户任务的内容分析
明确使用该产品的不同类型的用户 与产品不同用户类的代表进行沟通 遵从项目的最终决策者的意见
3 分析人员必须编写软件需求报告
•分析人员应将从客户那里获得的所有信息进行整理,以区分业务需求及 规范、功能需求、质量目标、解决方法和其他信息。‚需求分析报告‛, 使开发人员和客户之间针对要开发的产品内容达成协议。客户要评审此 报告,以确保报告内容准确完整地表达其需求。
No. 15
项目需求分析20条法则
如果都没有做好,象这个项目一样, 就只能有两种选择: 尽早重来;下一 个版本重新开始
好的需求,会加快项目的进度,也可以给开发人员的设计提供帮助。 项目开始前一定要做好需求和设计,至少要有明确的思路,匆忙开始的项目很可能 会失败,至少也会走弯路,而走弯路花的时间很可能会超过在需求和设计上省下来 的时间,更不用说失败的项目所造成的后果。
No. 9
C
ontent
I. II. III.
什么是需求 如何寻找需求 分析需求的难点
IV.
V. VI.
需求分析20条准则
需求确认 案例讨论
No. 10
项目需求分析难在哪里
有几种原因使需求分析变得困难: 客户说不清楚需求 有些客户对需求只有朦胧的感觉,当然说不清楚具体的需 求。例如全国各地的很多政府机构在搞网络建设,这些单 位的领导和办公人员大多不清楚计算机网络有什么用,反 而要系统分析人员替他们设想需求。 有些客户心里非常清楚想要什么,但却说不明白。 如果客户本身就懂开发,能把需求说得清清楚楚,这样的 需求分析将会非常轻松、愉快。如果客户全不懂开发,但 信任开发方,事情也比较简单。分析人员可以引导客户, 先阐述常规的需求,再由客户否定不需要的,最终确定客 户真正的需求。最怕的就是‚不懂装懂‛或者‚半懂充内 行‛的客户,他们会提出不切实际的需求。如果这些客户 甚至觉得自己是上帝的爸爸,那么沟通和协商都会很困难。
No. 3
从一个典型的失败项目说起——需求和功能设计
以上示例失败的原因
需求分析不到位、架构设计不合理
Do 需求分析做的好 架构设计合理 灵活的适应变化的需求 Don’t 需求分析做的好,架构设计不合理,项 目也可以实现,只是以后的维护会 有困难 架构好了,需求没有做好,随着需 求的进一步完善,项目也会完成
8
以已有的模块进行需求示例
•需求通常有一定灵活性,分析人员可能发现已有的某个模块与客户描述 的需求很相符,在这种情况下,分析人员应提供一些修改需求的选择以 便开发人员能够降低新系统的开发成本和节省时间,而不必严格按原有 的需求说明开发。所以说,如果想在产品中使用一些已有的常用模块, 而它们并不完全适合您所需的特性,这时一定程度上的需求灵活性就显 得极为重要了。
No. 18
项目需求分析20条法则
12 抽出时间清楚地说明并完善需求
•客户很忙,但无论如何客户有必要抽出时间参与‚头脑高峰会议‛的讨 论,接受采访或其他获取需求的活动。有些分析人员可能先明白了客户 的观点,而过后发现还需要客户的讲解,这时请耐心对待一些需求和需 求的精化工作过程中的反复。
13

准确而详细地说明需求
No. 4
需求内容
业务需求——反映了组织机构或客户对网站、产品高层次的目标要求, 通常在项目定义与范围文档中予以说明。 例如:电子商务网站中,关于客户在线业务流程实现,在线产品展示,订 单与支付等,整个过程都要符合客户企业自身的业务运作流程,为客户服 务。 用户需求——描述了用户使用网站必须要完成的任务,这在使用实例 或方案中予以说明。 例如:描述‚招聘系统‛功能,用户可分部门浏览职位招聘情况,可 在线填写简历,用户填写的简历字段可定制,后台可分类检索简历。
需求确认 案例讨论
No. 2
从一个典型的失败项目说起——需求和功能设计
|现实
一个小项目,感觉需求也简单,再加上时间 紧,如果从需求开始一步步来,时间肯定来不 及,在这种情况下,项目就匆匆的开始了。为 了节省时间,需求分析,架构设计等等都不去考 虑了,想到哪写到哪,完全瀑布式开发。直接 结果是,完工时间一拖再拖,最后不得不决定 下一版本整个推倒重来。
项目管理
Project Management
______需求管理
Internal Training Materials
CONFIDENTIAL INFORMATION: Do not disclose
C
ontent
I. II. III.
什么是需求 如何寻找需求 分析需求的难点
IV.
V. VI.
需求分析20条准则
10
获得满足客户功能和质量要求的系统
•每个人都希望项目成功,但这不仅要求客户要清晰地告知开发人员关于 系统‚做什么‛所需的所有信息,而且还要求开发人员能通过交流了解 清楚取舍与限制,一定要明确说明您的假设和潜在的期望,否则,开发 人员开发出的产品很可能无法让您满意。
11
给分析人员讲解业务
•分析人员要依靠客户讲解业务概念及术语,但客户不能指望分析人员会 成为该领域的专家,而只能让他们明白您的问题和目标;不要期望分析 人员能把握客户业务的细微潜在之处,他们可能不知道那些对于客户来 说理所当然的‚常识‛。
相关主题