软件需求分析建模
需求分析建模实验报告
需求分析建模实验报告1. 引言需求分析是软件开发生命周期中非常重要的一个阶段，通过需求分析可以明确系统的功能和性能要求，并为后续的开发、测试、部署等工作提供基础。
在需求分析过程中，采用合适的建模方法有助于准确描述系统的需求，识别并解决潜在的问题。
本实验旨在通过需求分析建模实践，提高对需求分析过程和技术的理解和应用能力。
2. 实验目的- 掌握需求分析建模的基本概念和方法；- 学习使用UML建模语言描述系统需求；- 提高对需求获取、分析和建模能力。
3. 实验环境- 操作系统：Windows 10- 工具软件：Visual Paradigm4. 实验内容本实验选择一个实际案例进行需求分析建模，详情如下：4.1 项目背景某在线购物平台开发团队决定对其系统进行升级，以提供更好的用户体验和功能。
升级后的系统将包括商品浏览、购物车管理、订单管理等模块。
4.2 需求获取通过与平台运营团队沟通和观察用户行为，获取以下需求：1. 用户可以通过平台浏览商品，包括商品的名称、价格、库存等信息；2. 用户可以将商品加入购物车，并对购物车中的商品进行管理（增删改查）；3. 用户可以对购物车中的商品进行结算，生成订单，并选择支付方式；4. 用户可以查看历史订单和订单详情。
4.3 需求分析建模在实验过程中，通过Visual Paradigm工具进行建模，选择了以下几个UML图形进行需求分析建模：1. 用例图：用于识别和描述系统的功能需求，并展示功能间的关系；2. 类图：用于描述系统中的类和类之间的关系，以及类的属性和方法；3. 活动图：用于描述系统的业务流程，展示各个活动的先后顺序和逻辑关系。
4.4 实验步骤1. 利用Visual Paradigm创建新项目，选择用例图模板；2. 根据需求获取的内容，识别系统的功能需求，并创建相应的用例图；3. 根据用例图创建类图，描述系统中的类和类之间的关系；4. 根据用例图创建活动图，描述系统的业务流程；5. 验证建模结果的正确性和完备性。
面向对象的软件开发过程中的需求分析与建模研究
面向对象的软件开发过程中的需求分析与建模研究第一章引言随着信息技术的快速发展，软件已逐渐成为了现代社会不可或缺的组成部分。
而软件开发过程中的需求分析与建模是确保软件开发质量的重要步骤，因此在面向对象的软件开发中，需求分析与建模研究具有重要的意义和价值。
本文将从面向对象的软件开发出发，介绍需求分析和建模的概念、方法和工具，并重点探讨基于面向对象的软件开发过程中的需求分析与建模研究。
第二章面向对象的软件开发面向对象的软件开发是一种软件开发方法，它以对象为中心，实现了软件的高内聚、低耦合和易维护性，具有较高的开发效率和软件重用性。
在面向对象的软件开发中，需求分析和建模是其中的关键环节。
基于面向对象的软件开发过程主要包括以下几个阶段：1.需求分析阶段。
在该阶段中，需求分析人员将收集和分析用户和系统需求，以确定软件开发的需求和目标。
2.设计阶段。
在设计阶段中，设计人员将根据需求分析阶段的结果，设计面向对象的软件系统架构和对象模型。
3.编码和测试阶段。
在这个阶段中，开发人员将根据设计人员的指示开发代码和进行测试，以确保软件能够按要求正确运行。
4.部署和维护阶段。
在这个阶段中，开发人员将软件部署到用户环境中，并进行维护和修复错误。
在整个软件开发过程中，需求分析和建模是相互关联、相互作用的关键环节。
第三章需求分析与建模基础知识3.1 需求分析需求分析是软件开发的首要任务，它是确保软件开发符合用户需求的前提条件。
需求分析包括两个方面，即功能需求和非功能需求。
1.功能需求功能需求是软件开发中最基本的需求，它是用户对软件功能的具体要求。
在软件开发中，功能需求可以通过用例图、活动图、状态图和顺序图等方法进行描述和分析。
2.非功能需求非功能需求是软件开发中的另一个重要因素，它主要描述软件的性能、可靠性、安全性、可维护性和可移植性等方面的要求。
常用方法包括场景模型、质量属性树和系统特征模型等。
3.2 需求建模需求建模是将需求分析的结果转换为相应的模型，以便于软件设计和开发人员的理解和使用。
软件工程中的软件需求建模与验证
软件工程中的软件需求建模与验证在软件工程领域中，软件需求建模与验证是非常重要的环节。
通过对软件需求的建模与验证，可以帮助开发团队实现对用户需求的准确理解，规避项目风险，提高软件质量。
本文将对软件需求建模与验证进行探讨，介绍其意义、常用方法以及实施过程中需要注意的事项。
一、软件需求建模的意义软件需求建模是指将用户需求转化为易于理解、易于分析的建模表示形式的过程。
它的意义主要体现在以下几个方面：1. 精确理解用户需求：用户需求通常是非结构化的，通过建模可以将其转化为结构化的表示形式，从而更好地理解用户需求的具体内容。
2. 消除需求的二义性：在软件开发过程中，需求二义性可能导致开发人员对用户需求理解存在偏差，从而产生错误的设计。
通过建模，可以减少需求的二义性，确保需求准确无误。
3. 支持复杂系统的设计与开发：对于复杂的软件系统，建模可以帮助开发人员更好地理解系统的结构与功能，从而更好地进行系统设计与开发。
二、软件需求建模方法在软件需求建模中，常用的方法包括数据流图、用例图等。
1. 数据流图（DFD）：数据流图是一种图形化表示方法，通过展示系统内部外部的数据流与处理过程来描述软件系统的功能与数据交互。
在数据流图中，数据流由数据流向箭头表示，处理过程由方框表示，外部实体由圆形表示。
2. 用例图（Use Case Diagram）：用例图是一种图形化表示方法，用于描述系统与外部实体之间的交互关系。
在用例图中，系统由矩形表示，外部实体由椭圆形表示，用例由椭圆形与直线表示。
三、软件需求验证的方法软件需求验证是指通过一系列的过程与活动，确保软件需求的正确性与合理性。
常用的软件需求验证方法包括软件检查、测试、原型等。
1. 软件检查：软件检查是通过审查软件需求文档，以发现并纠正其中的错误、遗漏和不一致之处。
软件检查可以由项目团队内部成员进行，也可以由外部的专业人士进行。
2. 软件测试：软件测试是通过执行各种测试用例，以发现软件需求与实际软件系统之间的差异，并对其进行评估。
软件需求工程中的模型及分析方法
软件需求工程中的模型及分析方法在软件开发中，软件需求工程是非常重要的一环，因为在这个阶段确定的需求将直接影响后续的软件设计和开发。
而模型及分析方法是软件需求工程的重要工具，它们可以帮助开发人员深入了解用户需求，更好地完成软件开发任务。
本文将围绕软件需求工程中的模型及分析方法展开讨论。
一、模型及其类型模型是对实际系统或过程的一种抽象表示，它可以帮助开发人员更好地理解和分析软件需求，在需求工程中常用的模型包括以下几种：1.1 静态模型静态模型是对系统或过程中的元素及其关系的表示，它们的变化不随时间而定。
在需求工程中常用的静态模型包括数据流图、结构图、实体关系图等。
数据流图可以表示系统中的数据输入、输出以及数据处理过程，它可以帮助开发人员更好地理解数据流动的过程。
结构图可以表示系统中的模块和模块之间的关系，它可以帮助开发人员更好地理解模块之间的交互。
实体关系图可以表示系统中不同实体之间的关系，它可以帮助开发人员更好地理解实体之间的交互。
1.2 动态模型动态模型是对系统或过程中的操作及其变化的表示，它们的变化随时间而定。
在需求工程中常用的动态模型包括状态图、活动图、时序图等。
状态图可以表示系统中不同状态之间的转换，它可以帮助开发人员更好地理解系统状态的变化。
活动图可以表示系统中各种活动的执行过程，它可以帮助开发人员更好地理解系统中不同活动之间的关系。
时序图可以表示系统中事件之间的时间顺序，它可以帮助开发人员更好地理解系统中不同事件的执行顺序。
1.3 物理模型物理模型是对系统或过程中的物理组件及其关系的表示，它们通常与硬件和软件的配合使用。
在需求工程中常用的物理模型包括部署图、机房图等。
部署图可以表示不同硬件之间的连接和通信，它可以帮助开发人员更好地理解系统中不同硬件之间的配合。
机房图可以表示不同设备在机房内的位置和连接方式，它可以帮助开发人员更好地理解机房中各种设备的位置关系。
二、分析方法及其应用分析方法是针对需求进行深入分析的方法，通过分析可以更好地理解用户需求并确定需求的可行性。
软件需求分析建模
小结
在需求获取和分析过程中，要对问题进行 评估，对方案进行综合。在整个过程中，分 析师关注的焦点是“做什么”，而不是“怎 么做”，系统必须完成什么功能，会产生什 么数据，将定义什么界面，会遇到什么约束 等。
总之，在这一阶段主要经历集中在获取和 分析系统的逻辑功能上。不要把“用计算机 如何实现”这样的物理因素牵扯进来，影响 逻辑功能的分析。
需求获取－需求人员
谁参加需求？
角色
职责
需求分析员
客户与最终 用户
项目组
调查、分析用户的需求、定义产品需求、 撰写《用户需求规格说明书》
提供必要的需求信息；确认最终需求
参与需求评审
需求获取－功能
功能性需求
软件必须实现的软件功能
非功能性需求
系统的易用性、反应速度、容错性、健壮性等等质量属性
需求获取－非功能
需求捕获技术－用户访谈
访谈开始和结束
陈述访谈的目的，谈谈被访谈者关心的事。 讨论他们所熟悉的日常工作的过程。 怎样的变化将使你的工作更简单或更有效？暗
示被访谈者提出改进意见。 当列表中的所有领域都讨论过后，提出下面问
题： “还有什么问题我们没有讨论吗？”或是 “ 我们还需要讨论些别的内容吗？” 结束会谈时，简短的总结讨论过的问题，重点 指出会谈的要点，并说出你的理解。 最后，你必须感谢被访谈者参加这次访谈。
本系统对于用户的需求，在功能上可以进行扩展，能满 足各级财政业务上的需求。
本系统在数据库上可以进行移植，支持Oracle,Sybase等 数据库。
需求获取-功能实例
需求获取—参与者
•谁使用了系统的主要功能？ •谁来维护和管理系统使系统正常工作？
角色及其职责描•哪述些人对系统产生的结果感兴趣？
软件工程中的需求分析与建模
● 03
第3章 需求建模技术
需求建模概述
需求建模是软件工程中的一个重要环节，通过对需求 进行建模，可以更清晰地理解和定义系统需求。需求 建模的目的是为了准确地捕获用户需求，确保软件开 发过程中不会遗漏任何重要需求。同时，需求建模还 可以帮助团队更好地沟通和协作，提高项目的成功率。
用例建模
用例是描述系统功能的一种有效方式。通过用 例建模，可以清晰地定义系统的功能和用户与 系统之间的交互。用例图可以直观地展示系统 的功能和不同用户角色之间的交互关系。用例 描述则详细描述了每个用例的具体行为和步骤。
意度。
需求变更频繁
导致开发过程混乱
需求不明确
影响产品质量
沟通不畅
导致需求误解
面临的挑战
可能的改进方向
采用敏捷开发模式
迭代开发 持续集成 快速反馈
加强需求管理
建立需求数据库 制定明确需求文档 实施变更控制
提高沟通效率
定期沟通会议 使用协同工具 建立需求反馈渠道
展望未来
未来在软件工程领域，人工智能技术的发展将为需求 分析带来更多可能性，大数据技术的应用将提升需求 建模的精度，需求管理工具的不断创新将提高团队效 率。
测试
单元测试 集成测试
软件工程发展历程
软件工程的发展经历了多个阶段，从最初的混沌时期 到逐渐建立起规范的软件开发流程和方法。随着科技 的不断进步，软件工程也在不断演变和完善。
● 02
第二章 需求分析基础
需求分析概述
需求分析是软件工程中至关重要的一部分，它 涉及定义、识别和规范软件开发项目中的需求。 通过需求分析，可以确保开发团队在项目开始 阶段清晰了解客户的需求，明确目标和方向。 需要对需求进行系统性的分析，以确保最终的
第3章软件需求分析与建模
2020/3/7第3章软件需求分析与建模
软件工程教研室
15
①数据模型 描述对象系统的本质属性及其关系。常用的建模工具有 实体-联系图等。 ②功能模型 描述对象系统所能实现的所有功能。而不考虑每个功能 实现的次序。常用的建模工具有数据流图、IDEF0等。 ③行为模型 描述对象系统为实现某项功能而发生的动态行为。常用 的建模工具有控制流图、状态转换图等。
2020/3/7第3章软件需求分析与建模
软件工程教研室
24
X
1
3
2
1.1 1.3 1.2
2.2
2.1
2.3
3.2
3.1
3.3
图3-3 自顶向下逐层分解图
2020/3/7第3章软件需求分析与建模
软件工程教研室
25
结构化分析的过程如下 1．建立当前系统（现在工作方式）的概念模型。系统的 概念模型就是现实环境的忠实写照，可用系统流程图来表 示。这样的表达与当前系统完全对应，用户容易理解。 2．抽象出当前系统的逻辑模型。分析系统的概念模型， 抽象出其本质的因素，排除次要因素，获得用数据流图 DFD 图等描述的当前系统的逻辑模型。 3．建立目标系统的逻辑模型。分析目标系统与当前系统 逻辑上的差别，从而进一步明确目标系统“做什么”，建 立目标系统的“逻辑模型”(修改后的数据流图DFD 图等)。 4．建立人机交互接口和其他必要的模型，确定各种方案 的成本和风险等级，据此对各种方案进行分析，选择其中 一种方案，建立完整的需求规约。 分析模型的结构如图3-4所示。
Y
用户和设计者是否满意
N
运行原型
是否放弃
Y
N
把原型作为 把原型作为应 应用系统 用系统开发的
第6章需求分析与建模
第6章需求分析与建模需求分析与建模是软件开发过程中的重要环节，它是基于用户需求，对系统功能和性能进行细致的分析和建模，以便于后续的系统设计与实现。
本章主要介绍需求分析与建模的概念、方法和工具，以及需求分析与建模的步骤和技巧。
需求分析是软件开发过程中的首要任务，它旨在明确系统的功能需求、性能需求和非功能需求，以及用户对系统的期望和要求。
需求分析包括需求获取、需求分析、需求规格和需求验证等环节。
需求获取是在与用户和其他相关人员的沟通和交流中，获取系统需求的过程。
需求获取的方法有面谈、问卷调查、文档分析、原型演示等。
面谈是需求获取的主要方法，它可以直接与用户进行交流，了解用户的需求和期望。
问卷调查可以广泛收集用户的意见和建议，但需要注意问卷设计和样本选择的合理性。
文档分析是从已有的文档中提取需求信息，如用户手册、竞争产品分析、市场调研报告等。
原型演示可以通过模拟系统的界面和功能，来引导用户提供需求，从而达到需求获取的目的。
需求规格是将需求描述、需求功能和需求级别等信息进行形式化和详细化的过程。
需求规格可以采用自然语言、用例图、数据流图、状态转换图等形式进行描述。
自然语言是最常用的需求规格方法，通过文字和语言描述需求的功能和性能。
用例图是一种图形化的需求规格方法，它可以清晰地描述系统的功能和用户之间的交互。
数据流图是一种描述系统输入、处理和输出的方法，它能够明确系统的数据流和数据处理过程。
状态转换图是一种描述系统状态和状态转换的方法，它能够清晰地描述系统的状态变化和状态转移。
需求验证是对需求的正确性和可行性进行验证的过程。
需求验证的方法有面谈、演示、原型测试和用例测试等。
面谈是需求验证的主要方法，通过与用户的交流和沟通，来验证需求的准确性和合理性。
演示可以通过模拟系统的功能和性能，来验证需求的可行性和有效性。
原型测试是通过制作系统的原型，来进行需求验证和改进的过程。
用例测试是通过编写测试用例和执行测试脚本，来对系统需求进行详细测试和验证。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需访谈的个体太多 需要回答容易确定的细节问题 当你希望有个详细的结果时 使问卷表尽可能的简短。用多个短小的问 卷表替代一个长的问卷表。如果在回答了 前15-20个问题后，长的问卷表会使用户感 觉厌烦，他们就不会对其余的问题做出正 确的判断。通常，一个问卷表包含的问题 不超过10-15。
需求捕获技术－小组会议
用户访谈 收集资料 问卷表 小组会议
需求捕获技术－用户访谈
准备访谈 计划访谈日程 访谈开始和结束 引导访谈
需求捕获技术－用户访谈
准备访谈
在进行访谈前，需求分析者应该很好的理解 行业的组织结构，行业定位、项目范围和项目目 标，访谈会涉及下面内容：
组织结构报告 年度报告 长期发展计划 部门目标的陈述 已有程序手册 已有系统的演示 已有系统文档
需求分析
如果投入大量的人力、物力、财力和时间，而开发出的软件 却没人要，那么所有的投入都是徒劳。如果费了很大的精力 开发一个软件，最后却不能满足用户的要求，而要重新开发， 那么这种返工是让人痛心疾首的。例如，用户需要一个响应 时间快的软件，而在软件开发前期忽略了软件的性能要求， 忘了向用户询问这个问题，想当然地认为是开发无响应时间 这一性能要求的软件，如果当你千辛万苦地开发完成向用户 提交时才发现出了问题，是要付出很大的代价的。所以，需 求分析在软件开发过程中具有举足轻重的地位，具有决策性、 方向性、策略性的作用，我们应对需求分析具有足够的重视。 在一个大型软件系统的开发中，需求分析的作用要远远大于 程序设计。
需求获取
5）建立核心队伍：建立起典型用户的核心队伍把同类产品 或你的产品的先前版本用户代表召集起来，从他们那里收 集目前产品的功能需求和非功能需求。这样的核心队伍对 于商业开发尤为有用，因为你拥有一个庞大且多样的客户 基础。与产品代表的区别在于，核心队伍成员通常没有决 定权。 6）确定使用实例：让用户代表确定使用实例从用户代表处 收集他们使用软件完成所需任务的描述-使用实例，讨论用 户与系统间的交互方式和对话要求。在编写使用实例的文 档时可采用标准模版，在使用实例基础上可得到功能需求。
学习任务3
软件需求分析建模
主讲：陈荣保
项目开发实践
简勇 陈荣保 编著
析是指理解用户需求，就软件功能和性能与客户达成 一致，估计软件风险和评估项目代价，最终形成开发计划的 一个复杂过程。在这个过程中，用户处在主导地位，需求分 析工程师和项目经理要负责整理用户需求，为之后的软件设 计打下基础。需求分析阶段结束后，要求得到《用户需求说 明书》和《需求规格说明书》两份文档。广义上，需求分析 包括需求的获取、分析、规格说明、变更、验证、管理的一 系列需求工程； 狭义上，需求分析是指需求的获取、分析及定义的过程。需 求分析的任务就是软件系统解决“做什么”的问题，就是要 全面地理解用户的各项要求，并准确地表达所接受的用户需 求的过程。
需求获取
首先，需求获取要定义问题范围，而系统的边界往往是很 难明确的，用户不了解技术实现的细节，这样将造成系统 目标的混淆。 其次，是对问题的理解。任何一个系统都会有很多的用户 或者不同类型的用户，每个用户只知道自己需要的系统， 而不知道系统的整体情况；他们不知道系统作为一个整体 怎么样工作效率更好，也不太清楚哪些工作可以交给软件 完成；他们不清楚需求是什么，或者说如何以一种精确的 方式来描述需求；他们需要开发人员的协助和指导，但是 用户与开发人员之间的交流很容易出现障碍，往往忽略了 那些被认为是“很明显”的信息。 最后，是需求的确认。需求的不稳定性往往随着时间的推 移产生变动，使之难以确认。 为了克服以上的问题，必 须有组织地执行需求的获取活动。
需求捕获技术－用户访谈
引导访谈
避免提封闭性的问题 询问开放性的问题 使用适当的表达 重述被访谈者的回答 有效的使用沉默
需求捕获技术－收集资料
收集用户的书面需求文档 收集用户现在的业务操作流程及其改 进意见文档 收集用户现在使用的数据表和文件及 其格式，并确定数据的来源
需求捕获技术－问卷表
需求获取
3）用户群分类：产品的用户在很多方面存在着差异，例如： 用户使用产品的频度、他们的应用领域和计算机系统知识、 他们所使用的产品特性、他们所进行的业务过程、他们在 地理上的布局以及他们的访问优先级。根据这些差异，你 可以把这些不同的用户分成小组。用户类不一定都指人， 你可以把其它应用程序或系统接口所用的硬件组件也看成 是附加用户类的成员。以这种方式来看待应用程序接口， 可以帮助你确定产品中那些与外部应用程序或组件有关的 需求。将用户群分类并归纳各自特点为避免出现疏忽某一 用户群需求的情况，要将可能使都有所差异。详细描述出 它们的个性特点及任务状况，将有助于产品设计。
按 课 程 统 计
角 色 设 置
权 限 设 置
设 置 统 计 类 型
需求获取—参与者
角色及其职责描述
•谁使用了系统的主要功能？ •谁来维护和管理系统使系统正常工作？ •哪些人对系统产生的结果感兴趣？
角色获取 职责描述
角色要求系统提供哪些功能？ 角色在系统中的工作是什么？ 角色的某些功能是否必须被系统自动 实现？
选课 数据库
成绩 数据库
需求分析--实例
1 层选课数据流图
教务 人员
录入
学生
选择
教务 人员 审核 审核选课申请
同意
开设新课程
选择课程
选中
可选课程数据库
选中课程数据库
开设课程数据库
需求分析--实例
1 层成绩数据流图
学生 教师
录入
学生
考试
交卷
成绩处理
查询
查询成绩
考试题库
学生考卷
学生成绩库
需求分析
可扩展性
可移植性
本系统在数据库上可以进行移植，支持Oracle,Sybase等 数据库。
需求获取-功能实例
网上选课系统
课程管理
成绩管理
成绩统计
系统管理
开 设 新 课 程
选 课 申 请
审 核 选 课 申 请
结 束 课 程
课 程 考 试
录 入 成 绩
成 绩 查 询
按 班 统 计
处 理 成 绩 的 各 类 表
需求获取－需求人员
谁参加需求？
角色 需求分析员 客户与最终 用户 项目组 职责 调查、分析用户的需求、定义产品需求、 撰写《用户需求规格说明书》 提供必要的需求信息；确认最终需求 参与需求评审
需求获取－功能
功能性需求
软件必须实现的软件功能
非功能性需求
系统的易用性、反应速度、容错性、健壮性等等质量属性
需求分析建模
1.需求获取 2.需求捕获技术 3.需求分析 4. 需求文档的编写
需求获取
开发软件项目关键的第一步工作是什么？
软件的需求分析 理解用户对软件提出的要求
需求获取
需求获取可能是软件开发中最困难、最关键、 最易出错及最需要沟通交流的活动。对需求的 获取往往有错误的认识：用户知道需求是什么， 我们所要做的就是和他们交谈，从他们那里得 到需求；只要问用户系统的目标特征，什么是 要完成的，什么样的系统能适合商业需要就可 以了。但是实际上需求获取并不是想象的这样 简单，这条沟通之路布满了荆棘。
需求分析-用例图实例
需求分析-用例描述实例
需求分析-用例描述实例
需求分析
数据流程图的基本图例符号
外部实体 处理 数据流 数据存储
数据流程图画法
工具
Microsoft Office Visio PowerDesigner ……
需求分析--实例
0 层数据流图
学生
选择
教师
录入
选择课程
成绩处理
业务处理过程
业务数据及关系
找出元数据：数据的数据 找出中间数据：描述统计数据的数据 找出元数据和中间数据的关系
需求获取-报表
学生成绩统计表
学号 20090105001 20090105002 20090105003 20090105004 20090105005 学生 平均分 名次
需求捕获技术
需求捕获技术－用户访谈
访谈开始和结束
陈述访谈的目的，谈谈被访谈者关心的事。 讨论他们所熟悉的日常工作的过程。 怎样的变化将使你的工作更简单或更有效？暗 示被访谈者提出改进意见。 当列表中的所有领域都讨论过后，提出下面问 题： “还有什么问题我们没有讨论吗？”或 是 “我们还需要讨论些别的内容吗？” 结束会谈时，简短的总结讨论过的问题，重点 指出会谈的要点，并说出你的理解。 最后，你必须感谢被访谈者参加这次访谈。
实体-关系图
学生 课程 代码 <pi> VA4 <M> 名称 VA20 学分 N2 课程号 <pi> 0,n 选课 成绩 N3,1 0,n 授课 教师 姓名 VA20
学号 <pi> VA10 <M> 姓名 VA20 电话 I 学号 <pi>
需求文档的编写
编写用户需求报告
需求获取－非功能
主要质量属性
正确性 可靠性 易用性 安全性
详细要求
数据输入输出保持正确，界面显示无误。 本系统操作的数据是财务数据，因此必须保证所有数据 的可靠性和正确性 本系统用户界面简单，用户在经过培训以后，就能很快 上手使用。 所有操作人员都要通过用户名和密码登陆系统，特别是 B/S端用户还必须通过证书验证，才能进去系统，保 证了数据的安全性。 本系统对于用户的需求，在功能上可以进行扩展，能满 足各级财政业务上的需求。