6开发其他需求.ppt

面向对象分析与设计 开发其他需求 其他需求 补充规约（Supplementary Specification） 捕获其他类型的需求。如包装、可支持性说明、许可授权。 词汇表（Glossary） 术语和定义。类似于数据字典 愿景（Vision） 对项目的简洁描述 业务规则（Business Rules） 凌驾于应用之上的规定或政策。如会计制度 开发补充规范 记录那些在用例模型中不易表述的系统需求 功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述 部分非功能性需求对架构选择具有重要影响 一般包括：（ URPS+） 功能性（适用于多个用例的功能） 非功能需求（可用性、可靠性、可支持性） 设计或实现约束 业务规则 变例 功能性 功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述 有些功能性需求是全局性的，适用于所有的用例 如，日志，出错处理，用户认证等 不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。 Pos的例子 P78 非功能性需求 技术需求 （客户很少主动提出非功能性需求） 可用性（Usability） 可靠性（Reliability） 性能（Performance） 可支持性（Supportability） 其他 可用性（Usability） 对系统使用上的要求 如系统的使用者所需要的培训时间 是否应附合一些常见的可用性标准如 Windows 界面风格等。 P78 可靠性（Reliability） 使用的可靠性，保证系统运行不出错 包括： 平均故障间隔时间(MTBF)：通常表示为小时数，但也可表示为天数、月数或年数； 平均修复时间(MTTR)：系统在发生故障后可以暂停运行的时间； 精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）； 最高错误或缺陷率：通常表示为 bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。 性能（Performance） 对事务的响应时间（平均、最长）； 吞吐量（例如每秒处理的事务数）； 容量（例如系统可以容纳的客户或事务数）； 降级模式（当系统以某种形式降级时可接受的运行模式）； 资源利用情况：内存、磁盘、通信等。 可支持性（Supportability） 定义所有与系统的可支持性或可维护性相关的需求 对于后期的支持和维护 其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。 设计约束 设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。 用Oracle数据库平台，用PB开发…. 软件必须符合 ISO××××标准… … 本质上不是需求，只是从商业、行政、技术上的约束 P79 业务规则 功能必须满足的运行原则和策略 P88 比赛场地必须是长方形，边线的长度必须长于球门线的长度。 球是圆形的 比赛分为两个半场，每半场45分钟。 业务规则（2） 业务规则是在需求收集和分析的标准过程中确定的 单独记录业务规则，与需求分离 确保业务规则的内聚（易于定义） 在用例文档中，相应的步骤加上业务规则限定 变例 描述新的潜在的需求 以简单的方式记录变例 在体系结构中为变例留下实现的空间 例 系统愿景（Vision） 是总览性的简短文档，项目最高等级文档。 描述对项目的共同愿景。（老大的愿望） 涉众的关键高阶目标： 提示了重要的非功能和质量目标 系统功能特性概要 对功能性进行概括 描述功能特性的准则 特性层次不超过两级 特性最好少于10个 P82 词汇表（Glossary） 重要术语及期定义的列表 统一不同涉众的对同一事物的术语 以数据字典方式记录词汇 别名 描述 格式（类型、长度、单位） 与其他元素的关系 值域 验证规则 P87 编写的步骤 需求产生的制品 愿景、用例文档、补充规约、词汇表等 建议顺序 编写简要的愿景方案 确定用户目标和对应的用例名称 详细编写一些用例，并开始编写补充性规格说明 精化愿景，对以上制品的信息进行概括 用户界面原型 界面原型是对需求的补充，使需求说明更加具体化。 有利于与客户交流。 界面原型开发要根据上一阶段的用例分析的结果进行。 特别是基于web的信息系统，更需要界面原型的补充说明 用户界面原型建模 对大多数人来说，用户界面就是软件本身。所以，掌握用户界面设计的技巧与技术是让软件走向市场的最直观因素。 好的用户界面使得人们不用阅读用户手册或接受培训就能使用应用软件。 界面模型以独立于技术的方式来满足软件的界面需求。 目标着重于用户和他们对系统的使用，而不是表现系统的特征。着重于需求，而不是