软件工程与目管理03.pptVIP

* 层次模块结构图（H图） 1、H图基本做法：是将系统划分为若干子系统，子系统下再划分为若干的模块，大模块内再分子模块。 2、H图特点：主要关心模块的外部属性，不关心模块的内部，即只关心它是什么能够作什么，不关心它怎么做。（怎么做IPO图解决） 3、模块的定义(什么是模块)：具有输入输出、逻辑功能、运行程序和内部数据这四种属性的一个程序。 IPO图 IPO图是输入、处理、输出图的简称 模块编号:c.5.5.8 图3.7 IPO图的一个例子图 c.5.4.4 上组模块 送入出入 库单据 1核对纪录 2核对价格 3核对用户 纪录 4记录合格 将合格标志 送回上一级 模块c.5.4.4 本书建议使用一种改进的IPO图 (也称为IPO表)， (1) 一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。 (2) 完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。 (3) 现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。 (4) 有效性必须证明需求是正确有效的，确实能解决用户面对的问题。 3.8 验证软件需求 3.8.1 从哪些方面验证软件需求的正确性 3.8.2 验证软件需求的方法 需求验证是检验需求能否满足客户的意愿。 需求验证的技术 需求评审：由不同代表（如分析员、客户、设计人员、测试 人员）组成的 评审小组以会议形式对需求进行系统性分析。 原型评价：客户和用户在一个可运行的系统模型上实 际检验 系统是否符合他们的真正需要。 - 测试用例生成：通过设计具体的测试方法，发现需求中的许多问题。 需求验证 需求验证主要围绕需求规格说明的质量特性展开。 它主要是： ?正确性 ?无二义性 ? 完整性 ?可验证性 ?一致性 ?可修改性 ?可跟踪性 * 需求规格说明的质量特性 ? 正确性 需求规格说明对系统功能、行为、性能等的描述必须 与用户的期望相吻合，代表了用户的真正需求。 ? 审查需求的正确性应该考虑的问题 用户参与需求过程的程度如何？ - 每一个需求描述是否准确地反映了用户的需要？ - 系统用户是否已经认真考虑了每一项描述？ 需求可以追溯到来源吗？ ? 举例：下面的需求描述正确吗？ - 在用户每次存钱的时候系统将进行信用检查。 * 需求规格说明的质量特性 ? 无二义性 - 需求规格说明中的描述对于所有人都只能有一种 明确统一的解释。 ? 审查需求的无二义性应该考虑的问题 - 需求规格说明是否有术语词汇表？ - 具有多重含义或未知含义的术语是否已经定义？ -- 需求描述是否可量化和可验证？ - 每一项需求都有测试准则吗？ ? 举例：下面的需求描述是无歧义的吗？ - 如果用户试图透支，系统将采取适当的行动。 * 需求规格说明的质量特性 ? 完整性 - 需求规格说明应该包括软件要完成的全部任务， 不能遗漏任 何必要的需求信息。 ? 审查需求的完整性应该考虑的问题 -- 是否存在遗漏的功能或业务过程？ -- 在每个定义的功能之间是否有接口？ - 是否有信息或消息在所定义的功能之间传递？ - 是否定义了功能的使用者？ - 是否已经清楚地定义了用户与功能之间的交互？ -- 是否定义了与外部过程和系统之间的接口？ * 需求规格说明的质量特性 ? 审查需求的完整性应该考虑的问题（续） - 所描述的功能是否可以映射到业务过程中？ - 文档中是否存在待确定的需求引用？ - 文档中是否存在未定义的术语和引用？ - 文档的各个部分都完整吗？ - 需求包括非功能属性的说明吗？ ? 是否考虑了软件性能？ ? 是否考虑了安全性要求？ ? 是否考虑了可靠性？ ? 是否考虑了系统容量问题？ * 需求规格说明的质量特性 ? 可验证性 - 需求规格说明中描述的需求都可以运用一些可行的手段对其 进行验证和确认。 ? 审查需求的可验证性应该考虑的问题 - 在需求文档中是否存在不可验证的陈述，诸如“用户界面友 好”、“容易”、“简单”、“快速”、“健壮”、“最新技术”等？ - 所有描述都是具体的和可测量的吗？ ? 举例：下面的两个需求描述中哪一个难以验证？ - 系统将在 20