第3章需求分析概述
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
用户需求例子－图书馆管理系统
功能需求：办理读者借书证, … 性能需求：查询操作延迟时间不超过1秒钟, … 设计约束：前台运行在windows OS下，… 其它要求：开发时间6个月, …
需求分析为什么重要？
（1）许多大型应用系统的失败，最后均归结到需求 分析：要么获取需求的方法不当，使得需求分析不到 位或不彻底，导致开发者反复多次地进行需求分析， 致使设计、编码、测试无法顺利进行；要么客户配合 不好，导致客户对需求不确认，或客户需求不断变化， 同样致使设计、编码、测试无法顺利进行。
需求获取是一个需要高度合作的活动，而并不 是客户所说的需求的简单复本。
作为一个分析者，你必须透过客户所提出的表 面需求理解他们的真正需求。询问一个可扩充 （open-ended）的问题有助于你更好地理解 用户目前的业务过程并且知道新系统如何帮助 或改进他们的工作。
调查用户任务可能遇到的变更，或者用户需要 使用系统其它可能的方式。想像你自己在学习 用户的工作，你需要完成什么任务？你有什么 问题？从这一角度来指导需求的开发和利用。
需求获取为什么难？
（3）开发者和用户要对需求达成完全一致的认 识，用户要在需求报告上签字，要承担责任。
项 目 负 责人设计 员
用 户
需 求 分 析 Βιβλιοθήκη Baidu 员
分析人员或客户理解有误。
有个外星人间谍潜伏到地球刺探情报，它给上司写了 一份报告：“主宰地球的是车。它们喝汽油，靠四个 轮子滚动前进。嗓门极大，在夜里双眼能射出强 光。……有趣的是，车里住着一种叫作‘人’的寄生 虫，这些寄生虫完全控制了车。” 软件系统分析人员不可能都是全才。客户表达的需求， 不同的分析人员可能有不同的理解。如果分析人员理 解错了，可能会导致开发人员白干活，吃力不讨好。 读中学时候最怕写作文逃题，如果逃题了，不管作文 写得多长，总是零分。所以分析人员写好需求说明书 后，要请客户方的各个代表验证。如果问题很复杂， 双方都不太明白，就有必要请开发人员快速构造软件 的原型，双方再次论证需求说明书是否正确。
需求不准确性（客户说不清楚需求）
有些客户心里非常清楚想要什么，但却说不明白。 大家可能很不以为然。就举日常生活的事例吧， 比如说买鞋子。我们非常了解自已的脚，但没法 说清楚脚的大小和形状。只能拿鞋子去试，试穿 时感觉到舒服才会买鞋（居然也有神通广大的售 货员，看一眼客户的脚，就知道应该穿什么样的 鞋）。
需求获取方法-简易的应用规格说明技术
这种方法提倡用户与开发者密切合作，共同 标识问题，提出解决方案的要素，商讨不同 的方法并指定基本的需求。今天，简易的应 用规格说明技术已经成为信息系统界使用的
需求获取方法-简易的应用规格说明技术
尽管存在许多不同的简易应用规格说明 方法，但是它们遵循的基本准则是相同
唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。” （《大话西游之大圣娶亲》）
连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也 因此变得多姿多彩。 软件的需求会变化吗？ 答：据历史记载，没有一个软件的需求改动少于三次。 让我们先接受“需求会变动”这个事实吧，免得在需求变动时 惊慌失措。明白“需求会变动”这个道理后，在进行需求分析 时就要留点神： （1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需 求。以便在进行系统设计时，将软件的核心建筑在稳定的需求 上，否则将会吃尽苦头。 （2）在合同中一定要说清楚“做什么”和“不做什么”。如 果合同含含糊糊，日后扯皮的事情就多。
所以为了更好的理解问题，人们常常采 用建立模型的方法。
需求描述工具 结构化分析方法--结构化建模
所谓模型，就是为了理解事 物而对事物做出的一种抽象， 是对事物的一种无歧义的书 面描述。
通常，模型由一组图形符号 和组织这些符号的规则组成。 结构化分析就是一种建立模 型的活动，通常建立数据模 型、功能模型和行为模型等
访谈-情景分析
有些时候，尝试着问一些“愚蠢”的问题也有助于客 户打开话匣子。如果你直接要求客户写出业务是如何 实现的，客户十有八九无法完成。但是如果你尝试着 问一些实际的问题，例如：“以我的理解，你们收到 订单后，会...”。客户立刻就会指出你的错误，并滔滔 不绝的开始谈论业务，而你，就在一边仔细的聆听吧。 这一招就叫做“抛砖引玉”。
讨 成分论 报析： 表员“ 自对我 动用们 化户要处提用理出新”的的，初系你步统觉要完得求
需求分析为什么重要？ 这应个该需反求复是求精精确多的次，细可化测，试才的能 的充吗分？理解用户的需求，得出对
目标系统的完整、准确和具体
（2）需求分析的输出的文要档求。是《用户需求 报告》，它是客户、软件开发人员和项 目管理人员三者必须遵守的一根基线， 三者共同工作的基础，是测试的准则。
需求获取方法-软件原型
快速原型应该具备的第一个特性是 “快速”。快速原型的目的是尽快向用 户提供一个可在计算机上运行的目标系 统的模型，以便使用户和开发者在目标 系统应该“做什么”这个问题上尽可能 快地达成共识。
需求获取方法-软件原型
快速原型应该具备的第二个特性是 “容易修改”。如果原型的第一版不是 用户所需要的，就必须根据用户的意见 迅速地修改它，构建出原型的第二版， 以更好地满足用户的需求。
为什么软件系统分析员的工资要比普通程序员高？ 就是因为需求分析困难
需求获取为什么难？
（4）中国的国有企业正处在变动期（体制改革与 企业重组），中国的民营企业正处在成长期（发 展壮大与不完全成熟）。这就给信息系统的需求 分析，无疑增加了难度系数。
想想看，这四条原因，哪一条都非同小可？
需求描述工具
工作获得成功的前提和关键，不论我们
把设计和编码工作做得如何出色，不能
真正满足用户需求的程序只会给用户带
3.1 概述（什么是软件需求、需
求分析的重要性及困难性）
3.2
与用户沟通的方法
3.3
分析建模与规格说明
3.3
实体 — 关系图
3.5
数据流图
3.6
状态转换图
3.7
数据字典
3.8
小结
3.1 概述—怎样理解需求分析、 软件需求
需求过程中的角色
名称 用户
客户
市场分 析人 员
软件分 析师
描述 直接操作软件的人员。他们通常具有不同的 业务角色，有不同的业务需求。例如一个图 书管理系统的用户包括：读者、图书管理员、 仓库管理员、系统管理员、馆长
指软件开发的委托方或软件市场的目标客户。 例如，某一设备制造商委托软件开发商进行 设备控制软件开发，那么该设备制造商是系 统的客户 对于没有具体客户的通用软件，市场分析人 员将提供市场需要，并对实际客户进行模拟
使用一种“定义机制”(例如，工作表、 图表等)。
需求获取方法-简易的应用规格说明技术
目标是标识问题、提出解决方案要素、 商讨不同的方法以及在有利于实现目标
需求获取方法-软件原型
构建原型的要点是，它应该实现用户看得见 的功能(例如屏幕显示或打印报表)，省略目 标系统的“隐含”功能(例如修改文件)
在中立地点举行由开发者和用户双方出
需求获取方法-简易的应用规格说明技术
提出一个议事日程，这个日程应该足够 正式以便能够涵盖所有要点，同时这个 日程又应该足够非正式，以便鼓励自由 思维。
需求获取方法-简易的应用规格说明技术
由一个“协调人”来主持会议，他既可 以是用户也可以是开发者还可以是从外
访谈
在非正式的访谈中，将提出一些可以自 由回答的开放性问题，以鼓励被访问的 人员表达自己的想法，例如，询问用户 为什么对目前正在使用的系统感到不满
问卷调查
当需要调查大量人员的意见时，向被调 查的人员分发调查表是一个十分有效的 做法。
访谈-情景分析
在对用户进行访谈的过程中使用情景分 析技术往往非常有效。所谓情景分析就 是对用户运用目标系统解决某个具体问 题的方法和结果进行分析。
软件行业中的最高技术职称。
需求获取(需求分析）为什么难？
需求获取看似容易，做起来难，主要原 因有四：
（1）用户需求具有动态性，即需求的 不稳定性。在整个软件生存周期内，应用 软件的需求会随着时间的进展而有所变化。 个别用户，甚至是朝三暮四地变化。
问题域
交流 用户
需求分析员
需求具有动态性、不稳定性、自身经常变动
对于类似的项目，软件分析师将对以前系统 进行评估，判断是否存在重用的可能
需求获取方法-访谈
访谈(或称为会谈)是最早开始运用的获 取用户需求的技术，也是迄今为止仍然 广泛使用的主要的需求分析技术。
开座谈会 问卷调查 跟班作业 收集用户资料
访谈
访谈有两种基本形式，分别是正式的和 非正式的访谈。在正式的访谈中，系统 分析员将提出一些事先准备好的具体问 题，例如，询问客户公司销售的商品种 类、雇用的销售人员数目以及信息反馈 时间应该多快等。
开座谈会
需求讨论会上必须要使用笔记本电脑，还要指定一个 打字熟练的人把所有的讨论记录下来，记录的同时还 要做一定的整理。如果不这样做，那么你结束会议的 时候就会发现，所有的讨论只剩下一个模糊的印象， 需求对你来说仍然是一件遥远的事情。在座谈讨论之 后，记下所讨论的条目(item)，并请参与讨论的用户 评论并更正。及早并经常进行座谈讨论是需求获取成 功的一个关键途径，因为只有提供需求的人才能确定 是否真正获取需求。进行深入收集和分析以消除任何 冲突或不一致性。
需求描述文档-软件需求规格说明
除了用分析模型表示软件需求之外，还 要写出准确的软件需求规格说明。模型 既是软件设计的基础，也是编写软件规 格说明的基础。
见规格说明书模板及例子
3.2 与用户沟通的方法
软件需求分析总是从两方或多方之间的 通信开始。用户面临的问题需要用基于 计算机的方案来解决；开发者应该对用 户的需求作出反应，给用户提供帮助。
需求获取为什么难？
（2）用户需求具有模糊性，即需求不准 确性。由于用户的素质不是很高，业务流 程不很规范，所以需求表达不很清楚也不 够明确。
问题域
交流 用户
需求分析员
需求不准确性（客户说不清楚需求）
有些客户对需求只有朦胧的感觉，当然说不清 楚具体的需求。例如全国各地的很多政府机构 在搞网络建设，这些单位的领导和办公人员大 多不清楚计算机网络有什么用，反而要软件系 统分析人员替他们设想需求。
分析人员或客户理解有误。
由于客户大多不懂软件，他们可能觉得软件是万 能的，会提出一些无法实现的需求。有时客户还 会把软件系统分析人员的建议或答复给想歪了。
有一个软件人员滔滔不绝地向客户讲解在“信息 高速公路上做广告”的种种好处，客户听得津津 有味。最后，心动的客户对软件人员说：“好得 很，就让我们马上行动起来吧。请您决定广告牌 的尺寸和放在哪条高速公路上，我立即派人去 做。”
需求不准确性（客户说不清楚需求）
如果客户本身就懂软件开发，能把需求说得清 清楚楚，这样的需求分析将会非常轻松、愉快。 如果客户全不懂软件，但信任软件开发方，这 事也好办。分析人员可以引导客户，先阐述常 规的需求，再由客户否定不需要的，最终确定 客户真正的需求。最怕的就是“不懂装懂”或 者“半懂充内行”的客户，他们会提出不切实 际的需求，那么沟通和协商都会很困难。
需求分析为什么重要？
（3）需求分析要占用整个软件开发时间或工作量 的30%左右。
（4）需求获取中的错误，属于软件开发中的早期 错误，它会在后续的设计和实现中进行发散式的 传播。
根据以上四项原因，IT企业的高层经理，对
需求分析特别重视，常常派经验最丰富的人员去
作项目需求。正因为如此，“系统分析员”才是
第二篇 传统方法学
采用传统的方法
学进行需求分析
第3章
结构化分析 “做什么，不做 什么”
为了开发出真正满足用户需求的软件产 品，首先必须知道用户的需求。
传统的软件工程方法学采用结构化分析 (Structured Analysis ,SA)技术完成需 求分析工作。
我们必须知道
对软件需求的深入理解是软件开发
需求分析是发现、求精、建模、规格 说明和复审的过程。
软件需求，又称软件需求分析或软件 需求获取，它既是软件开发中的老问 题（几十年都没有很好地彻底解决）， 又包含着许多新思路和新内容。需求 获取是否彻底与成功，直接关系到软 件开发的成败。
什么是用户需求
待开发软件系统的功能、性能、设计约束和其它要求
功能需求：办理读者借书证, … 性能需求：查询操作延迟时间不超过1秒钟, … 设计约束：前台运行在windows OS下，… 其它要求：开发时间6个月, …
需求分析为什么重要？
（1）许多大型应用系统的失败，最后均归结到需求 分析：要么获取需求的方法不当，使得需求分析不到 位或不彻底，导致开发者反复多次地进行需求分析， 致使设计、编码、测试无法顺利进行；要么客户配合 不好，导致客户对需求不确认，或客户需求不断变化， 同样致使设计、编码、测试无法顺利进行。
需求获取是一个需要高度合作的活动，而并不 是客户所说的需求的简单复本。
作为一个分析者，你必须透过客户所提出的表 面需求理解他们的真正需求。询问一个可扩充 （open-ended）的问题有助于你更好地理解 用户目前的业务过程并且知道新系统如何帮助 或改进他们的工作。
调查用户任务可能遇到的变更，或者用户需要 使用系统其它可能的方式。想像你自己在学习 用户的工作，你需要完成什么任务？你有什么 问题？从这一角度来指导需求的开发和利用。
需求获取为什么难？
（3）开发者和用户要对需求达成完全一致的认 识，用户要在需求报告上签字，要承担责任。
项 目 负 责人设计 员
用 户
需 求 分 析 Βιβλιοθήκη Baidu 员
分析人员或客户理解有误。
有个外星人间谍潜伏到地球刺探情报，它给上司写了 一份报告：“主宰地球的是车。它们喝汽油，靠四个 轮子滚动前进。嗓门极大，在夜里双眼能射出强 光。……有趣的是，车里住着一种叫作‘人’的寄生 虫，这些寄生虫完全控制了车。” 软件系统分析人员不可能都是全才。客户表达的需求， 不同的分析人员可能有不同的理解。如果分析人员理 解错了，可能会导致开发人员白干活，吃力不讨好。 读中学时候最怕写作文逃题，如果逃题了，不管作文 写得多长，总是零分。所以分析人员写好需求说明书 后，要请客户方的各个代表验证。如果问题很复杂， 双方都不太明白，就有必要请开发人员快速构造软件 的原型，双方再次论证需求说明书是否正确。
需求不准确性（客户说不清楚需求）
有些客户心里非常清楚想要什么，但却说不明白。 大家可能很不以为然。就举日常生活的事例吧， 比如说买鞋子。我们非常了解自已的脚，但没法 说清楚脚的大小和形状。只能拿鞋子去试，试穿 时感觉到舒服才会买鞋（居然也有神通广大的售 货员，看一眼客户的脚，就知道应该穿什么样的 鞋）。
需求获取方法-简易的应用规格说明技术
这种方法提倡用户与开发者密切合作，共同 标识问题，提出解决方案的要素，商讨不同 的方法并指定基本的需求。今天，简易的应 用规格说明技术已经成为信息系统界使用的
需求获取方法-简易的应用规格说明技术
尽管存在许多不同的简易应用规格说明 方法，但是它们遵循的基本准则是相同
唐僧曾说：“妖要是有了仁慈之心，就不再是妖，是人妖。” （《大话西游之大圣娶亲》）
连妖都会变心，别说人了。所以喜新厌旧乃人之常情，世界也 因此变得多姿多彩。 软件的需求会变化吗？ 答：据历史记载，没有一个软件的需求改动少于三次。 让我们先接受“需求会变动”这个事实吧，免得在需求变动时 惊慌失措。明白“需求会变动”这个道理后，在进行需求分析 时就要留点神： （1）尽可能地分析清楚哪些是稳定的需求，哪些是易变的需 求。以便在进行系统设计时，将软件的核心建筑在稳定的需求 上，否则将会吃尽苦头。 （2）在合同中一定要说清楚“做什么”和“不做什么”。如 果合同含含糊糊，日后扯皮的事情就多。
所以为了更好的理解问题，人们常常采 用建立模型的方法。
需求描述工具 结构化分析方法--结构化建模
所谓模型，就是为了理解事 物而对事物做出的一种抽象， 是对事物的一种无歧义的书 面描述。
通常，模型由一组图形符号 和组织这些符号的规则组成。 结构化分析就是一种建立模 型的活动，通常建立数据模 型、功能模型和行为模型等
访谈-情景分析
有些时候，尝试着问一些“愚蠢”的问题也有助于客 户打开话匣子。如果你直接要求客户写出业务是如何 实现的，客户十有八九无法完成。但是如果你尝试着 问一些实际的问题，例如：“以我的理解，你们收到 订单后，会...”。客户立刻就会指出你的错误，并滔滔 不绝的开始谈论业务，而你，就在一边仔细的聆听吧。 这一招就叫做“抛砖引玉”。
讨 成分论 报析： 表员“ 自对我 动用们 化户要处提用理出新”的的，初系你步统觉要完得求
需求分析为什么重要？ 这应个该需反求复是求精精确多的次，细可化测，试才的能 的充吗分？理解用户的需求，得出对
目标系统的完整、准确和具体
（2）需求分析的输出的文要档求。是《用户需求 报告》，它是客户、软件开发人员和项 目管理人员三者必须遵守的一根基线， 三者共同工作的基础，是测试的准则。
需求获取方法-软件原型
快速原型应该具备的第一个特性是 “快速”。快速原型的目的是尽快向用 户提供一个可在计算机上运行的目标系 统的模型，以便使用户和开发者在目标 系统应该“做什么”这个问题上尽可能 快地达成共识。
需求获取方法-软件原型
快速原型应该具备的第二个特性是 “容易修改”。如果原型的第一版不是 用户所需要的，就必须根据用户的意见 迅速地修改它，构建出原型的第二版， 以更好地满足用户的需求。
为什么软件系统分析员的工资要比普通程序员高？ 就是因为需求分析困难
需求获取为什么难？
（4）中国的国有企业正处在变动期（体制改革与 企业重组），中国的民营企业正处在成长期（发 展壮大与不完全成熟）。这就给信息系统的需求 分析，无疑增加了难度系数。
想想看，这四条原因，哪一条都非同小可？
需求描述工具
工作获得成功的前提和关键，不论我们
把设计和编码工作做得如何出色，不能
真正满足用户需求的程序只会给用户带
3.1 概述（什么是软件需求、需
求分析的重要性及困难性）
3.2
与用户沟通的方法
3.3
分析建模与规格说明
3.3
实体 — 关系图
3.5
数据流图
3.6
状态转换图
3.7
数据字典
3.8
小结
3.1 概述—怎样理解需求分析、 软件需求
需求过程中的角色
名称 用户
客户
市场分 析人 员
软件分 析师
描述 直接操作软件的人员。他们通常具有不同的 业务角色，有不同的业务需求。例如一个图 书管理系统的用户包括：读者、图书管理员、 仓库管理员、系统管理员、馆长
指软件开发的委托方或软件市场的目标客户。 例如，某一设备制造商委托软件开发商进行 设备控制软件开发，那么该设备制造商是系 统的客户 对于没有具体客户的通用软件，市场分析人 员将提供市场需要，并对实际客户进行模拟
使用一种“定义机制”(例如，工作表、 图表等)。
需求获取方法-简易的应用规格说明技术
目标是标识问题、提出解决方案要素、 商讨不同的方法以及在有利于实现目标
需求获取方法-软件原型
构建原型的要点是，它应该实现用户看得见 的功能(例如屏幕显示或打印报表)，省略目 标系统的“隐含”功能(例如修改文件)
在中立地点举行由开发者和用户双方出
需求获取方法-简易的应用规格说明技术
提出一个议事日程，这个日程应该足够 正式以便能够涵盖所有要点，同时这个 日程又应该足够非正式，以便鼓励自由 思维。
需求获取方法-简易的应用规格说明技术
由一个“协调人”来主持会议，他既可 以是用户也可以是开发者还可以是从外
访谈
在非正式的访谈中，将提出一些可以自 由回答的开放性问题，以鼓励被访问的 人员表达自己的想法，例如，询问用户 为什么对目前正在使用的系统感到不满
问卷调查
当需要调查大量人员的意见时，向被调 查的人员分发调查表是一个十分有效的 做法。
访谈-情景分析
在对用户进行访谈的过程中使用情景分 析技术往往非常有效。所谓情景分析就 是对用户运用目标系统解决某个具体问 题的方法和结果进行分析。
软件行业中的最高技术职称。
需求获取(需求分析）为什么难？
需求获取看似容易，做起来难，主要原 因有四：
（1）用户需求具有动态性，即需求的 不稳定性。在整个软件生存周期内，应用 软件的需求会随着时间的进展而有所变化。 个别用户，甚至是朝三暮四地变化。
问题域
交流 用户
需求分析员
需求具有动态性、不稳定性、自身经常变动
对于类似的项目，软件分析师将对以前系统 进行评估，判断是否存在重用的可能
需求获取方法-访谈
访谈(或称为会谈)是最早开始运用的获 取用户需求的技术，也是迄今为止仍然 广泛使用的主要的需求分析技术。
开座谈会 问卷调查 跟班作业 收集用户资料
访谈
访谈有两种基本形式，分别是正式的和 非正式的访谈。在正式的访谈中，系统 分析员将提出一些事先准备好的具体问 题，例如，询问客户公司销售的商品种 类、雇用的销售人员数目以及信息反馈 时间应该多快等。
开座谈会
需求讨论会上必须要使用笔记本电脑，还要指定一个 打字熟练的人把所有的讨论记录下来，记录的同时还 要做一定的整理。如果不这样做，那么你结束会议的 时候就会发现，所有的讨论只剩下一个模糊的印象， 需求对你来说仍然是一件遥远的事情。在座谈讨论之 后，记下所讨论的条目(item)，并请参与讨论的用户 评论并更正。及早并经常进行座谈讨论是需求获取成 功的一个关键途径，因为只有提供需求的人才能确定 是否真正获取需求。进行深入收集和分析以消除任何 冲突或不一致性。
需求描述文档-软件需求规格说明
除了用分析模型表示软件需求之外，还 要写出准确的软件需求规格说明。模型 既是软件设计的基础，也是编写软件规 格说明的基础。
见规格说明书模板及例子
3.2 与用户沟通的方法
软件需求分析总是从两方或多方之间的 通信开始。用户面临的问题需要用基于 计算机的方案来解决；开发者应该对用 户的需求作出反应，给用户提供帮助。
需求获取为什么难？
（2）用户需求具有模糊性，即需求不准 确性。由于用户的素质不是很高，业务流 程不很规范，所以需求表达不很清楚也不 够明确。
问题域
交流 用户
需求分析员
需求不准确性（客户说不清楚需求）
有些客户对需求只有朦胧的感觉，当然说不清 楚具体的需求。例如全国各地的很多政府机构 在搞网络建设，这些单位的领导和办公人员大 多不清楚计算机网络有什么用，反而要软件系 统分析人员替他们设想需求。
分析人员或客户理解有误。
由于客户大多不懂软件，他们可能觉得软件是万 能的，会提出一些无法实现的需求。有时客户还 会把软件系统分析人员的建议或答复给想歪了。
有一个软件人员滔滔不绝地向客户讲解在“信息 高速公路上做广告”的种种好处，客户听得津津 有味。最后，心动的客户对软件人员说：“好得 很，就让我们马上行动起来吧。请您决定广告牌 的尺寸和放在哪条高速公路上，我立即派人去 做。”
需求不准确性（客户说不清楚需求）
如果客户本身就懂软件开发，能把需求说得清 清楚楚，这样的需求分析将会非常轻松、愉快。 如果客户全不懂软件，但信任软件开发方，这 事也好办。分析人员可以引导客户，先阐述常 规的需求，再由客户否定不需要的，最终确定 客户真正的需求。最怕的就是“不懂装懂”或 者“半懂充内行”的客户，他们会提出不切实 际的需求，那么沟通和协商都会很困难。
需求分析为什么重要？
（3）需求分析要占用整个软件开发时间或工作量 的30%左右。
（4）需求获取中的错误，属于软件开发中的早期 错误，它会在后续的设计和实现中进行发散式的 传播。
根据以上四项原因，IT企业的高层经理，对
需求分析特别重视，常常派经验最丰富的人员去
作项目需求。正因为如此，“系统分析员”才是
第二篇 传统方法学
采用传统的方法
学进行需求分析
第3章
结构化分析 “做什么，不做 什么”
为了开发出真正满足用户需求的软件产 品，首先必须知道用户的需求。
传统的软件工程方法学采用结构化分析 (Structured Analysis ,SA)技术完成需 求分析工作。
我们必须知道
对软件需求的深入理解是软件开发
需求分析是发现、求精、建模、规格 说明和复审的过程。
软件需求，又称软件需求分析或软件 需求获取，它既是软件开发中的老问 题（几十年都没有很好地彻底解决）， 又包含着许多新思路和新内容。需求 获取是否彻底与成功，直接关系到软 件开发的成败。
什么是用户需求
待开发软件系统的功能、性能、设计约束和其它要求