第4部分信息系统分析.ppt

第4部分 信息系统分析 信息系统分析的主要任务及目标 任务： 业务和数据的流程是否通畅，是否合理，数据、业务过程和实现管理功能之间的关系，原有系统管理模式改革和新系统管理方法等。 目标： 确定用户的需求及其解决方法，提出系统的逻辑模型。 需求分析 分为问题分析、需求定义和需求评审3个阶段。 1. 问题分析 对问题及其环境的理解、分析和综合，清除用户需求的模糊性、歧义性和不一致性，对相互冲突的要求进行折衷。 此阶段，要将对原始问题的理解与软件开发经验结合起来，以发现由于用户的片面性或短期行为所导致的不合理要求和用户尚未提出但具有真正价值的潜在需求。 2. 需求定义 3. 需求评审 在用户和软件设计人员的配合下对生成的需求规格说明和初步用户手册进行复核，以确保需求的全面性、精确性和一致性。 需求定义 需求获取、需求规格说明及需求说明书（初步用户手册）等。 需求规格说明包含对目标软件系统的外部行为的完整描述、需求验证标准及用户在性能、质量、可维护性等方面的要求。 用户手册包括用户界面描述及有关目标软件使用方法的初步构想。 需求获取的内容 功能需求 必能需求 环境需求 安全保密要求 用户界面需求 资源使用需求 软件成本消耗与开发进度需求 需求获取的方法 系统调查原则 自顶向下全面展开； 分析管理部门存在的道理、环境条件、工作过程； 工程化的工作方式； 全面铺开与重点调查结合； 主动沟通和亲和友善的工作方式。 系统调查常出现的错误 1.技术与业务脱节 2.敷衍了事，不下功夫了解原有业务。 3.就事论事，图快、图方便。 4.把客户当专家，希望客户说出所有业务和问题。 系统详细调查 详细调查方法： 1.自顶向下全面展开 展开的方法可按深度优先与分支定界相结合方式，也可以按广度优先与分支定界相结合的方式。 2.事先计划和培训 3.从组织机构入手 组织结构按行政隶属关系或按业务隶属关系。 4.调查与分析整理相结合 调查必须统一口径，统一要求，统一表格； 相关业务对照调查材料。 5.了解业务与收集数据同时进行 在调查每个具体工作岗位业务的同时，还要收集与该业务有关的所有报表、文件、技术文档，附在调查问卷之后； 在了解业务时，还要了解用户对信息载体的满意程度。 需求规格说明（IEEE830标准） 1 引言 1.1 目的 1.2 文档约定 1.3 预期的读者和阅读建议 1.4 产品的范围 1.5 参考文献 2. 综合描述 2.1 产品的前景 2.2 产品的功能 2.3 用户类和特征 需求规格说明（IEEE830标准） 2.4 运行环境 2.5 设计和实现的限制 2.6 假设和依赖 3 外部接口 3.1 用户界面 3.2 硬件接口 3.3 软件接口 3.4 通信接口 需求规格说明（IEEE830标准） 4. 系统特性 4.1 说明和优先级 4.2 激励/响应序列 4.3 功能需求 5. 其他非功能需求 5.1 性能需求 5.2 安全设施需求 5.3 安全性需求 需求规格说明（IEEE830标准） 5.4 软件质量属性 5.5 业务规则 5.6 用户文档 6 其他需求 附录A：词汇表 附录B：软件分析模型 附录C：待确定的问题 需求规格评审 评审需求规格说明的主要指标： 正确性 无歧义性 安全性 可验证性 一致性 可理解性 可修改性 可追踪性 评审参考内容 系统定义的目标是否与用户的要求一致 系统需求分析提供的文档资料是否齐全 文档中的所有描述是否完整、清晰、准确地瓜映了用户要求 与所有其他系统成分的重要接口是否都已描述 所开发项目的数据流与数据结构是否足够，是否确定 所有图表是否清楚，在没有补充说明时是否易于理解 主要功能是否已包括在规定的软件范围之内，是否都已充分说明 设计的约束条件或限制条件是否符合实际 开发的技术风险是什么 是否考虑过软件需求的其他方案 是否考虑过将来可能会提出的软件需求。 是否详细制定了检验标准，能否对系统定义的成败进行确认 有没有遗漏、重复或不一致的地方 用户是否审查了初步的用户手册 软件开发计划中的估算是否受到了影响 需求规格说明书 根据软件需求规格说明IEEE指南的表达，应该按照功能描述规格，而不是按照结构或过程描述规格。 通常，可以将需求工程文档分为需求（分析）文档和规格说明文档或将这两个文档结合在一起。 需求规格说明书 需求文档包含的内容： 问题域描述+待满足的需求列表（待求解的问题） 规格说明文档包含的内容： 将满足需求的解系统的一种行为的定义（解决问题） 需求规格说明书 需求规格说明书的核心是新的解系统的行为描述，包含的内容如下： 文档细节（标题、授权、修订本历史等） 概述（问题域和解系