03-3需求分析(需求获取技术).pptVIP

本章主要内容 3.1 软件需求概念 -软件需求的问题、定义、层次、来源、依据、目标 3.2 需求工程过程 - 需求开发：需求获取、需求分析、规格说明、需求验证 - 需求管理：覆盖需求开发全过程 3.3 需求获取技术 -面谈、专题讨论会、原型方法 -应用用例 3.4 结构化分析技术 -数据流图、实体关系图、状态转换图、数据字典 应用用例（1） 用例技术是OOSE方法的组成部分，是需求获取的一种技术，以用户角度建立的功能模型。 用例模型* 表示不同用户的角色和这些角色如何使用系统的，通过与系统的交互方式描述出全部功能性的行为。具有“用户—目标”的特征。 用例模型是由用例图和用例描述组成。 用例图组成元素* 角色（Actor）是与系统交互的人或物。 用例（Use Case）描述了角色和系统之间的交互，侧重于系统为用户“做什么”，角色使用系统达到某个目标。 应用用例（2） 用例图表示处于同一系统中的参与者和用例之间的关系的图。示例：学生注册课程系统的用例图 应用用例（3） 应用用例（4） UML符号 角色不一定指的是人，它可以是其他系统、外部组织机构、外部设备等。（例如：飞机订票系统——外部的结算系统。） 应用用例（5） 建立用例模型的步骤* 识别系统边界和角色 列出事件 识别用例 书写用例文档 识别用例的关系 对用例进行优先级排序 案例描述（1） 举例：学生注册课程系统 大学准备开发一个基于Web的学生课程注册系统。 学生使用该系统查询新学期将开设的课程、授课教师情况，登记注册自己要学习的课程，课程结束后查询成绩单； 教师可以使用该系统查询新学期将开设的课程查询学生选课情况，考试结束后可以登记成绩； 注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息、课程信息等。 案例描述（2） 在每个学期的开始，学生可以获得该学期课程目录表，课程目录表列出每门课程的所有信息，诸如基本信息、教师、开课系和选课条件等。 新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请，开学两周后注册管理员负责关闭课程注册。 每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课将被取消。 案例描述（3） 一旦学生注册过程完毕，注册系统将有关信息提交收费系统以便学生缴费。如果在实际注册过程中名额已满，系统将通知学生予以更改。 学期结束时，学生可以查看成绩单。由于学生成绩属于敏感信息，系统必须提供必要的安全措施以防非法存取。 建立用例模型的步骤 识别系统边界和角色 列出事件 识别用例 书写用例文档 识别用例的关系 对用例进行优先级排序 识别系统边界和角色 系统边界的定义 系统边界是指一个系统所包含所有系统成分与系统以外各种事物的分界线。系统成分是那些在OOAOOD中定义可以编程实现的系统元素。 识别角色 谁使用系统的主要功能？ 谁改变系统的数据？ 谁从系统获取信息？ 谁需要系统的支持以完成 日常工作任务？ 谁负责维护、管理并保持 系统正常运行？ 系统需要应付（处理）哪些 硬设备？ 系统需要和哪些外部系统交互？ 谁对系统运行产生的结果感兴趣？ 时间、气温等内部外部条件？ 识别角色：角色是利益获得者 角色识别是用户观点，非系统观点 键盘、鼠标也与系统交互，但是对用户来说不是有意义的交互。所以键盘、鼠标不是系统的责任。 打印机不是角色，是因为打印机与系统之间不是有意义的交互，其交互是系统观点，而非用户观点。 识别角色：角色的泛化关系 经理可以参与职员，参职员参与的所有用例。 建立用例模型的步骤 识别系统边界和角色 列出事件（业务中的重要活动集合） 识别用例 书写用例文档 识别用例的关系 对用例进行优先级排序 列出事件 系统必须响应的外部事件和内部事件 — 外部事件：来自系统外部（如：ATM系统“存款”） — 内部事件：来自系统内部（如：ATM系统自动“过帐”） 如何识别：头脑风暴法（根据需求，找谁做什么的描述） — “主语+动词（+宾语）” — 主语：Actor的侯选，如教师，学生，注册管理员。 — 动词：表示行为，如注册，登记，查看… — 宾语：动词所代表行为的目标 列出事件：学生注册课程系统 建立用例模型的步骤 识别系统边界和角色 列出事件 识别用例（角色开展什么业务） 书写用例文档 识别用例的关系 对用例进行优先级排序 识别用例（1） 用例特征： 可观测（用例总是由角色初始化的） — 用例止于系统边界，描述交互而不是内在系统活动。 结果值（用例为角色提供值） — 用例是目标导向的，参与者需要使用它来达到的目标。 系统执行（系统责任） — 结果值由系统生成，用例执行才算完