七章其他需求.pptVIP

第七章 其他需求 暨南大学计算机系 黄战 目标 展示补充性规格说明、词汇表、设想和业务规则等制品。 比较和对照系统特性和用例。 定义质量属性。 简介 用例不是需求的全部。我们通过以下制品捕获了其他需求： 补充性规格说明 例如报表、文档、包装、可支持性说明、许可授权等等。 词汇表 捕获术语和定义，也可起到数据字典的作用。 设想 概括了对项目的“设想”，即执行摘要。该制品为项目贮运爱思想提供简介描述。 Next Gen POS 示例 这是对文本主旨更加准确的把握，但是我们把它当作对主题的介绍。 NextGen示例（部分）补充性规格说明 功能性 可用性 可靠性 性能 可支持性 实现约束 购买构件 免费开源构件 接口 法律问题 所关注领域内的信息 注解：补充性规格说明 补充性规格说明捕获了用例或词汇表难以描述的其他需求、信息和约束： FURPS+ 需求－－功能性、可用性、可靠性、性能、可支持性。 报表 硬件和软件约束（操作系统和网络系统等）。 开发约束（例如，过程和开发工具）。 国际化问题（货币单位，语言）。 文档化（用户、安装和管理手册等）和帮助。 许可和其他法律问题。 包装。 标准（技术、安全和质量）。 物理环境问题（例如，热度或振动）。 操作问题（例如，如何处理错误，或者每隔多久进行备份）。 特定应用领域规则。 所关注领域的信息（例如，信用卡支付处理的整个过程）。 注解：补充性规格说明 约束不是行为，而是设计或工程上的一些其他种类的限制。例如 必须使用Oracle（我们和他们之间有许可方案） 必须在Linux上运行（降低成本） 质量属性 这是一个系统的“质量”，它有两种类型： 运行时可视（功能性、可用性、可靠性、性能等） 运行时不可视（可支持性、可测试性等） 质量属性具有相关性和涉及可交替性。 领域规则 常见的领域规则： 公司政策 物理法则 政府法律 所关注领域内的信息 这对于主题问题专家是有价值的，他们可以编写一些于新软件系统有关的领域解释，以便为开发人员提供背景信息和更为深入的理解力。 NextGen示例（部分）设想 注解：设想 我们是在处理同样的问题吗？正确的问题吗？ 问题陈述：一个表格式的模板： 涉众的关键高阶目标及问题 我们需要可容错的销售处理过程。 我们需要定制业务规则的能力。 根问题和目标是什么？ 具有创造性、研究性的小组工作方法。 涉众的关键高阶目标及问题 系统特性：功能需求 为掌握主要特性而在设想文档中只列出用例名称是不够的。原因如下： 太详细。人们想要了解的是主要思想的概要。 用例名称可能掩盖了涉众真正关心的主要特性。 有些值得注意的特性跨越了多个用例或者与用例无关。 设想中的其他需求 对于其他需求，要避免在设想和补充性规格说明（SS）中重复或近于重复。最好只在SS中记录这些需求。在设想文档中，可以指引读者到SS中阅读这些需求。 应该先编写设想，特性还是用例？ 不需要严格定义这种先后顺序。建议采取如下的顺序： 1）首先编写简要的设想草案。 2）确定用户目标和对应的用例名称。 3）详细编写一些用例，并且开始编写补充性规格说明。 4）精化设想，对以上制品中的信息进行概括。 NextGen示例（部分）词汇表 注解：词汇表（数据字典） 可靠的规格说明：矛盾的修辞手法？ 项目站点上的在线制品 这些数字制品通常应该只在线记录于项目的Web站点上，使用超链接或者存储在数据库中。（例如：数据词典）。 初始阶段没有很多的UML吗？ 大部分UML图是在详尽的细节明确以后出现的。 UP中的其他需求制品 UP制品和上下文处理过程 * * Figure Vision 1 NextGen POS Cashier System Administrator Store Manager Calls upon services Calls upon services ?actor? Payment Authorization Service ?actor? Tax Calculator ?actor? Accounting System ?actor? Human Resources System ?actor? Inventory System ?actor? Sales Activity System ....???????????? a successful solution would be ....???????????? the impact of which is ....???????????? affects ....???????????? The problem of 词汇表 修订历史 ???????????? ???????????? ???????????? ??????????