软件需求讲义第一部分教材.ppt

业务规则 只有公司正式员工才能注册从工资中扣除餐费的支付方式 一张订单上的所有饭菜必须送到同一个地点 计算订单价格的方法是每一种食物条目的单价乘以所订的这种食物条目的数量，加上应该交纳的销售税。 需求金字塔 特性（feature） 特征（feature）是系统为了完成涉众的一个或多个需要而提供的服务。 理解用户需要的重点是启发和组织系统特性 一项系统特性可以包括多个用户业务需求 一个用户业务需求又包括多个软件功能性需求 应用领域 特征范例 电梯控制系统 在发生火警时人 工控制通道 存货管理系统 及时提供所有存 货的必威体育精装版状况 缺陷跟踪系统 提供缺陷走势数 据评估产品质量 工资管理系统 到目前为止的金 额分类扣除报告 家用自动照明系统 长时间外出的设 置 特性、用例、软件（功能性）需求示例 目标需求：产品允许用户轻松地更正文档中的拼写错误。满足用户的业务要求，提高用户的工作效率 产品特性：拼写检查器 对应的用户业务需求（用例）：“修改拼写错误”、“把单词添加到词典中” 对应的功能性需求：“找到并突出显示拼错的单词”、“用对话框显示可供选择的单词表，提示输入正确的单词”、“用正确的单词替换整篇文档中同一个单词的所有拼写错误”。 特性属性 要点归纳 熟练掌握 好需求的特性 需求的层次 非功能性需求的内容 需求路线 一般掌握 需求在软件项目中的任务、作用 需求的定义 * * 这里所指的涉众包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。 无歧义性（续） 消除歧义的方法 对感到模糊的地方刨根问底 关键字技术 其他技术 完整性 不能遗漏任何需求或必要的信息 遗漏需求将很难查出来 如果不能确定某项需求，务必用TBD（to be determined，待确定）来标识 项目开发前，必须解决需求中所有的TBD项 每项需求必须完整描述即将交付使用的功能 完整性（续） 防止遗漏的方法 注重用户的任务而不是系统的功能。 将高层需求分解足够细，让用户真正的需求显示出来：“应该、将要、可能” →“将、必须”。 务必让所有用户类都提出意见，确保每个用例都至少有一个执行者。 用多种方式表达需求：UML模型、数据流图、判定表 （树）、E-R图等。 跟踪系统需求、业务规则、用例，直至详细的软件功能性需求，确保导出了所有必须的功能。 检查边界值 完整性（续） 示例：如果可能的话，应该根据主要法人账号列表在线确认所输入账号的合法性。 TBD，尽快确定其必要性 验证成功如何 验证失败又该如何 修订：当请求者输入账户号码时，系统将根据在线的法人账号列表来验证所输入的账号。如果在此列表中查不到该账号，则系统将显示一个出错信息并拒绝订货；否则进入订货流程。 一致性 任何一项需求不会与其他需求或更高层次的需求发生冲突 记下每项需求的来源，当发现需求冲突知道该找谁商量 项目开发前，必须解决需求不一致的问题 可检验性 需求可以通过合理的方式充分检测 开发人员能够确认软件是否满足用户需求 测试人员能够设计合理的测试方法，检验系统能否正常运行 示例1：用新的系统完成报表自动化处理。 示例2：员工标识号必须在一个有效的范围内。 确定性 使得所有人都知道在所有可能的条件下系统应该做什么 处理有条件的行为，要使用两种不同的需求 一条： 说明满足条件系统如何 另一条：说明不满足条件系统如何 确定性（续） 示例：系统1应该每隔5分钟向系统2发送一次新记录。 每隔5分钟的时间起点在哪里，不确定 当无新记录可发时，系统1该如何 修订：如果自上次向系统2发送消息以来，5分钟内收到了新记录，则系统1向系统2发送新记录；如果在上述5分钟内没有收到新记录，则系统1向系统2发送“无新记录”的提示消息。 可跟踪性 可跟踪的（软件）需求都能找到它的来源 可跟踪的（软件）需求都有它对应的设计单元、实现代码 可跟踪的（软件）需求都有它被正确实现的测试用例 可跟踪的（软件）需求都有一个固定、惟一的标识 可行性 需求必须在已知系统和环境的限制范围内能够实施 需要软件开发人员配合，检查技术可行性 忌讳使用“迅速、瞬间、及时”等用词 必要性 每一项需求都必须是用户真正的需要，或者是为符合外部系统的需求，或者是符合某一标准 每项需要都必须来源于有权定义需求的一方，可追溯至特定的客户 要控制软件开发的风险，一定要确认所要开发的内容是用户实际需要的 练习题 产品应在不少于每60秒的正常周期内提供状态信息。 不少于每60秒，一年如何？ 状态信息有哪些内容，在哪里显示，如何显示？ 修订：1. 产品将在用户界面的指定区域显示状态信息。 1.1 自产品启动后，状态信息必须每隔60±10秒更新一次。 1.2 状态信息必须保持持续的可见性。