3 需求分析-1 任务获取.pptVIP

复习 可行性研究的内容 系统流程图的基本符号 数据流图的符号、含义、画法、灵活应用 数据字典的符号、写法、灵活应用 第3章需求分析 内容 需求分析的任务 需求获取 分析建模 文档编写 需求验证 3.1 需求分析的任务 需求分析的依据：可行性研究阶段的文档 需求分析的目的：明确用户对系统的确切要求。 3.1.1 确定对系统的综合要求 （1）功能需求：目标系统必须具备的所有功能。 考虑系统做什么 系统权限与角色 与其它系统的接口 注意：一般不考虑系统的实现细节。 （2）非功能需求 定义了系统工作时的特性 非功能需求 性能：软件开发的技术性指标，如存储量、速度、稳定性等 环境需求： 硬件设备：机型、外设、接口、地点、分布、温度、湿度、磁场干扰等 软件：操作系统、数据库系统、网络等 界面需求：界面风格、操作方式等 用户和人的因素： 用户类型 用户水平 非功能需求 文档 需要哪些文档 文档读者 数据 输入、输出数据的格式 数据的准确性和精度 数据流量 数据需保持的时间 非功能需求 安全保密 系统备份 系统版权 软件成本消耗与开发进度 软硬件投资 规定时间表？ 3.1.1 确定对系统的综合要求 例：某高校医疗费管理系统的需求分析 某高校医疗费分为校内门诊费、校外门诊费、住院费、子女医疗费4种，要求在数据库中存放每个职工的职工号、姓名、所属部门。职工报销时填写所属部门、职工号、姓名、日期、医疗费种类和数额。 该校规定，每年每个职工的医疗费报销有限额，限额在年初时确定，每个职工一年内报销的医疗费不超过限额时可全部报销；超过限额时，超出部分只可报90%，职工个人负担10%。子女医疗费也有限额，超出部分可报销50%。 3.1.1确定目标系统的具体要求 例：某高校医疗费管理系统的需求分析 医疗费管理系统每天记录当天报销的医疗费类别和金额，并存入数据库。当天下班前让系统自动结帐、统计当天报销的总额，供出纳核对。每笔帐要保存备查，每天要累计各职工及子女已报销的医疗费，以便检查超额与否。要设计适当的查询功能。 年终结算、下一年度开始时，要进行数据库文件初始化，每位职工的初始余额为职工的医疗费限额，前一年有余额，累加到新年度的余额中。 职工调离本单位、调入本单位或在本单位内部部门间调动，数据库文件要及时修改。 3.1.1确定目标系统的具体要求 （1）确定系统的环境要求 该系统规模不大，可以和用户单位的其它管理系统使用相同的计算机硬件设备、操作系统和数据库管理系统。在使用数据库管理系统建立数据库结构的同时，如果使用英文字段，则应在数据字典中说明字段所对应的中文含义。 3.1.1确定目标系统的具体要求 （2）系统的性能要求 涉及会计经费问题，数据不能随意更改，但数据输入时又难免出错，因而在输入费用后，要有提示，要求核对。、 当天报销工作结束时，让出纳员再次核对经费总额，若出纳员支出的金额总数和计算机结算的数据不相符合，说明数据有误。可让计算机显示每笔报销账目，供仔细核对，此时再允许修改一次。 正式登帐后，数据不允许修改，由此来保证财务制度的严格性，保证数据的安全性。 3.1.1确定目标系统的具体要求 （3）系统功能 主要功能有：数据输入、结算、累加、统计、查询及系统维护等。 ①数据输入： 报销日期、职工号、姓名、部门、校外门诊费、校内门诊费、住院费、子女医疗费。输入数据后，根据是否超额计算本次可报销的数额。 ②结算 结算当日报销人数、各类医疗费总额及所有类别的总额，供核对。若数额有误，将当日报销人员和分类数额全部列出，供出纳员仔细核对，若发现错误，则进入“修改”模块进行修改。 3.1.1确定目标系统的具体要求 ③修改 会计帐是不能随意更改的，这里只允许修改当天输入的错误数据。 ④累加 …… ⑤统计 …… ⑥查询 …… 系统维护 …… 3.1.2 确定对系统数据要求 分析系统的数据要求，建立数据模型：数据字典、方框图、Warnier图。 3.1.3 导出系统的逻辑模型 数据流图、实体联系图、状态转换图、数据字典、主要处理算法 3.1.4 修正系统开发计划 3.1 需求分析的任务 需求分析的过程： 需求获取 分析建模 文档编写 需求验证 3. 2 需求获取 获取需求的方法： 访谈 面向数据流自顶向下求精 简易的应用规格说明技术 快速建立软件模型 3.2.1 访谈 是最早开始获取需求的方式，还可以配合： 现场观察工作流程 调查表 情景分析 开会讨论 某出版社系统调查表 3.2.2 面向数据流自顶向下求精 结构化的分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。 请用户针对数据流图、数据字典等进行复查。 反复进行，完成数据流图细化。 3.2.3 简易的应用规格说明技术 面向团队的需求收集法。原则： 由开发人员和用户组成团