4-4信息系统分析.pptVIP

第四章 信息系统分析-4 教学目的 第五节　系统需求 系统方案-1 系统可选方案的产生与选择 在需求定义的基础上，需要初步确定系统的设计策略； 一种是做两个系统可选方案，一个是主要方案，一个是备选方案 另一种是做三个系统可选方案，一个是功能最全，费用最高；一个是功能最少，费用最低；一个是功能适中，费用适中。 影响系统可选方案的因素 系统特性 由系统需求所决定 系统约束 属于对开发工作的限制 系统方案-2 产生设计策略 在分析阶段的成果（需求调查、分析、定义）基础上，将需求需求定义的基础上，将需求划分成功能组，利用必要的层次进行分类 列举不同的潜在的实施环境（硬件和系统软件平台） 建议不同的获得必要软件资源的可能性。 资源外包 将组织信息系统用用和运行的部分和全部责任交付给外部公司的实践 通过利用外包商的经济规模，为客户节省费用 系统方案-3 主要软件来源 硬件制造商 商品软件生产商 定制软件生产商 企业解决方案软件 现场开发 2002年全球前十名软件/服务提供商 系统特性和系统约束的类型 系统需求分析报告 传统方法的主要内容 业务活动描述（数据流程图）； 业务逻辑描述（处理过程描述）； 业务数据描述（数据字典）； 系统的非功能性要求（质量要求等） 面向对象方法的主要内容 用户场景描述（用例图） 全局结构描述（静态结构图） 系统术语表 软件需求规格说明模板 需求验证 目的 关注证明需求所定义的系统是客户正真要求 重要性 需求错误的代价是非常高的，因此，需求验证是非常重要的 在软件交付后纠正一个需求错误的费用可能比改正一个实施错误高100倍。 软件错误是逐渐扩散的。 需求检查的内容 有效性 系统提供的功能是否最好地支持了客户的需要？ 一致性 是否存在需求冲突？ 完整性 是否用户要求的功能都包括了? 现实性 这些需求能在给定的预算和现有技术的条件下实施吗？ 可验证性 这些需求能否进行检查？ 需求验证的技术 需求评审 对需求进行系统地人工分析 原型 利用一个系统可执行的模型来检查需求 测试用例 建立对需求的测试来检查需求的可测试性 需求评审 需求评审要求 在需求定义被形式化的过程中，应该进行定期的评审. 在评审中，应该有客户和开发团队成员参加 评审可以是正式的（有完整的文档）或非正式的。这种在开发人员、客户和最终用户之间的充分沟通能在较早的阶段解决问题。 需求评审内容 可验证性 需求是否可以真正地测试 可理解性 需求是否正确地理解 可追踪性 需求的起源是否清楚地表示 可适应性 需求是否能改变而不对其它需求产生大的影响 需求管理 需求管理的含义 是在系统分析、设计、实施和运行维护过程中对需求变化进行管理的过程 需求管理的必要性 需求的不完整和不一致是不可避免的 在开发过程中由于商业需求发生变化，或者随着对系统理解的深入，出现新的需求； 不同的群体有不同的需求，而这些需求经常是对立的 需求改进 常见的需求变化原因 在开发过程中来自不同方面的需求的优先等级发生变化 系统客户可能从商业角度来确定需求，但这同终端用户的需求是冲突的。 在系统开发过程中，商业和技术环境发生变化 稳定需求和易变需求 稳定需求 稳定需求来自客户组织的核心活动 也可能由领域模型导出 例如，一个医院总是有医生、护士 易变需求 在系统开发过程中或系统运行期间容易发生改变的需求 例如在一个医院，与卫生保健政策相关的需求 需求分类 需求管理计划 在系统计划阶段，需要计划 需求确定 需求如何被单独地确定 需求变化管理过程 在分析需求变化时应遵守的过程 可追踪性政策 需要保存的需求之间关系信息的数量 CASE 工具支持 支持需求变化管理的工具的需要 需求变化管理的过程 主要阶段 问题分析 讨论需求问题，并提出变化 变化分析和成本估算 评价变化对其它需求的影响 变化实施 修改需求文档，以及其它文档来反映所做的需求变动 Change management 可追踪性 可追踪性是关注在需求、需求来源和系统设计之间的关系 需求来源可追踪性 需求同提出这些需求的利益相关者之间的联系 需求的可追踪性 在相互依赖的需求之间的联系 设计可追踪性 从需求到设计的联系 一个追踪性矩阵 本章小结（2） 信息系统需求调查基本完成后，必须进行系统的需求分析 需求分析与系统模型建立是密切相关的，系统模型既是需求分析的工具，也是需求分析的结果 组织现状分析模型是对组织结构、业务过程等进行描述，有助于对要开发的系统的理解 无论是结构化的分析设计技术，还是面向对象分析设计技术，都可以从系统的事件和事物的分析开始 系统事件反映了系统内部与外部的活动起因，体现了系统的动态特征。有外部事件、时间事件和状态事件三种类型的事件。 系统事物是组成系统的实体，其是系统活动的发出者或接受者，体现了系统的静态属性。 课后作业