第一讲需求分析与管理

3.需求分析的主要困难和对策 3.需求分析的主要困难和对策
3.3合作关系
– –
如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程 中会很疲惫。 倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有 他自己的想法：
我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？ 我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧 ……。
IBM/360
1.需求分析的基本概念 1.需求分析的基本概念
1.3 需求分析的参与人员
一般的项目中需求分析阶段可能存在以下的参与角色，不同的角 色以不同的立场会对需求分析产生不同的影响。 – 客户 – 项目经理（需求方，开发方） – 最终用户 – 系统分析员 – 系统构架师
1.需求分析的基本概念 1.需求分析的基本概念
3.需求分析的主要困难和对策 3.需求分析的主要困难和对策 3.6开发人员写不好需求文档
–
开发人员在调查过程中已经获得了不少需求信息，却写不出好的需 求文档来。理工科学生普遍存在写作能力不强的问题。 提高开发人员写作能力的根本办法就是让他们多练习写文档， 熟能生巧。 另外，企业应当提供合适的文档模板以及比较好的示例文档， 尽可能地降低写作难度。
第一讲需求分析与管理 一切软件成功的基石
目录
1.需求分析的基本概念 2.需求工程 3.需求分析的主要困难和对策 4.需求变更与管理 5.需求分析所用到的工具
1.需求分析的基本概念 1.需求分析的基本概念
1.1定义
需求分析指的是在建立一个新的或改变一个现存的系统时描写新系统的 目的、范围和定义时所要做的所有的工作。需求分析是软件工程中的一 个关键过程 关键过程。 关键过程 需求分析就是准确的获取客户的“需要”，规范客户的“欲望”；
2.2需求开发
– –
–
–
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。 需求调查的目的是通过各种途径获取用户的需求信息（原始材料）， 产生《用户需求说明书》。 需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节 等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。 需求定义的目的是根据需求调查和需求分析的结果，进一步定义准 确无误的产品需求，产生《产品需求规格说明书》。系统设计人员 将依据《产品需求规格说明书》开展系统设计工作。
4.需求变更与管理 4.需求变更与管理
4.5需求跟踪
–
–
需求跟踪的目的是建立与维护“需求－设计－编程－测试” 之间的一致性，确保所有的工作成果符合用户需求。 需求跟踪有两种方式：
正向跟踪。检查《产品需求规格说明书》中的每个需求是否都 能在后继工作成果中找到对应点。 逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都 能在《产品需求规格说明书》中找到出处。
3.需求分析的主要困难和对策 3.需求分析的主要困难和对策
3.1 知识技能问题
–
–
应用域的知识是无边无际的，任何人都不可能是“万事通”。 需求分析员可能是某一领域的专家，但当他接手陌生的业务 时，他可能是个“无知”者。人一生中会有许多充满挫折的 “第一次”，不可以逃避。 当需求分析员缺乏应用域知识时，他该怎么办？ 首先他要有勇气做事，否则连实践的机会都没有。 其次他应当赶紧补习应用域知识，不论是通过自学还是培 训的方式，否则他很难与用户交流。如果可能的话，开发 方最好请既懂软件又懂应用域知识的行家来帮忙。
2.需求工程 2.需求工程
2.3需求管理
– –
–
–

需求管理的目的是在客户与开发方之间建立对需求的共同理解，维 护需求与其它工作成果的一致性，并控制需求的变更。 需求确认是指开发方和客户共同对需求文档进行评审，双方对需求 达成共识后作出书面承诺，使需求文档具有商业合同效果。 需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系， 建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。 需求变更控制是指依据“变更申请－审批－更改－重新确认”的流 程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
4.需求变更与管理 4.需求变更与管理
4.1常见的困境
客户的一个电话，就推翻了之前你与客户、与你自己的开发团 队，经过再三讨论而确认定下来的需求。之后你就重新开始了 和客户、和你的开发团队进入新一轮的需求谈论中，甚至是无 休止的谈论。 “我们无法拒绝客户, 但也无法立即满足他的新需求,所以只好 是推到以后再进行完善。” 而因为需求变更的原因，致使项目多次的延期后，客户仍然说 这不是他们想要的。
–
–
需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住 用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强 的交流、沟通能力。 开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中 的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说 在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举 办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需 求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。
4.需求变更与管理 4.需求变更与管理
4.3对策
实行分级管理，以达到对需求变更的控制和管理 一级需求（或变更）是关键性的需求，这种需求如果不满足，意味着 整个项目不能正常交付使用，前期工作也会被全部否定。 二级需求（或变更）是后续关键性需求，它不影响前面工作内容的交 付，但不加以满足，新的项目内容无法提交或继续 三级需求是后续重要的需求，如果不被满足会令整体项目工作的价值 下降，为了体现项目价值，也是开发人员自已的技术价值的证明 四级需求是改良性需求，没有满足这类需求并不影响已有功能的使用， 但如果实现了则会更好 五级需求是可选性需求，更多的是偶是一种设想，以及一种可能，通 常只是客户的的一种个人喜好而已
5.需求分析所用到的工具 需求分析所用到的工具
5.1文档化（便捷，经济） ○○○○-製品要件説明書.doc ○○○○-顧客要件説明書.doc 用户需求说明书 产品规格说明书
5.需求分析所用到的工具 需求分析所用到的工具
5.2构建快速原型 Visio Rose Dreamwear Flash ………..
3.需求分析的主要困难和对策 3.需求分析的主要困难和对策 3.4用户说不清楚需求
– – – – –
讨论-评审-修改-确认-讨论-评审-修改……. 通过讨论出真知的方式，激发和挖掘出需求，不断的使需求清晰 起来。 沟通技巧（助产术,建议法） 和客户的沟通技巧在需求分析时占据着很重要的位置。 需求理解与需求挖掘 可以广泛的借鉴其他系统的应用经验服务于当前项目 眼见为实：原型系统 由于各种原因，客户缺乏成功构建系统的动力或者主动性：根据 客观条件改善沟通关系
1.2需求分析的重要性
Frederick Brooks在他1986 《没有银弹》的论文中阐述了需求的重要 性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念 性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件 系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后 对它修改也极为困难。
–
正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种 跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需 求跟踪矩阵保存了需求与后继工作成果的对应关系。
4.需求变更与管理 4.需求变更与管理
核心：
变更可控
需求变更管理tips 需求变更管理
需求一定要与投入有联系，如果需求变更的成本由开 发方来承担，则项目需求的变更就成为必然了。所以， 在项目的开始，无论是开发方还是出资方都要明确这 一条：需求变，软件开发的投人也要变。 需求的变更要经过出资者的认可，这样才会对需求的 变更有成本的概念，能够慎重地对待需求的变更。 小的需求变更也要经过正规的需求管理流程，否则会 积少成多
4.需求变更与管理 4.需求变更与管理
4.4需求评审面临的困难
–
–
开评审会议时经常会发生争议。适当的争议有利 于澄清问题，比什么东西都一致赞成要好。然而 当争议变为争吵时就坏事了，争吵不仅对评审工 作没有好处，而且会无意中伤害同事们的感情。 人们在很多时候分不清楚自己究竟是“坚持真理” 还是“固执己见”。毫不妥协或者轻易妥协都不 是好办法。我们应当养成良好的习惯：不要一棍 子打死异己的观点，尝试着让自己站在他人的立 场思考问题，这样你会找到比较满意的答案。
3.需求分析的主要困难和对策 3.需求分析的主要困难和对策
3.2态度问题
–
–
–
相当多的开发人员习惯于被动地对待需求开发。很多开发人员错误 地以为： 需求是用户的事情，不是我们的事情。我们为用户开发软件， 难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需 求，或者经常变更需求，这类问题是用户产生的，应当由他们 自己负责。 用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不 是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当 成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发 过程，产生太多的后患。 软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析 员的天职就是在有限的时间内获取准确而细致的用户需求，如果做 不到就是失职，不要找借口。
3.需求分析的主要困难和对策 3.需求分析的主要困难和对策
3.5双方误解需求
沟通行为本身就存在歧义 使用客户容易理解的语言和表达方式，一些负责的问题采用图表， 动画和原型系统等直观的方式进行讨论 – 沟通术语不统一 加强学习和培训 – 角度不同，理解不同 – 知识面不对称
–
解决沟通误解的主要技术手段除了加强沟通外，就是需要确保需求 的确认工作。
4.需求变更与管理 4.需求变更与管理 4.4需求评审面临的困难
– –
–
需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比 较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。 需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起 花费比较长的时间开会并不容易（例如有些人可能出差在外，有 些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开 发是循序渐进的过程，需求评审也可以分段进行。这样每次评审 的时间比较短，参加评审的人员也少一些，组织会议就比较容易。 开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子 一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。 主持人应当控制话题，避免大家讨论与主题无关的东西。
4.需求变更与管理 4.需求变更与管理
4.2需求变更的主要原因
范围没有圈定就开始细化 项目功能的添加和改善 没有指定需求的基线 需求的基线是指是否容许需求变更的分界线。随着项目的进展， 基线将越定越高 没有良好的软件结构适应变化
4.需求变更与管理 4.需求变更与管理
4.3对策
加强前期工作：客户不断提出需求变更，那就有一个问题，客户为什 么要不断提出变更？可见客户自己对项目并不是很理解，在项目的进 行中有了想法，就要求项目团队加进去，所以，问题的本原在于，从 一开始就要了解客户的需要是什么？他们会有那些潜在的需要？ 需求确认是指开发方和客户方共同对《产品需求规格说明书》进行评 审，双方对需求达成共识后作出承诺。需求确认包含两个重要工作： “需求评审”和“需求承诺”。
1.3 需求分析的参与人员
客户：负责掏钱的人，扮演着上帝的角色 项目经理（需求方）：上帝的代理人 项目经理（开发方）：保证项目能够顺利完成的看护人 最终用户：最终使用用户的人 系统分析员：需求分析的导演 系统构架师：导演的技术顾问
2.需求工程 2.需求工程
2.1需求分析的工程化划分
2.需求工程 2.需求工程
2.需求工程 2.需求工程
2.4需求分析的工程化方法
– –
–
需求分析不是艺术创作，需要有规范的基本方法，沟通技巧 可以因人而异，需求分析的过程和基本目标是严肃而细致的。 需求的管理，变更和追踪是细致的工作，不能因为需求项目 的细小而放弃管理，放弃管理最终会使项目在大量的细节中 失败。记忆是不可靠的，没有详尽的记录和确认只会使项目 陷入争论和互相埋怨。 需求的工程化方法的目标是保证需求清晰，可控