项目管理之需求分析

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
给分析人员讲解业务
•分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会 成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析 人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来 说理所当然的‚常识‛。