第1章 面向对象需求汇集与确认.pptVIP

Chapter 13 面向对象需求 第1章 面向对象需求收集与确认 本章主要内容 需求分析的目的和基本过程 组建需求建模团队 基本需求收集技术 本质用例建模 本质用户界面原型 使用类职责协作卡CRC进行领域建模 开发补充规范 确定变例 1.1 需求分析的目的和基本过程 需求分析的主要过程 收集需求 表示需求 分析需求 1.1 需求分析的目的和基本过程(Cont.) 分析需求 根据收集到的需求进行分析,充分理解领域专家和用户提出的对系统的要求. 分析是否正确地表达了需求. 1.2 组建需求建模团队 需求团队的人员组成:少而精 领域专家 提供需求的详细信息 需求分析员 负责组织需求收集、建立文档和需求确认 协调员 负责组织需求建模讨论会 记录员 负责记录需求信息 项目相关人员 用户,客户,投资者 1.3 基本需求收集技术 1.3 基本需求收集技术 (Cont.) 集体讨论 需求分析员或协调员领导团队集体讨论,为系统确定潜在的需求. 集体讨论技术 协调员解释集体讨论的规则和主题 记录员记录并展示讨论内容 讨论是一个迭代过程 1.4 本质用例建模 利用需求建模理解系统所要解决的业务问题 绘制用例图(Use Case) 两种用例模型(分别产生于两个阶段) 本质用例模型(Essential Use Case Model)(业务用例模型,抽象用例模型) 对系统的需求建立独立于技术的模型 系统用例模型(System Use Case Model)(个体用例模型,详细用例模型) 描述用户和系统协同工作的细节 1. 绘制用例图 使用UML的用例图描述一个系统的用例、参与者、关联、系统边框和包. 用例(Use Case) : 描述一系列动作,为参与者提供可测量的 值. 参与者(Actor) :与系统进行交互的角色(人,机构,外部系统). 关联(Association) :描述用例和参与者,用例和用例之间的关系. 系统边界(System Boundary) :描述系统的边界范围. 包(Package) :将模型分组组织起来(子系统). 一个简单的大学课程的用例图 2. 确定参与者 参与者(角色)表示与系统进行交互的任何个或物. 通过问题发现参与者 系统的客户 从系统取得信息的人或系统 为系统提供信息的人或系统 安装系统、使用系统的人 与本系统进行交互的其他系统 …… 确定参与者应注意的问题 参与者可以是人 “学生” ,“教师” 参与者可以是物 “注册员”可能是人,也可能是某系统 参与者不需与具体职位对应 “成绩管理员”可以是专职人员,也可以是任课教师 教师可以是教授,副教授,讲师,助教 确定了参与者后,还必须为每个参与者合适地命名,并编写对参与者的描述. 3. 确定用例(以大学课程系统为例) 方法1：Constantine Lockwood确定用例的方法. 从参与者角度,向领域专家提出问题,确定可能的用例. 例:从参与者学生的观点,可发现大学课程系统中的学生: 需要注册、参加、退出某一课程 需要可供选择讨论班的列表 需要确定讨论班的基本信息 需要注册某个讨论班,参加讨论班,退出讨论班,完成讨论班 需要得到一份成绩单 需要知道课程变化信息,包括教室变化、时间变化 方法2:Ambler(1998a)的用户情景方法 请领域专家在集体讨论会讨论不同的情景 例: 与领域专家讨论结果为: 学生需要注册课程,然后注册该课程的某个讨论班,注册员需要确定学生是否满足该讨论班的要求条件. 学生具备该课程要求的条件,且该课的讨论班有空位 导师要求在他讲授的课程中都要列出某讨论班. 导师向系统提交学生成绩单.成绩可以是考试成绩、测验成绩或作业成绩. 学生想要退出某讨论班. 学生们要求打印成绩单,以便放在个人简历中. 利用上述两种方法中的一种或二者结合,将信息组织到用例图中. 对于较大的系统,可以将用例图中的内容组织成若干个包. 应注意的问题 这一阶段的用例是一个初级用例,将陆续完善; 用例之间没有时间顺序; 一个客户参与者通常参与多个用例; 用例不是功能; 关联线可以不使用箭头; 每一个参与者至少参与一个用例,每一个用例至少包含一个参与者; 一个用例图中用例个数以7?2个为宜,使用Package可以进行适当分解. 4. 编写用例文档 确定了用例图后,为每个用例编写用例文档. 用例文档的主要内容 用例名称 对用例的描述 前提条件 后置条件 活动的基本过程 用例过程 包括基本过程和候选过程 一个过程描述仅描述一件事. 用例“注册讨论班” 名称：注册讨论班 描述：把现有的有资格的某一学生注册到某个讨论班. 前提条件：学生已在大学注册. 后置条件：如果学生具有注册资格,并且该讨论班有空位,则学生注册到该讨论班. 活动的基本过程： 1.学生想要注册到某个讨论班.