《面向对象的需求分析》由会员分享，可在线阅读，更多相关《面向对象的需求分析（81页珍藏版）》请在金锄头文库上搜索。
1、面向对象的需求分析-1-认识问题认识问题分析问题分析问题解决问解决问题题最终用户最终用户( (提出问题提出问题) )开发团队开发团队( (解决问题解决问题) )以以用户用户的身份站在的身份站在用户用户的的 角度认识问题角度认识问题 获取需求获取需求用例建模技术用例建模技术以以开发者开发者的身份站在的身份站在用户用户 的角度分析问题的角度分析问题 分析需求分析需求用例分析技术用例分析技术以以开发者开发者的身份站在的身份站在开发开发 团队团队的角度分析问题的角度分析问题 解决需求解决需求面向对象设计面向对象设计-3-内容安排n n理解需求理解需求n需求，难在何处？n以用例为中心组织需求n基于用例的
2、需求分析过程-4-需求建造“正确”的系统n需求：系统必须满足的条件或具备的能 力nRobert Grady软件质量准则“FURPS”n功能性（Functionality）n使用性（Usability）n可靠性（Reliability）n性能（Performance）n可支持性（Supportability）非功能性需求非功能性需求-5-内容安排n理解需求n n需求，难在何处？需求，难在何处？n以用例为中心组织需求n基于用例的需求分析过程-6-需求，难在何处？n自己到底想要什么？n这是个问题-7-需求：也需要开发客户/用户的要 求/想法/期望软件设计软件产品开发编码和测试验收有价值的 软件需求分
3、析和设计-8-获取好的需求n需求收集包括五个关键步骤n找到可以帮助你理解这个系统的人n倾听这些相关人员的描述，并从他们的角度 来理解系统n利用一个容易理解的模型来描述用户希望如 何使用这个系统以及为他们提供的什么价值n详细地描述系统和客户以及系统和外部系统 之间的交互n重构（refactor）这个详细描述以保证它是 可读且易懂的-9-内容安排n理解需求n需求，难在何处？n n以用例为中心组织需求以用例为中心组织需求n基于用例的需求分析过程-10-需求问题：对策难捕获难捕获易变易变从用户视角看问题从用户视角看问题合理的结构合理的结构用例用例-11-以用例为中心组织需求用例用例可用性可用性可靠性可
4、靠性网络协议网络协议业务规则业务规则硬件接口硬件接口界面约束界面约束性能性能用例的相关概念参与者（Actor） 用例（Use Case） 事件流参与者(Actor)n参与者是在系统之外于系统进行交互的 任何事物。参与者触发系统某项功能的 执行(通过向系统输入某些信息，或请求 系统输出某些信息)。n最常见的参与者n人（操作人员或系统的服务对象）n设备（监控系统的摄像头等信息采集器）n外系统用例(Use Case)n用例(use case):是对系统某个功能的一组 动作序列的描述，系统执行这些动作序列 将产生一个对某个特定的参与者有特定价 值的结果。用例表示系统外部可见的功能 单元。n简言之：用例
5、就是系统某功能一次执行的例 子。事件流n事件流是系统完成需求行为的事件描述 应尽量写的详细。事件流通常包括4部 分：简要说明前置条件主事件流和异常事件流（错误流）事后条件（并不是每个用例都有）-16-内容安排n理解需求n需求，难在何处？n以用例为中心组织需求n n基于用例的需求分析过程基于用例的需求分析过程-17-基于用例的需求分析过程n1. 获取原始需求n2. 开发一个可以理解的需求n2.1 识别参与者n2.2 识别用例n2.3 构建用例图n3 详细、完整地描述需求n进行用例阐述n4 重构用例模型n4.1 识别用例间的关系n4.2 对用例进行组织和分包-18-基于用例的需求分析过程n n1.
6、 1. 获取原始需求获取原始需求n2. 开发一个可以理解的需求n2.1 识别参与者n2.2 识别用例n2.3 构建用例图n3. 详细、完整地描述需求n进行用例阐述n4. 重构用例模型n4.1 识别用例间的关系n4.2 对用例进行组织和分包-19-获取需求的技巧（MSF）技巧技巧描述描述实地观察实地观察直接观察个人工作的情况，以发现现存的实践方式和问 题访谈访谈从个人处收集特定信息特定群体特定群体 调查调查对一组人员进行调查，以便了解工作态度和共同看法问卷调查问卷调查收集详细数据和统计意义上比较重要的数据用户指导用户指导让最终用户告诉你，他们是如何操作系统的原型制作原型制作模拟一个无法直接测试的
7、系统统计版本统计版本使用具有统计功能的应用程序来记录用户完成任务的方 式 (RequisitePro)-20-获取需求：网上选课系统初次访谈记录（教务处）初次访谈记录（教务处）开发者：谁将使用这个应用程序？ 客 户：教务处管理人员、学生、老师，各院系教学秘书。开发者：现在是怎么选课的？ 客 户：教学秘书把备选课程告诉学生，然后把学生的选课情况反馈上 来，然后教务处安排上课。开发者：这些课程是怎么确定的？ 客 户：从教学计划里得到的。开发者：这些课程会有变化吗？ 客 户：嗯，有些教师可能想开一门新选修课，他把该课程提交上来， 教研室审核通过后就可以备选了。各院系也可以增加或删除一些课程。-21-
8、获取需求：网上选课系统第二次访谈记录（教务处）第二次访谈记录（教务处）开发者：我认为我们应该更加深入的谈谈。 客 户：好的。开发者：是否要增加一个用户教研室。 客 户：应该是吧。开发者：教务处怎么安排上课？ 客 户：跟据选课情况，安排授课教师、教室以及上课时间。开发者：授课老师怎么确定的呢？ 客 户：由教授课程的院系决定。开发者：增加或删除课程谁来操作，还要再增加一个新用户吗？ 客 户：不用，教学秘书就行。-22-获取需求：网上选课系统和教学秘书的谈话和教学秘书的谈话开发者：您对教务处的安排还满意吧？ 客 户：基本上可以，但是有个小问题。开发者：什么？ 客 户：专业选修课的上课安排由我决定就好
9、了，因为我们很多课需要 多媒体教室，我们的老师也不想去北区上课。教务处的人总是不照顾我 们，但是这话千万别告诉教务处，就说我们想自行决定就可以了。开发者：我去教务处商量一下。第三次访谈记录（教务处）第三次访谈记录（教务处）开发者：教学秘书提出了一个问题。 客 户：什么问题。开发者： 客 户：专业选修课由各院系决定就行了，但是全校公共选修课的上课 安排还得教务处来决定。获取需求：网上选课系统获取需求：网上选课系统经过若干次谈话，终于有了一个较为清晰的需求经过若干次谈话，终于有了一个较为清晰的需求参与者： 教务处管理人员、学生、老师、各院系教学秘书、教研室主任 使用情况： 教务处管理人员：发布公共
10、课课程信息、安排公共课上课地点、 时间，增加或删除公共课、修改公共课课程信息（时间、地点） 、发布新闻 学生选课、查询成绩 老师申请新课、登录成绩 教学秘书发布专业选修课备选信息、安排专业选修课上课、修改 课程信息（对公共课只能修改授课教师）、发布新闻 教研室主任审核新开课程-25-基于用例的需求分析过程n1. 获取原始需求n n2. 2. 开发一个可以理解的需求开发一个可以理解的需求n2.1 识别参与者n2.2 识别用例n2.3 构建用例图：确定参与者和用例之间的关系n3. 详细、完整地描述需求n进行用例阐述n4. 重构用例模型n4.1 识别用例间的关系n4.2 对用例进行组织和分包-26-
11、2.1 识别参与者n参与者，Actorn关键词：边界n参与者：在系统之外，透过系统边界与系统 进行有意义交互的任何事物-27-参与者要点n系统外n参与者代表在系统边界之外的真实事物，并 不是系统的成分n系统边界n参与者透过系统边界直接与系统交互，参与 者的确定代表系统边界的确定n有意义的交互n任何事物n人、外系统、外部因素、时间-28-题外话：人与猪(1)-29-人与猪(2)n众所周知，use case 图里的actor 用一个小 人表示。但是这个小人极具误导性，往往让初 学者（包括客户）理解为一个真实的人。大多 数UML 学习者都要花好长一段时间来搞明白 小人其实不一定代表的是人，而是很抽象
12、的系 统不可控的外部因素，比如说另一个系统。那 么为什么不干脆用其它的符号来表示Actor 呢 ？n如果我开发一个猪圈自动供食供水系统，猪的 前蹄触发一个开关系统就供食或供水。显然， 这里的Actor 是小猪。那么在use case 图里 用小猪代替原来的小人不是更易于交流吗？-30-思考：参与者与系统边界？n某企业要求开发一个企业信息管理系统 ，并与原来已有的库存系统相连接n某企业要求开发一个企业信息管理系统 ，并把原来已有的库存管理系统加以改 造，成为企业信息管理系统的一部分-31-思考：识别参与者？n寻呼台系统：用户如果预定了天气预报 ，系统每天定时给他发天气消息；如果 当天气温高于35
13、度，还要提醒用户注意 防暑；在这个叙述里，谁是寻呼台系统的在这个叙述里，谁是寻呼台系统的ActorActor？-32-识别参与者思路n谁使用系统的主要功能n谁改变系统的数据n谁从系统获取信息n谁需要系统的支持以完成日常工作任务n谁负责日常维护、管理并保证系统正常运行n系统需要应付（处理）那些硬设备n系统需要和那些外部系统交互n谁（或什么）对系统运行产生的结果（值）感兴 趣n时间、气温等内部外部条件n经过若干次谈话，终于有了一个较为清晰的需求经过若干次谈话，终于有了一个较为清晰的需求参与者： 教务处管理人员、学生、老师、各院系教学秘书、教研室主任 使用情况： 教务处管理人员：发布公共课课程信息、
14、安排公共课上课地点、 时间，增加或删除公共课、修改公共课课程信息（时间、地点） 、发布新闻 学生选课、查询成绩 老师申请新课、登录成绩 教学秘书发布专业选修课备选信息、安排专业选修课上课、修改 课程信息（对公共课只能修改授课教师）、发布新闻 教研室主任审核新开课程寻找参与者：网上选课系统-34-2.2 识别用例n关键词：价值n定义n用例实例是系统执行的一系列动作，这些动 作将生成特定参与者可观测的结果值n一个用例定义一组用例实例n简洁：参与者使用系统达到目标-35-用例要点n可观测用例止于系统边界n一组用例实例用例的粒度n结果值用例是有意义的目标n系统执行结果值由系统生成n由参与者观测业务语言
15、、用户观点-36-要点：用例止于系统边界描述交互，而不是内在的系统活动描述交互，而不是内在的系统活动-37-要点：有意义的目标-38-要点：结果值由系统生成系统需要处理的，由系统生成系统需要处理的，由系统生成-39-要点：业务语言而非技术语言n用户词汇，而不是技术词汇n如：发票，商品，洗衣机n而不是：记录，字段，COM，C+等-40-要点：用户观点而非系统观点用户观点用户观点系统观点系统观点-41-用例 VS. 功能呼叫某人接听电话发送短信记住电话号码传输/接收电源/基站输入输出（显示、键盘）电话簿管理用户观点用户观点系统观点系统观点-42-用例的命名n执行者视角：n（状语）动词+（定语+ ）
16、宾语-43-要点：用例粒度-1n用例要有路径，路径要有步骤；而这一 切都是可观测的n最常犯错误：粒度过细，陷入功能分解n过细的粒度，一般都会导致技术语言的描述 ，而不再是业务语言-44-用例粒度-2n把步骤当用例n把系统活动当用例是不合适的-45-思考：识别用例-1nEmail客户端（如：outlook express），A 在北京发邮件给上海的B，系统提醒B你有“新 邮件”，B收邮件-46-思考：识别用例-2寻找用例：网上选课系统经过若干次谈话，终于有了一个较为清晰的需求经过若干次谈话，终于有了一个较为清晰的需求参与者： 教务处管理人员、学生、老师、各院系教学秘书、教研室主任 使用情况： 教务处管理人员：发布公共课课程信息、安排公共课上课地点、 时间，增加或删除公共课、修改公共课上课信息（时间、地点） 、发布新闻 学生：选课、查询成绩 老师：申请新课、登录成绩 教学秘书：发布专业选
