接口和界面的需求.PPT

3．对需求进行测试 最常见的需求验证方式是需求评审，但是，在评审之前，一般还应对需求进行测试，并将测试结果通知评审人员。 对软件需求的一个基本要求，就是需求的可验证性，而需求测试，就是需求验证的最好方法。对需求进行测试，在测试V模型中表达得最清楚。 软件需求应在最终的软件产品上得以验证。不能验证的需求无法得到保证。因此，要考虑如何对每个需求进行验证。接受测试可以完成这个工作。 4.6 需求分析文档 1．用户需求报告 软件需求分为两种，一种是《用户需求报告》，它是开发人员直接与用户打交道，直接向用户提交需求的报告。 另一种是分配的《软件需求报告》，它是开发人员不直接与用户打交道，只与系统集成项目组(总体组)打交道，由系统集成项目组将一个大项目分解为硬件开发和软件开发两部分，并将软件开发的任务分配给软件项目组，它相当于指令性软件开发计划，或近似于立项之后的软件开发计划。 2．需求分析规格说明书 以用户需求报告为基线，按照规定的格式，就可以制作出合乎规范的《需求分析规格说明书》。 《需求分析规格说明书》是站在开发者的立场上写的，不需要用户看懂、签字与确认。 由于它是概要设计和详尽设计的依据，所以它除了要覆盖《用户需求报告》的内容外，还要加上有利于设计的提示与建议，如实体、属性、关联、主键、外键、算法分析 3．需求管理文档 需求管理文档有： （1）《用户需求报告评审记录表》 （2）《需求分析规格说明书评审记录表》 （3）《需求变更管理表》 它们的格式与内容，如表4-16和表4-17所示。 项目名称 项目经理 评审阶段 用户需求报告/需求分析规格说明书 第 次评审 评审组组长 评审时间 评审地点 评审组成员 不符合项跟踪记录（Check list of noncompliance items） 不符合项名称 不符合项内容 限期改正时间 实际改正时间 测试合格时间 测试员签字 审计员签字 评审意见 评审结论 项目名称 申请日期 用户名称 审批日期 变更原因 实际变更日期 原来需求 变更内容 审批意见 《用户需求报告/需求分析规格说明书评审记录表》的特色是：突出了不符合项的跟踪记录。 所谓不符合项，就是有问题的项。这些问题主要是指在系统功能、性能、接口上存在的遗漏或缺陷。 一旦在评审中发现，就要马上记录在案，记录内容包括：不符合项名称、不符合项内容、限期改正时间、实际改正时间、测试合格时间、测试员签字、审计员签字。 软件测试部门的测试员签字，说明给出了测试合格证明。软件质量管理部门的审计员签字，表示审计了此项工作。只有当不符合项为零时，评审才能最后通过。评审意见可以指出文档中的强项和弱项。评审结论就是通过或不通过。 4.7 本 章 小 结 软件分为系统软件和应用软件，应用软件又可以分为信息系统软件和非信息系统软件，信息系统软件是以数据库管理系统DBMS为主要支撑平台的应用软件。 在软件的开发过程中，都有一个需求分析问题。那么读者也许要问：“需求分析是否也可以分为系统软件需求分析和应用软件需求分析，信息系统软件需求分析和非信息系统软件需求分析呢？”回答是。 在实现生活中，确实有多种软件需求分析。由于信息系统这种软件应用面最广，市场最大，客户最多，需求分析最难，所以人们一谈需求分析，就自然而然地认为指“信息系统需求分析” ，最后给开发者和客户造成一种既成事实：“需求分析”就等于“信息系统需求分析”。 信息系统需求分析难度系数较大，这是为什么？ 信息系统由社会环境、网络环境、数据环境和程序环境这四个部分组成。社会环境中又包括：企事业单位的组织机构、部门分工、岗位职责、管理水平、人员素质、业务流程、操作规则、信息标准等因素。这些因素汇集在一起，从各个方面影响信息系统的需求，波及信息系统建设的成败。 要在这样复杂多变的社会环境中，通过需求分析，使“开发者与客户达成完全一致的需求”，多么不容易！这就是信息系统需求分析难度系数大的真正原因。 第4章介绍完毕。 请同学们认真完成作业。 谢谢诸位，再见！ 图4-5表示图书馆信息系统的实体联系模型。主要实体是“图书”和“读者”，这两个实体之间的关系是图书借阅和图书归还，因为一个复杂关系也是一个实体，所以用“图书借阅”和“图书归还”这两个实体来表示这两个复杂关系。 另外，极少数读者可能有违规行为，所以需要增设一个“罚款”实体。 由于图书馆的图书，来自于对外的采购，每一次采购都要有订购单，而且一张订购单上可以同时订购一个出版社的多种图书，所以要用“订购单头”和“订购单明细”两个实体来描述。 需要指出的是：不同的软件分析师，对于同一个图书馆信息系统，所设计出来的实体--联系图，可能大同小异，也可能各不相同。 因为对于同一个信息系统，实体--联系图不存在唯一的标准答案。 实体--联系模型既是表