3需求分析祥解.pptVIP

* 建立本质用户界面的方法 研究系统应用的两种方法 通过白板讨论，完成初始草图。 通过类职责协作卡CRC ( Class Responsibility Collaborator)描述。 两级UI建模 主要UI元素建模 屏幕、报表 次要UI元素建模 输入域、列表、容器 3.5 系统原型 * 主要UI元素的例子——在讨论班中注册学生 帮助请求器 学生编号 学生信息 学生姓名 显示请求器 学生已经参加的或 正在参加的讨论班 讨论班编号 讨论班搜索器 讨论班名称 搜索请求器 讨论班列表 详细信息请求器 注册请求器 讨论班编号 讨论班详细信息 讨论班名称 教授 讨论班位置 必要条件列表 讨论班描述 讨论班供应情况 在讨论班中注册学生 3.5 系统原型 * 次要UI元素的例子——学生姓名 称谓 列表, 如博士、 先生、阁下 名 输入域, 仅允许字母 姓 输入域, 仅允许字母 姓名缩写 输入域, 仅允许字母 学生姓名 学生已经参加的或 正在参加的讨论班 列表, 包括讨论班名称、讨论班编号、 加入学期、当前状态 (通过、未通过、当前注册)、 目前分数(如果有的话) 3.5 系统原型 * UI流程图 显示组成应用程序的主要UI元素之间的关系. :主菜单 :讨论班信息 :教授信息 :成绩单 :获取成绩单 :注册讨论班 使用“注册请求器” 使用“成绩单请求器” 使用“教授信息请求器” 使用“必备条件详细资料请求器” 使用“讨论班 信息请求器” 使用“成绩 单请求器” 大学系统初始UI流程图 3.5 系统原型 * 软件需求规格说明 通常用自然语言和模型，完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。 软件需求规格说明书，是需求分析阶段得出的最主要的文档。 引言 任务概述 数据描述 功能需求 性能需求 运行需求 其他需求 3.6 需求文档 * 需求的表示必须文档化 在开发和维护过程中,开发人员和用户都需使用文档。 对需求文档的基本要求 文档以书面形式书写； 文档书写规范、清晰、准确、图文一致； 文档内容的组织便于在开发和维护过程中跟踪； 文档合理编号,并配有数据字典,以便交叉参考； 在开发过程中,若需求改变,则必须同时修改文档,并对改变进行跟踪。 3.6 需求文档 3.6 需求文档 需求文档内容元素 用好的结构化和自然语言编写文本型文档。 建立图形化模型，这些模型可以描绘转换过程、系统状态和它们之间的变化、数据关系、逻辑流或对象类和它们的关系。 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。 * * 补充规范 所有未在用例模型、用户界面模型或领域模型的需求中包含的信息。 所有不适合在其他地方表示的需求。 补充规范的内容 业务规则 非功能需求 约束 3.6 需求文档 * 1. 确定业务规则 软件必须满足用户的策略、准则、规定、制度 大学系统部分业务规则的例子 BR123 任职教授可以管理学生成绩 BR124 任职教授授权的助教可以管理学生成绩 BR177 用于在数字表示的成绩和字母表示的成绩之间进行转换的表格 BR245 所有硕士学位的课程安排中必须包括完成一篇课程论文 3.6 需求文档 * BR123业务规则的例子 名称: 任职教授可以管理学生成绩 标识符:BR123 描述:只有任职教授被授权才能输入、修改和删除学生成绩，…… 例子: 王刚博士,“生物302：伽玛射线的高级应用”课程导师,可以管理所有注册该课程讨论班的学生的成绩.…… 来源:《大学政策和过程》 文件编号:U1701 出版日期:2000年8月14日 相关规则:BR12 任职资格评定 BR65 讨论班活动周期 BR200 修改学生最终成绩 版本历史: 2001年3月2日,由李明定义. 2001年10月10日,由王华更新了对相关规则BR200的引用. 3.6 需求文档 * 2. 确定非功能需求 非功能需求是关于系统必须实现的技术方面的因素。 非功能需求(技术需求)的主要内容 性能 可能性 可访问性 大学系统的非功能需求的例子 TR34 在24小时内系统不可用的时间应该不超过2分钟。 TR78 95%的时间内讨论班搜索不应超过3秒，99%的时间内不应超过10秒。 3.6 需求文档 * 3. 约束 软件解决方案拥有的自由度限制. 约束是全局性需求 约束的主要内容 开发资源的限制 开发工期的限制 开发成本的限制等 约束的例子 C18 系统将在Windows Sever服务器上工作 C24 系统将使用SQL Sever数据