3需求分析(1)-基本理论
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
定义问题 分析问题
N
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
导出解
2.5 需求规格说 明
2.6 数据流建模
逻辑模型符合系统目标？
Y END
12
C2 需求分析
（5）导出和评价供选择的解法 分析员应该从他建议的系统逻辑模型出 发，导出若干个较高层次的（较抽象的）物 理解法供比较和选择。其最简单途径是从技 术角度出发考虑解决问题的不同方案。 分别从技术角度、操作的可行性和经济 角度提出了一些可能的物理系统，去掉用户 不能接受的方案。 最后为每个在技术、操作和经济等方面 都可行的系统制定实现进度表，它不需要 （也不可能）制定得很详细，通常只需要顾 及生命周期每个阶段的工作量。
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
18
§2.3 软件需求分析
2.3.1 软件需求分析的任务
• 深入描述软件的功能和性能 • 确定软件设计的约束和软件同其它系统元素的 接口细节 • • • • • 定义软件的其它有效性需求 需求分析研究的对象是软件项目的用户要求 准确地表达被接受的用户要求 确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统元素中
5
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
C2 需求分析
2.2.2可行性分析的内容
（ 1）操作可行性 又称为社会可行性或运行可行性，是 对开发系统在一个给定的工作环境中能否 运行或运行好坏程度的量度。操作可行性 分析可以确定在当前政治意识形态、法律 法规、社会道德以及系统运行的组织机构 和人员等环境下，系统是否可行。
9
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
C2 需求分析
（2）研究正在使用的系统 现有的系统是信息的重要来源。显然， 若目前已有一个系统正被人使用，那么这个 系统必定能完成某些有用的工作，因此新的 目标系统必须也能完成它的基本功能；另一 方面，若现有系统完美无缺，用户自然不会 提出开发新系统的要求，因此，现有系统必 有缺点，新系统必须能解决现有系统存在的 问题。
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
例 考虑某大型商场的库存管 理系统。仓库中现有的各种商 品的数量和每种商品的库存量 临界值等数据值记录在库存清 单文件中。当仓库中商品数量 发生变化时，必须及时对库存 清单文件进行更新。如果某种 商品的库存量少于事先设定的 临界值，则应该报告给采购部 门以便订货。右图是库存清单 系统的系统流程图。
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（3）经济可行性 是对将要开发的系统的成本效益进行的量 度。软件的开发对公司或企业来说通常被视为 资本投资，因此，也应该像其他的资本投资一 样进行同样的投资分析。这些投资分析包括成 本效益分析、投资回收期、投资回收率、货币 的时间价值等。成本效益分析应该从两个方面 进行：一个方面是成本估计，包括系统开发期 间的开发成本和系统开发成功后的运行成本； 另一个方面是效益或利润估计，效益包括有形 的效益和无形的效益。
Fra Baidu bibliotek2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
§2.1 需求分析的目标
C2 需求分析
2.1 目标
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
• • • • • • • •
Bertrand Meyer在他的著作《ObjectOriented Software Construction》中总结了系统 需求分析的八项目标： 可行性分析 A0：决定是否建立一个系统 A1：理解最终的软件系统应该解决哪些问题 A2：引出这些问题和系统的一些相关问题 A3：提供一个与这些问题和系统特性有关的回答问 题的基础 A4：决定系统应该做什么 A5 ：决定系统不应该做什么 A6 ：确认系统将能满足用户的需要，并且定义相 应的验收标准 2 A7 ：为系统开发提供一个基础 需求规格说明
19
C2 需求分析
2.1 目标
2.2 可行性分析 --任务 --过程
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
• 需求分析的任务就是借助于当前 系统的逻辑模型导出目标系统的 逻辑模型，解决目标系统的 “做 什么” 的问题。
怎么做
当前系统 模型化 物理模型 抽象化
做什么
7
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
2.2.2可行性分析的内容
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
需求收集
C2 需求分析
2.1 目标
§2.2 可行性分析
可行性分析的目的，就是用最小的 代价在尽可能短的时间内确定问题 是否能够解决。 是否能够解决
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
3
2.2.1可行性分析的任务
可行性分析实质上是要进行一次大大压 缩简化了的系统分析和设计的过程，也就 是在较高层次上以较抽象的方式进行的系 统分析和设计的过程。 首先需要进一步分析和澄清问题定义。 在澄清了问题定义之后，分析员应该导 出系统的逻辑模型。然后从系统逻辑模型 出发，探索若干种可供选择的主要解法(即 系统实现方案)。
13
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（6）推荐行动方针 根据可行性研究成果应该做出的一个关 键性决定是，是否继续进行这项开发过程。 分析员必须清楚地表明他对这个关键特性决 定的建议。分析员认为值得继续进行这项开 发工程，并且说明选择这个解决方案的理由。 如果通常使用部门的负责人主要根据经济上 是否划算决定投资于一项开发过程，因此分 析员对于所推荐的系统必须进行比较仔细的 成本/效益分析。
逻辑模型
理 导解 需 出求 表 达 需 求
目标系统
具体化
物理模型
实例化
逻辑模型
2.3.2 需求分析的过程（四个方面）
★问题识别 ★分析与综合 ★编制需求分析阶段的文档 ★需求分析评审
(1) 问题识别 从系统的角度来理解软件并评审软件范围是否恰 当 确定对目标系统的综合要求，即软件的需求 提出这些需求实现条件，以及需求应达到的标准
第二章
软件需求分析
C2 需求分析
需求分析要求详细、准确地分析清楚 系统必须“做什么”，它是关系到软件开 发成败的关键阶段。在需求分析阶段，需 要用到各种方法、技术和工具等。通常把 一整套需求规格说明的方法、技术、图形 工具以及相应的软件工具的集合称为建模 方法。 结构化方法 面向对象方法
1
2.1 目标
10
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（3）导出新系统的高层逻辑模型 通过前一步的工作，分析员对目标系统应有 的基本功能和所受的约束已有一定了解，能 够使用数据流图描绘数据在系统中流动和处 理的情况，从而概括地表达他对新系统的设 想。通常为了把新系统描绘得更清晰准确， 还应有一个初步的数据字典，定义系统中使 用数据。数据流图和数据字典共同定义了新 系统的逻辑模型，以后可从这个逻辑模型出 发设计新系统。
14
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（7）草拟开发计划 开发计划除了制定工程进度表之外还 应该估计对各类开发人员和各种资源等的需 要情况，该指明那些时候使用以及使用多长 时间。此外还应估计系统生命周期每个阶段 的成本。最后应该给出下一个阶段（需求分 析）的详细进度表和成本估计。 （8）书写文档提交审查 应该把上述可行性研究各个步骤的工作 结果写成清晰的文档，请用户、客户组织的 负责人及评审组审查，以决定是否继续这项 工程及是否接受分析员推荐的方案。
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
16
处理 输入/输出
库存更新事务
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
8
2.2.3可行性分析基本步骤 （1）复查系统规模和目标 分析员访问关键人员，仔细阅读和分析 有关的材料，以便对问题定义阶段书写的关 于规模和目标的报告书进行进一步复查确 认，改正含糊或不确切的叙述，清晰地描述 对目标系统的一切限制和约束。这个步骤的 工作，实质上是为了确保分析员正在解决的 问题确实是要求他解决的问题。
15
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
2.2.4 系统流程图
在进行可行性分析时，首先需要了解现 有物理系统的基本情况，并以概括的形式表 示出来。系统流程图是一种表示物理系统的 传统工具。系统中的各个物理部件通常包括 程序、文件、数据库、表格、人工过程等。 系统流程图表示的是信息在系统各物理 部件之间流动的情况，而不是对信息进行加 工处理的控制过程。
11
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（4）进一步定义问题 新系统的逻辑模型实质上表达了分析员 对新系统必须做什么的看法。用户是否也有 同样的看法呢？分析员应该和用户一起再次 复查问题定义、工程规模和目标，这次复查 应该把数据流图和数据字典作为讨论的基础。 若分析员对问题有误解或者用户曾经遗漏了 某些要求，那么现在是发现和改正这些错误 的时候了。
4
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
对每种解法都应该仔细研究它的可行 性，一般说来，至少应该从技术、经济和操 作三方面研究每种解法的可行性。 (1)技术可行性 使用现有的技术能实现这 个系统吗? (2)经济可行性 这个系统的经济效益能超 过它的开发成本吗? (3)操作可行性 系统的操作方式在这个用 户组织内行得通吗? 必要时还应该从法律、社会效益等更广 泛的方面研究每种解法的可行性
库存清单程序
库存清单 文件
订货信息
报告生成程序
订货报告
17
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
系统流程图要点
对于比较复杂的系统，可以采用分层 的方法。首先，用一张系统流程图在高层 次上描绘系统的整体概貌，体现系统的关 键功能。然后，将每个关键功能扩展到一 定的详细程度，绘制成单独的一张图。
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
6
2.2.2可行性分析的内容
（2）技术可行性 是对特定的技术解决方案的实用性和技 术资源的可用性的量度。通常说来，人们喜 欢追逐新技术以解决他们碰到的实际问题。 比如，随着语音识别技术的日益成熟并走向 实用，人们可以考虑把语音识别技术作为将 要开发的系统的一部分。但技术上是否已经 实用化则是一个必须注意的问题，技术资源 (比如掌握这种技术的人力资源)是否可以获 得则是另外一个问题。
N
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
导出解
2.5 需求规格说 明
2.6 数据流建模
逻辑模型符合系统目标？
Y END
12
C2 需求分析
（5）导出和评价供选择的解法 分析员应该从他建议的系统逻辑模型出 发，导出若干个较高层次的（较抽象的）物 理解法供比较和选择。其最简单途径是从技 术角度出发考虑解决问题的不同方案。 分别从技术角度、操作的可行性和经济 角度提出了一些可能的物理系统，去掉用户 不能接受的方案。 最后为每个在技术、操作和经济等方面 都可行的系统制定实现进度表，它不需要 （也不可能）制定得很详细，通常只需要顾 及生命周期每个阶段的工作量。
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
18
§2.3 软件需求分析
2.3.1 软件需求分析的任务
• 深入描述软件的功能和性能 • 确定软件设计的约束和软件同其它系统元素的 接口细节 • • • • • 定义软件的其它有效性需求 需求分析研究的对象是软件项目的用户要求 准确地表达被接受的用户要求 确定被开发软件系统的系统元素 将功能和信息结构分配到这些系统元素中
5
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
C2 需求分析
2.2.2可行性分析的内容
（ 1）操作可行性 又称为社会可行性或运行可行性，是 对开发系统在一个给定的工作环境中能否 运行或运行好坏程度的量度。操作可行性 分析可以确定在当前政治意识形态、法律 法规、社会道德以及系统运行的组织机构 和人员等环境下，系统是否可行。
9
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
C2 需求分析
（2）研究正在使用的系统 现有的系统是信息的重要来源。显然， 若目前已有一个系统正被人使用，那么这个 系统必定能完成某些有用的工作，因此新的 目标系统必须也能完成它的基本功能；另一 方面，若现有系统完美无缺，用户自然不会 提出开发新系统的要求，因此，现有系统必 有缺点，新系统必须能解决现有系统存在的 问题。
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
例 考虑某大型商场的库存管 理系统。仓库中现有的各种商 品的数量和每种商品的库存量 临界值等数据值记录在库存清 单文件中。当仓库中商品数量 发生变化时，必须及时对库存 清单文件进行更新。如果某种 商品的库存量少于事先设定的 临界值，则应该报告给采购部 门以便订货。右图是库存清单 系统的系统流程图。
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（3）经济可行性 是对将要开发的系统的成本效益进行的量 度。软件的开发对公司或企业来说通常被视为 资本投资，因此，也应该像其他的资本投资一 样进行同样的投资分析。这些投资分析包括成 本效益分析、投资回收期、投资回收率、货币 的时间价值等。成本效益分析应该从两个方面 进行：一个方面是成本估计，包括系统开发期 间的开发成本和系统开发成功后的运行成本； 另一个方面是效益或利润估计，效益包括有形 的效益和无形的效益。
Fra Baidu bibliotek2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
§2.1 需求分析的目标
C2 需求分析
2.1 目标
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
• • • • • • • •
Bertrand Meyer在他的著作《ObjectOriented Software Construction》中总结了系统 需求分析的八项目标： 可行性分析 A0：决定是否建立一个系统 A1：理解最终的软件系统应该解决哪些问题 A2：引出这些问题和系统的一些相关问题 A3：提供一个与这些问题和系统特性有关的回答问 题的基础 A4：决定系统应该做什么 A5 ：决定系统不应该做什么 A6 ：确认系统将能满足用户的需要，并且定义相 应的验收标准 2 A7 ：为系统开发提供一个基础 需求规格说明
19
C2 需求分析
2.1 目标
2.2 可行性分析 --任务 --过程
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
• 需求分析的任务就是借助于当前 系统的逻辑模型导出目标系统的 逻辑模型，解决目标系统的 “做 什么” 的问题。
怎么做
当前系统 模型化 物理模型 抽象化
做什么
7
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
2.2.2可行性分析的内容
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
需求收集
C2 需求分析
2.1 目标
§2.2 可行性分析
可行性分析的目的，就是用最小的 代价在尽可能短的时间内确定问题 是否能够解决。 是否能够解决
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
3
2.2.1可行性分析的任务
可行性分析实质上是要进行一次大大压 缩简化了的系统分析和设计的过程，也就 是在较高层次上以较抽象的方式进行的系 统分析和设计的过程。 首先需要进一步分析和澄清问题定义。 在澄清了问题定义之后，分析员应该导 出系统的逻辑模型。然后从系统逻辑模型 出发，探索若干种可供选择的主要解法(即 系统实现方案)。
13
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（6）推荐行动方针 根据可行性研究成果应该做出的一个关 键性决定是，是否继续进行这项开发过程。 分析员必须清楚地表明他对这个关键特性决 定的建议。分析员认为值得继续进行这项开 发工程，并且说明选择这个解决方案的理由。 如果通常使用部门的负责人主要根据经济上 是否划算决定投资于一项开发过程，因此分 析员对于所推荐的系统必须进行比较仔细的 成本/效益分析。
逻辑模型
理 导解 需 出求 表 达 需 求
目标系统
具体化
物理模型
实例化
逻辑模型
2.3.2 需求分析的过程（四个方面）
★问题识别 ★分析与综合 ★编制需求分析阶段的文档 ★需求分析评审
(1) 问题识别 从系统的角度来理解软件并评审软件范围是否恰 当 确定对目标系统的综合要求，即软件的需求 提出这些需求实现条件，以及需求应达到的标准
第二章
软件需求分析
C2 需求分析
需求分析要求详细、准确地分析清楚 系统必须“做什么”，它是关系到软件开 发成败的关键阶段。在需求分析阶段，需 要用到各种方法、技术和工具等。通常把 一整套需求规格说明的方法、技术、图形 工具以及相应的软件工具的集合称为建模 方法。 结构化方法 面向对象方法
1
2.1 目标
10
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（3）导出新系统的高层逻辑模型 通过前一步的工作，分析员对目标系统应有 的基本功能和所受的约束已有一定了解，能 够使用数据流图描绘数据在系统中流动和处 理的情况，从而概括地表达他对新系统的设 想。通常为了把新系统描绘得更清晰准确， 还应有一个初步的数据字典，定义系统中使 用数据。数据流图和数据字典共同定义了新 系统的逻辑模型，以后可从这个逻辑模型出 发设计新系统。
14
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（7）草拟开发计划 开发计划除了制定工程进度表之外还 应该估计对各类开发人员和各种资源等的需 要情况，该指明那些时候使用以及使用多长 时间。此外还应估计系统生命周期每个阶段 的成本。最后应该给出下一个阶段（需求分 析）的详细进度表和成本估计。 （8）书写文档提交审查 应该把上述可行性研究各个步骤的工作 结果写成清晰的文档，请用户、客户组织的 负责人及评审组审查，以决定是否继续这项 工程及是否接受分析员推荐的方案。
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
16
处理 输入/输出
库存更新事务
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
8
2.2.3可行性分析基本步骤 （1）复查系统规模和目标 分析员访问关键人员，仔细阅读和分析 有关的材料，以便对问题定义阶段书写的关 于规模和目标的报告书进行进一步复查确 认，改正含糊或不确切的叙述，清晰地描述 对目标系统的一切限制和约束。这个步骤的 工作，实质上是为了确保分析员正在解决的 问题确实是要求他解决的问题。
15
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
2.2.4 系统流程图
在进行可行性分析时，首先需要了解现 有物理系统的基本情况，并以概括的形式表 示出来。系统流程图是一种表示物理系统的 传统工具。系统中的各个物理部件通常包括 程序、文件、数据库、表格、人工过程等。 系统流程图表示的是信息在系统各物理 部件之间流动的情况，而不是对信息进行加 工处理的控制过程。
11
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
（4）进一步定义问题 新系统的逻辑模型实质上表达了分析员 对新系统必须做什么的看法。用户是否也有 同样的看法呢？分析员应该和用户一起再次 复查问题定义、工程规模和目标，这次复查 应该把数据流图和数据字典作为讨论的基础。 若分析员对问题有误解或者用户曾经遗漏了 某些要求，那么现在是发现和改正这些错误 的时候了。
4
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
对每种解法都应该仔细研究它的可行 性，一般说来，至少应该从技术、经济和操 作三方面研究每种解法的可行性。 (1)技术可行性 使用现有的技术能实现这 个系统吗? (2)经济可行性 这个系统的经济效益能超 过它的开发成本吗? (3)操作可行性 系统的操作方式在这个用 户组织内行得通吗? 必要时还应该从法律、社会效益等更广 泛的方面研究每种解法的可行性
库存清单程序
库存清单 文件
订货信息
报告生成程序
订货报告
17
C2 需求分析
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
系统流程图要点
对于比较复杂的系统，可以采用分层 的方法。首先，用一张系统流程图在高层 次上描绘系统的整体概貌，体现系统的关 键功能。然后，将每个关键功能扩展到一 定的详细程度，绘制成单独的一张图。
2.1 目标 --任务 --内容 --基本步骤 --系统流程图
2.2 可行性分析
2.3 需求分析
2.4 需求收集
2.5 需求规格说 明
2.6 数据流建模
6
2.2.2可行性分析的内容
（2）技术可行性 是对特定的技术解决方案的实用性和技 术资源的可用性的量度。通常说来，人们喜 欢追逐新技术以解决他们碰到的实际问题。 比如，随着语音识别技术的日益成熟并走向 实用，人们可以考虑把语音识别技术作为将 要开发的系统的一部分。但技术上是否已经 实用化则是一个必须注意的问题，技术资源 (比如掌握这种技术的人力资源)是否可以获 得则是另外一个问题。