软件工程第四讲需求分析
软件工程第2篇-第4章 需求分析
2014-11-3
17
©曲阜师范大学计算机科学学院
第四章 结构化需求分析
4.2.1.4 实体-联系图的符号 使用实体 - 联系图（ Entity-Relationship Diagram）来建立 数据模型。可以把实体联系图简称为ER图，相应地把用ER图 描绘的数据模型称为ER模型。
2014-11-3
2014-11-3
13
©曲阜师范大学计算机科学学院
第四章 结构化需求分析
4.2 面向数据流的结构化需求分析方法
结构化分析方法的雏形出现于20世纪60年代后期。直到 1979年才由DeMarco将其作为一种需求分析方法正式提出。 20世纪80年代中后期，Ward & Hatley和Hatley & Pirbhai在结 构化分析方法中引入了实时系统分析机制，Harel等人研制了 面向复杂实时反应式系统的开发环境STATEMATE 。 结构化需求分析过程是通过建立三种模型来诠释，它们
18
©曲阜师范大学计算机科学学院
第四章 结构化需求分析 4.2.1.5 数据规范化
通常用“范式（Normal Forms）”定义消除数据冗余的程度。第
一范式（1 NF）数据冗余程度最大，第六范式（6 NF）冗余程度最小。
从实用角度来看，在大多数场合选用第三范式比较恰当。
1. 第一范式 无重复的列。 2. 第二范式 完全依赖于主键[消除非主属性对主键的部分函数依赖]。 3. 第三范式 不依赖于其它非主属性[消除传递依赖]。
2014-11-3
21
©曲阜师范大学计算机科学学院
第四章 结构化需求分析 4.2.2.4 举例
2014-11-3
22
©曲阜师范大学计算机科学学院
软件工程--需求分析
软件工程--需求分析软件工程需求分析在软件工程的领域中，需求分析是整个项目开发过程中至关重要的环节。
它就像是一座大厦的基石，如果基石不稳，整座大厦都可能摇摇欲坠。
简单来说，需求分析就是要弄清楚软件需要做什么，为谁而做，以及要达到什么样的效果。
需求分析的第一步，是明确软件的目标用户群体。
比如说，我们要开发一个在线学习平台，是面向小学生、中学生还是大学生？是为了提供课程辅导，还是为了培养兴趣爱好？不同的用户群体有着不同的需求和使用习惯。
如果把这个平台定位为小学生使用，那么界面就需要简洁明了、色彩鲜艳，操作要简单易懂；如果是面向大学生，可能就需要更多的专业课程资源和深入的学习功能。
接下来，要深入了解用户的具体需求。
这可不是简单地问问用户想要什么就行了，而是要通过各种方法去挖掘他们潜在的、真正的需求。
比如，可以进行用户访谈，和他们面对面交流，了解他们在学习过程中的痛点和期望；也可以进行问卷调查，收集大量的数据进行分析；还可以观察用户在现有类似平台上的行为，从中发现问题和改进的方向。
举个例子，如果我们要开发一个购物软件，用户可能会说希望能快速找到想要的商品，这只是表面需求。
进一步挖掘，我们会发现他们其实更希望有精准的搜索功能、个性化的推荐，以及清晰的商品分类和详细的商品信息。
这些才是用户真正关心的，也是我们在需求分析中要重点关注的。
在需求分析中，还需要考虑软件的使用场景。
是在移动端使用，还是在电脑端？是在有网络的环境下，还是离线也能使用？不同的使用场景会对软件的功能和性能产生不同的要求。
比如，一个在户外使用的地图导航软件，就需要具备离线使用的功能，并且要能快速定位和加载地图。
同时，要明确软件需要具备哪些功能。
这包括基本功能和扩展功能。
以一个社交软件为例，基本功能可能是添加好友、发送消息、分享动态等；扩展功能可能是群组聊天、视频通话、直播等。
在确定功能时，要权衡功能的必要性和实现的难度，不能一味追求功能的丰富而忽略了项目的可行性和成本。
软件工程需求分析(精品PPT)
•将功能和信息结构分配到这些系统元素中 •需求分析的任务
•深入描述软件的功能和性能 •确定软件设计的约束和软件同其它系统元素的接口细节
•定义软件的其它有效性需求
第四页，共七十七页。
需求(xūqiú)分析的具体任务
•需求分析阶段的具体任务：
•确定对系统的综合要求
•系统功能要求
第四章 析根底
软件工程 需求分 (ruǎn jiàn ɡōnɡ chénɡ)
第一页，共七十七页。
第四章 需求分析 根底 (fēnxī)
• 需求(xūqiú)分析的任务与原那么〔重点〕 • 需求分析的任务 • 需求分析的过程 • 软件需求分析的原那么 • 初步需求获取技术 • 需求建模〔重点〕 • 问题抽象、问题分解与多视点分析 • 支持需求分析的快速原型技术 • 需求规格说明书
第二十六页，共七十七页。
教务管理系统调查分析过程 1、认真学习教务管理方面的知识，重点掌握其中
的名词和术语 2、收集目前教务管理方面资料和软件，了解其特
•了解系统的需求 •软件开发是系统开发的一局部,仔细分析研究系统的需求 规格说明,对软件的需求获取是很有必要的
第十六页，共七十七页。
✓需求调查对象
对组织的高层管理者，进行组织管理目标或经营方 针等组织战略问题的调查
对中层的管理者，进行全部业务流的调查 对业务工作人员，进行详细业务信息的调查
✓市场调查 了解市场对待开发软件有什么样的要求；了解市场上 有无与待开发软件类似的系统
第十页，共七十七页。
需求(xūqiú)分析流程
第十一页，共七十七页。
软件需求(xūqiú)分析的原那么
1、需要能够表达和理解问题的信息域和功能域 信息域应包括：
软件工程中的需求分析步骤解析(四)
软件工程中的需求分析步骤解析随着科技的不断发展，软件在我们日常生活中扮演着越来越重要的角色。
软件的巨大变革和逐渐普及带来了一个严峻的问题，那就是如何满足用户的需求。
恰当而有效的需求分析是成功软件开发的关键步骤之一。
本文将从需求分析的定义出发，详细探讨软件工程中的需求分析步骤。
1. 需求分析的定义需求分析是软件开发的一项重要工作，旨在通过调研、分析和整理用户的需求，以确定软件开发的具体目标和功能。
需求分析的核心是识别问题和需求，为软件开发的后续步骤提供准确的需求说明。
通过需求分析，可以确保软件开发过程中保持目标的一致性，使得最终产品能够满足用户的期望。
2. 需求分析的步骤需求收集需求收集是需求分析的第一步，它涉及与用户、客户和相关利益相关者进行沟通和交流，以了解软件开发的具体需求。
常见的需求收集方法包括面对面访谈、问卷调查、观察用户行为和分析用户反馈等。
通过这些方法，可以获取用户的真实需求和期望，为后续的需求分析提供基础数据。
需求整理需求整理是将收集到的需求进行整理、分类和排序的过程。
通过对需求的整理，可以清晰地了解用户的主要需求和优先级，并将其转化为具体的需求文档或需求模型。
需求整理过程中，可以采用需求图、用例图等工具来可视化需求，并与用户深入讨论和验证。
需求分析与规划需求分析与规划是对整理后的需求进行深入分析和评估，以确定软件开发的实际可行性和可行方案。
在需求分析与规划阶段，可以采用目标树、时序图等工具，识别潜在的风险和问题，并制定相应的解决方案。
通过需求分析与规划，可以确保软件开发过程的有效管理和资源分配。
需求验证与确认需求验证与确认是通过与用户、客户和相关利益相关者进行沟通和交流，验证和确认软件开发的需求是否符合用户的期望。
在这一步骤中，可以使用原型、模拟演示等方式来展示软件的功能和特性，并与用户共同讨论和修改。
通过需求验证与确认，可有效减少后期开发过程中的返工和修改，提高软件的质量和用户满意度。
软件工程——4.需求分析基础
软件工程——4.需求分析基础软件工程——4.需求分析基础1. 引言需求分析是软件工程中非常重要的一个阶段，它是确定软件系统应该做什么以及用户的期望和需求的过程。
该文档将介绍需求分析的基础知识和方法。
2. 需求分析的定义和目的需求分析是软件开发过程中的第一步，其主要目标是确定软件系统的功能和约束。
通过需求分析，可以明确软件系统的用户需求、业务需求和技术需求，为后续的设计、开发和工作提供基础。
需求分析的主要内容包括以下几个方面：- 用户需求的获取：通过与用户沟通、观察和调研等方式，获取用户对软件系统的期望和需求。
- 需求的分析和整理：对收集到的需求进行分析和整理，理清具体的功能和约束。
- 需求的验证和确认：与用户反复沟通，确保需求的准确和完整。
3. 需求分析的基本原则在进行需求分析时，需要遵循以下基本原则：3.1 明确需求的来源需求的来源可以是用户的需求、企业的需求、法律法规等。
需要明确需求的来源，以便更好地理解需求并确保满足各方的期望。
3.2 分析需求的重要性和优先级不同的需求具有不同的重要性和优先级。
需求分析人员需要根据实际情况，确定哪些需求是最重要的，哪些是次要的，以便在后续的开发过程中进行合理的资源分配。
3.3 避免冗余和矛盾的需求在需求分析过程中，可能会出现冗余和矛盾的需求。
需求分析人员需要及时发现和排除这些问题，确保需求的一致性和合理性。
3.4 考虑可行性和可实现性在进行需求分析时，需要考虑所提出的需求是否可行和可实现。
如果某个需求无法满足技术或资源上的限制，需要及时与用户沟通，并寻求解决方案。
4. 需求分析的常用方法需求分析的方法有很多种，下面介绍几种常用的方法：4.1 用户访谈用户访谈是获取用户需求的主要方法之一。
需求分析人员可以通过与用户面对面的交流，了解用户对软件系统的期望和需求。
4.2 原型设计原型设计是一种以图形表示的方法，用于展示软件系统的界面和功能。
通过原型设计，用户可以更直观地看到软件系统的样貌，从而更好地理解和确认需求。
软件工程-需求分析
软件工程-需求分析软件工程-需求分析1. 引言2. 需求分析的重要性需求分析是软件工程开发过程中的第一步，其重要性体现在以下几个方面：2.1 确定项目目标与范围在需求分析阶段，通过与用户和相关利益相关方的沟通和交流，可以明确项目的目标与范围。
这有助于开发团队理解用户的需求，明确系统的功能和约束，确保项目的成功实施。
2.2 识别和定义系统需求通过需求分析，可以识别和定义系统的需求。
这包括功能需求、非功能需求以及性能需求等。
明确系统需求有助于后续的设计和开发工作，避免后期的返工和调整。
2.3 提高开发效率通过需求分析，可以避免需求方面的误解和偏差，减少开发过程中的不必要的沟通和调整。
这有助于提高开发效率，减少项目的开发周期和成本。
3. 需求分析的过程需求分析的过程包括以下几个步骤：3.1 需求获取需求获取是需求分析的第一步，主要是通过与用户和相关利益相关方的沟通和交流来收集和获取需求。
常用的需求获取方法包括面对面访谈、问卷调查、用户观察等。
3.2 需求分析与整理在需求获取的基础上，需求分析人员将获取到的需求进行分析与整理，辨识出主要和次要需求，并对其进行详细描述和分类。
3.3 需求验证需求验证是确认需求的正确性和可行性。
这可以通过与用户和相关利益相关方进一步的讨论和确认来完成。
验证需求的过程中，需求分析人员需要与开发人员密切合作，确保需求的准确理解和实现。
3.4 需求文档编写在需求验证完成后，需求分析人员需要将需求整理成文档的形式，以便于记录和交流。
需求文档应该包括需求的详细描述、功能需求、非功能需求、系统界面设计等内容。
4. 需求分析方法和工具需求分析方法和工具可以帮助分析人员更好地完成需求分析工作。
以下是一些常用的需求分析方法和工具：4.1 UML建模UML（Unified Modeling Language）是一种常用的建模语言，可以通过用例图、活动图、类图等来描述系统需求，辅助需求分析和系统设计工作。
软件工程_需求分析
软件工程_需求分析软件工程需求分析一、介绍需求分析是软件工程中的关键步骤，它的目标是确定软件系统的需求，确保开发团队和利益相关者对软件系统的功能和性能有清晰的理解。
本文档旨在详细描述软件工程需求分析的过程和方法，以帮助开发团队准确理解和定义软件系统的需求。
二、需求概述1.目标和范围描述软件系统的主要目标和范围，包括系统的预期功能、性能要求、适用范围等。
2.相关方列出与软件系统相关的各方利益相关者及其角色和职责，确保他们的需求得到满足。
三、用户需求分析1.需求收集收集利益相关者的需求，包括用户的功能需求、性能需求、操作需求等。
2.需求整理和优先级确定将收集到的用户需求进行整理和分类，确定各需求的优先级，以确定开发的重点和轻重缓急。
3.需求规约详细描述每个需求的具体内容和所需实现的功能，并根据可行性进行评估和规范。
四、系统需求分析1.功能需求根据用户需求分析的结果，将各个功能需求进行进一步细化和明确化，确保每个功能需求都能得到准确描述和定义。
2.性能需求定义系统的性能要求，包括响应时间、吞吐量、并发性等方面的要求，并进行可行性分析。
3.交互需求描述系统与用户的交互界面，包括用户界面的设计、用户操作的流程等。
4.数据需求定义系统需要存储和处理的数据，包括数据类型、数据格式、数据存取方式等。
五、约束与假设1.技术约束描述软件开发和使用过程中的技术限制和要求，包括硬件环境、软件平台、开发工具等。
2.时间约束确定软件开发和交付的时间要求，包括截止日期、里程碑等。
3.预算约束定义项目的预算限制，包括开发成本、运营成本等。
4.假设与依赖描述系统开发和使用过程中的假设和依赖条件，包括其他系统的兼容性、外部资源的可用性等。
六、附件本文档所涉及的附件详见附件部分。
七、法律名词及注释在本文档中涉及的法律名词和相关注释详见法律名词及注释部分。
软件工程的需求分析
软件工程的需求分析引言需求分析是软件工程中非常重要的一环，通过对用户需求的准确理解和详细描述，可以帮助开发团队有效地开展软件开发工作。
在软件工程的整个生命周期中，需求分析是其中最具挑战性和复杂性的阶段之一。
本文将介绍需求分析的概念、流程、方法以及其中所涉及的挑战和解决方案。
需求分析的概念需求分析是指通过对用户需求的调研、理解和整理，将用户的需求转化为可实施和可测试的需求规格说明。
需求分析旨在准确地描述软件系统需要满足的功能和性能要求，以及与系统交互的各种行为。
这对于开发团队来说至关重要，因为软件的最终成果必须满足用户的需求，才能被认为是成功的。
需求分析的流程需求分析可以分为几个关键步骤，包括需求收集、需求分析、需求确认和需求文档编写。
在需求收集阶段，通过与用户的沟通和调研，收集用户需求的详细信息。
需求分析阶段是对收集到的需求进行整理、分析和澄清，以便更好地理解和描述用户的需求。
需求确认阶段是与用户沟通和讨论，确保对需求的理解和描述是准确无误的。
将需求编写成规范的需求文档，供开发团队参考和开展后续的工作。
需求分析的方法需求分析涉及到一系列的工具和方法，以帮助开发团队更好地理解和描述用户的需求。
其中，常用的方法包括面谈法、问卷调查、原型设计和用例建模等。
面谈法通过与用户面对面的交流，获取用户需求的详细信息。
问卷调查则是通过发放问卷，了解大量用户的需求和期望。
原型设计是通过设计一个初步的软件原型，让用户参与评审，以更好地理解用户需求。
用例建模则是通过对用户典型行为的建模来描述用户需求和系统的交互过程。
需求分析中的挑战和解决方案需求分析在实践中常常面临一些挑战，如用户需求的模糊性、需求变更的频繁性和需求冲突的存在等。
为了解决这些挑战，需要采用一些解决方案。
要通过与用户的充分沟通和理解，尽可能减少需求的模糊性。
要建立灵活的需求管理机制，以便及时处理需求的变更和冲突。
还可以采用迭代开发的方法，将需求分析工作分解为多个小的迭代任务，以逐步完善需求规格。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
情况下的选课持续时间、是否按院系逐步开放选科、 选课人数的一般分布等—与性能设计密切相关 推荐关键管理人员使用USB Key设备，经济上是否可 以接受 ……
原型：如该企业有类似成熟系统可结合系 统演示进行需求调研
3.2.4 观察并记录商业过程(I)
观察 使用活动图来进行记录
学生购买教材的实际处理流程—当前系统物理模型 购 书 购 领 发 申 书 书 学 请 教务科 单 会计室 票 出纳员 单 教材科 书 学 108 107 206 206 生 生 赵 张 王 李 购 书 购 领 发 申 书 书 书 票 单 学 请 审查 单 学 开领 开发票 发书 生 有效性 书单 生
3.2.1 主要问题
主题 对用户来说的问题 商业过程和操作是什 你要干什么 么 商业过程应该怎样完 如何完成它？需要哪些步骤？ 成 需求什么样的信息 你要使用哪些信息？你要使 用什么样的表单或报告？
表 信息收集中的主要问题
3.2.2 复查报表、表格和过程描述
商业文档和过程描述是了解过程的一个好 方法。
第二阶段：制订访谈计划，深入讨论 相关需求
除了学生还有哪些相关用户?
选课规则(学分、课程人数限制等)、退课规则
了解客户对系统的期望：准确、访问速度快… ……
需求调研例—学生选课系统-2
第三阶段：基本了解需求后就一些关键细 节通过问卷进行明确
在已经了解总体选课人数之后，需要进一步了解通常
表格和报表可以为面谈提供可视化的帮助、 也可以提供工作文档。 复查现有过程文档将有助于识别面谈中不 会提及的商业规则。 有助于发现商业过程中的不一致和冗余。
3.2.3 面谈
面谈之前 确立面谈目的 确定要包括的相关用 户 确定参加会议的项目 小组成员 建立要讨论的问题和 要点列表 复查有关文档和资料 确立时间和地点 通知所有参加者有关 会议的目的、时间和地 点 进行面谈 衣着得体 准时到达 寻找异常和 错误情况 深入调查细 节 详细记录 找出和记录 未回答的条目 和未解决的问 题
数据模型中包含3种相互关联的信息：实体、 属性、联系
3.3.1 实体模型的概念(I)
• 实体：指客观世界存在的且可以相互区分的事务。 实体可以是人，也可以是物，还可以是抽象概念。 如职工、计算机、产品等都是实体。
• 属性：是指实体某一方面的特征。一个实体通常 由多个属性值组成，如学生实体具有学号、姓名、 专业、年级等属性。 • 联系：指实体之间的相互关系。 • 注意，联系也可以有属性。比如成绩既不是 学生的属性，也不是课程的属性，而是学生“学” 课程的属性，这个属性就是联系“学”的属性。
3.2.4 观察并记录商业过程(II)
3.2.5 建立原型
3.2.6 分发和收集调查表
举例：某出版社系统需求调查表
编号
1 2 3 4 5
提出问题 您在哪个部门工作？ 出版业务流程是什么？ 您每日都处理那些文件、数据、报表？ 工作中手工处理特别麻烦的事情是什么？ 工作中手工处理什么问题解决不了？影响效率的问题有哪 些？
闲置
摘机 拨号音 do：响拨号音 数字 数字 超时 超时 提示信息 do：播放信息 超时 do：响蜂鸣音
挂 机
挂 机
忙音 do：响忙音
无效号码 拨号 有效号码
占线
接通中 do：试接通
已接通 振铃 do：振铃 受话人摘机应答 通话 受话人挂机 断线
信 息 播 完
练习：办公室复印机的工作过程大致 如下：
3.1.2 逻辑模型
数据模型（ERD） 功能模型（DFD） 行为模型（状态转换图）
3.1.3 修正系统开发计划
根据在分析过程中获得的对系统的更深入 更具体的了解，可以比较准确地估计系统 的成本和进度，修正以前制定的开发计划。
3.2 信息收集技术
3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9 主要问题 复查现有报表、表格和过程描述 访谈 观察并记录商业过程 建立原型 分发收集调查表 主持联合应用程序设计会议 面向数据流分析 简易规格说明书
项目名称 项目编号 开工日期 供应商编号
供应商名称 地址
工程项目 M 供应量 供应 N 零件 N
供应商 M 订购 订购量
零件编号
零件名称
3.4 功能模型(I)
基本加工逻辑说明 对数据流图的每一个基本加工，必须有 一个基本加工逻辑说明 基本加工逻辑说明必须描述基本加工如 何把输入数据流变换为输出数据流的加 工规则 加工逻辑说明必须描述实现加工的策略 而不是实现加工的细节 加工逻辑说明中包含的信息应是充足的， 完备的，有用的，无冗余的
通过描绘系统的状态及引起系统状态转换的事件来表示 系统的行为。
状态 do：动作
系统行为模式 do：在该状态下的动作 引起系统状态转换的控制信息
事件
STD中使用的主要符号
初始事件
状态1 do：行为1
事件1[条件1]
状态2 do：行为2
事件2[条件2]
结束事件
……
【例】电话系统的状态转换图
实发 工资
4.3.1.1 实体关系图
应发 工资 扣款 基本 工资 奖 金 水电 扣款 缺勤 扣款 个人 所得 税扣 款
3.3.1 实体模型的概念(II)
联系可分为以下3种类型：
(1) 一对一联系(1∶1)
(2) 一对多联系(1∶N) (3) 多对多联系(M∶N)
3.3.3 ERD实例(I)
3.3.3 ERD实例(II)
习题. 请为某仓库的管理设计一个ER模型。 该仓库主要管理零件的订购和供应等事项。 仓库向工程项目供应零件，并且根据需要 向供应商订购零件。
3.4 功能模型(II)
基本加工逻辑说明工具
结构化英语 判定表 判定树
3.5 状态转换图(I)
状态转换图(简称为状态图)通过描绘系统的 状态及引起系统状态转换的事件，来表示 系统的行为。 3.5.1 状态 3.5.2 事件 3.5.3 符号
（3）状态转换图（State Transition Diagram）
3.7 其他图形工具
3.7.1 层次方框图 3.7.2 Warnier图 3.7.3 IPO图
3.7.1 层次方框图(I)
层次方框图用树形结构的一系列多层次的 矩形框描绘数据的层次结构。
例如，描绘一家计算机公司全部产品的数 据结构可以用图3.5中的层次方框图表示。
3.7.1 层次方框图(II)
突出优点：开发者与用户不分彼此，齐心协力， 密切合作；即时讨论并求精；有能导出规格说明 的具体步骤。
分组讨论
为《社交故事管理系统》设计信息 收集方案 时间：20分钟
3.3 ERD(I)
分析建模方法：
数据模型：ERD(实体联系图) 功能模型：DFD(数据流图)
行为模型：STD(状态转换图)
3.1.1 需求内容 3.1.2 逻辑模型 3.1.3 修正系统开发计划
需求包括的内容
(1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) 功能 系统做什么？ 性能 软件开发的技术性指标 系统何时做什么？ 环境 硬件设备 存储容量限制 系统何时及如何修改或升级？ 接口 有来自其它系统的输入吗？ 机型、外设、接口、地点、分布、 执行速度、响应时间 用户或人的因素 用户类型？ 到自其它系统的输出吗？ 温度、湿度、磁场干扰等 吞吐量 文档 对数据格式有规定吗？ 各种用户熟练程度？ 软件 系统的可靠性要求？ 数据 需哪些文档？ 对数据存储介质有规定吗？ 需对访问系统或系统信息加以控 资源 需受何种训练？ 操作系统、网络、数据库 系统必须监测和隔离错误吗？ 文档针对哪些读者？ 输入、输出数据的格式？ 安全保密 制吗？ 用户理解、使用系统的难度？ 规定系统平均出错时间？ 软件运行时所需的数据、软件、 接收、发送数据的频率？ 软件成本消耗与开发进度 如何隔离用户之间的数据？ 用户错误操作系统的可能性？ 出错后，重启系统允许的时间？ 内存空间等资源 数据的准确性和精度？ 质量保证 系统变化如何反映到设计中？ 用户程序如何与其它程序和操作 开发有规定的时间表吗？ 软件开发、维护所需的人力、支 数据流量？ 开发进度 系统隔离？ 软硬件投资有无限制？ 维护是否包括对系统的改进？ 撑软件、开发设备等 数据需保持的时间？ 系统的可移植性？ 系统备份要求？
3.2.7 主持联合应用程序设计会议
JAD的目的是把所有这些活动压缩为用户 和项目小组成员一起参加得更短的JAD会 议。 参加人员：
JAD会议领导者 用户 技术人员 项目组成员
3.2.8 面向数据流自顶向下求精
数据流图是帮助复查的极好工具。
从输入端开始，分析员借助数据流图、数 据字典和IPO图向用户解释输入数据是怎 样一步一步地转变成输出数据的。 这些认识正确吗?有没有遗漏?用户应该注 意倾听分析员的报告，并及时纠正和补充 分析员的认识。复查过程验证了已知的元 素，补充了未知的元素，填补了文档中的 空白。
(1) 必须理解并描述问题的信息域，根据这条
准则应该建立数据模型。 (2) 必须定义软件应完成的功能，这条准则要 求建立功能模型。 (3) 必须描述作为外部事件结果的软件行为， 这条准则要求建立行为模型。 (4) 必须对描述信息、功能和行为的模型进行 分解，用层次的方式展示细节。
3.1 需求分析的任务
面谈之后 复查笔记的准确性、 完整性和可理解性 把所收集的信息转 化为适当的模型和 文档 确定需要进一步澄 清的问题域 适当的时间向参加 会议的每一个人发 一封感谢信