面向对象分析与设计6开发其他需求

1 面向对象分析与设计 开发其他需求叶文来 2 其他需求 补充规约 SupplementarySpecification 捕获其他类型的需求 如包装 可支持性说明 许可授权 词汇表 Glossary 术语和定义 类似于数据字典愿景 Vision 对项目的简洁描述业务规则 BusinessRules 凌驾于应用之上的规定或政策 如会计制度 3 1开发补充规范P78 记录那些在用例模型中不易表述的系统需求 包括URPS 等质量属性或需求用例中可以简要编写 但还需要集中部分非功能性需求对架构选择具有重要影响一般包括 功能性 适用于多个用例的功能 非功能需求 可用性 可靠性 可支持性 设计或实现约束业务规则变例等 4 补充规格 非功能性需求 技术需求 客户很少主动提出非功能性需求 可用性 Usability 可靠性 Reliability 性能 Performance 可支持性 Supportability 其他 5 可用性 Usability 对系统使用上的要求如系统的使用者所需要的培训时间是否应附合一些常见的可用性标准如Windows界面风格等 P78 6 可靠性 Reliability 使用的可靠性 保证系统运行不出错包括 平均故障间隔时间 MTBF 通常表示为小时数 但也可表示为天数 月数或年数 平均修复时间 MTTR 系统在发生故障后可以暂停运行的时间 精确度 指出系统输出要求具备的精密度 分辨率 和精确度 按照某一已知的标准 最高错误或缺陷率 通常表示为bugs KLOC 每千行代码的错误数目 或bugs function point 每个功能点的错误数目 7 性能 Performance 对事务的响应时间 平均 最长 吞吐量 例如每秒处理的事务数 容量 例如系统可以容纳的客户或事务数 降级模式 当系统以某种形式降级时可接受的运行模式 资源利用情况 内存 磁盘 通信等 8 可支持性 Supportability 定义所有与系统的可支持性或可维护性相关的需求对于后期的支持和维护其中包括编码标准 命名约定 类库 如何来对系统进行维护操作和相应的维护实用工具等 9 设计约束 设计约束代表已经批准并必须遵循的设计决定 其中包括软件开发流程 开发工具 系统构架 编程语言 第三方构件类库 运行平台和数据库系统等等 用Oracle数据库平台 用PB开发 软件必须符合ISO 标准 本质上不是需求 只是从商业 行政 技术上的约束P79 10 补充规格 功能性 功能性需求主要在用例模型中刻画 但是也有部分需求不适合在用例中表述如 日志 出错处理 用户认证等有些功能性需求是全局性的 适用于所有的用例不需要在所有的用例中描述这些功能性需求 只需要在补充规约中统一描述就可以了 补充规格 领域规则和领域信息 领域规则记录特定应用的业务规则 如商品折扣领域信息记录与系统有关的领域解释 以便做为项目组的背景知识 加深对业务的理解 如账务知识等 11 12 2系统愿景 Vision P83 是总览性的简短文档 项目最高等级文档 描述对项目的共同愿景 老大的愿望 涉众的关键高阶目标 提示了重要的非功能和质量目标系统功能特性概要对功能性进行概括描述功能特性的准则特性层次不超过两级特性最好少于10个 13 3词汇表 Glossary P87 重要术语及期定义的列表统一不同涉众的对同一事物的术语以数据字典方式记录词汇别名描述格式 类型 长度 单位 与其他元素的关系值域验证规则P87 14 4业务规则P88 功能必须满足的运行原则和策略集中记录 便于共享和重用在用例文档中 相应的步骤加上业务规则限定比赛场地必须是长方形 边线的长度必须长于球门线的长度 球是圆形的比赛分为两个半场 每半场45分钟 姚明犯规 15 5变例 描述新的潜在的需求以简单的方式记录变例在体系结构中为变例留下实现的空间 替补 上场得分 16 例 变例 注册将完全通过Interntet完成可能性 在未来三年中有很高的可能性影响 未知 变例 大学将开设一个新的校区可能性 确定 已经公布两年内开设新校区影响 很大 学生可以在任何一个校区注册 老师在两个校区授课 学生希望把课程都安排在同一校区 17 编写的步骤 需求产生的制品愿景 用例文档 补充规约 词汇表等建议顺序编写简要的愿景方案确定用户目标和对应的用例名称详细编写一些用例 并开始编写补充性规格说明精化愿景 对以上制品的信息进行概括 18 用户界面原型 界面原型是对需求的补充 使需求说明更加具体化 有利于与客户交流 界面原型开发要根据上一阶段的用例分析的结果进行 特别是基于web的信息系统 更需要界面原型的补充说明 19 用户界面原型建模 对大多数人来说 用户界面就是软件本身 所以 掌握用户界面设计的技巧与技术是让软件走向市场的最直观因素 好的用户界面使得人们不用阅读用户手册或接受培训就能使用应用软件 界面模型以独立于技术的方式来满足软件的界面需求 目标着重于用户和他们对系统的使用 而不是表现系统的特征 着重于需求 而不是设计 原型的的开发手段很多 草图 网页 20 进行界面原型建模 主要步骤 探究系统应用确定主窗口为主要用户界面元素建模为次要用户界面元素建模探究各主次界面元素之间的关系探究用户界面之间的关系获得有关用户界面原型的反馈 21 探究系统应用 原型的开发取决于用户需求 需求决定了系统必须支持的业务对象 与实际用户共同工作 正是他们 最清楚自己的需求可以通过面谈及在建模阶段 用例等手段收集需求 22 确定主窗口 是用户启动应用程序时打开的窗口正常情况下 只要应用程序在运行时 它就始终处于打开状态最大限度减少主窗口的数目主窗口上设计公共的操作 对于需要与用户进行复杂的交互 再设计辅助窗口 23 Yahoo Music主窗口 24 为主要用户界面元素建模 是为系统与用户交互的接口建模 必须支持一个或多个用例主要用户界面可能是屏幕内容和报表 学生成绩单 25 为次要用户界面元素建模 是主要用户界面中的需要显示的元素应该支持用例中描述的行为输入域 列表和容器确定表示次要界面元素的表现方式及规则 边界框 26 探究各主次界面元素之间的关系 确定主要用户界面元素里的次要元素增加UI元素的公共特性 学生成绩单 学生信息 学生编号仅显示 学生全名仅显示 学生状态仅显示如 已毕业 全日制 在学阶段学生参加的课程列表包括课程名称 编号 状态 分数 教授 通知消息仅显示用于市场目的 脚注消息仅显示日期 页码号 27 探究用户界面之间的关系 界面流程图显示了应用软件的用户界面部件 屏幕及报表之间的关系界面流程图帮助开发者验证用户界面设计由于界面流程图提供了系统界面的高层视图 开发者可很快理解系统预期的运作流程 界面流程图表示方式多样 28 一个定单系统的界面流程图 29 简单网上书店页面关系图 30 手机聊天程序界面 31 获得有关用户界面原型的反馈 将设计展示给其他项目成员将设计展示给外部可用性专家将设计展示给用户展示原型方法 按用例中的说明走查常见的场景检测通过界面原型是否实现的系统需求对原型进行评估后 丢弃失败的部分 修改缺陷的部分 甚至添加遗漏的部分 32 用例场景测试 Scenario 用例场景通过一个或多个用户描述了单一逻辑路径根据业务流程测试界面原型 可能跨越一个或多个用例用例情景有名称 简短描述和采取活动的列表考虑系统使用时发生的异常情况情景可以描述当前系统领域外的逻辑创建调用一条或多条业务规则的情景 33 根据用例场景设计测试用例 为达到最佳的测试效果或高