面向对象的需求分析

面向对象的需求分析-*-认识问题分析问题解决问题最终用户(提出问题)开发团队(解决问题)以用户的身份站在用户的角度认识问题获取需求—用例建模技术以开发者的身份站在用户的角度分析问题分析需求—用例分析技术以开发者的身份站在开发团队的角度分析问题解决需求—面向对象 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 -*-内容安排理解需求需求，难在何处？以用例为中心组织需求基于用例的需求分析过程-*-需求—建造“正确”的系统需求：系统必须满足的条件或具备的能力RobertGrady软件质量准则“FURPS”功能性（Functionality）使用性（Usability）可靠性（Reliability）性能（Performance）可支持性（Supportability）非功能性需求-*-内容安排理解需求需求，难在何处？以用例为中心组织需求基于用例的需求分析过程-*-需求，难在何处？自己到底想要什么？这是个问题-*-需求：也需要开发客户/用户的要求/想法/期望软件设计软件产品开发编码和测试验收有价值的软件需求分析和设计-*-获取好的需求需求收集包括五个关键步骤找到可以帮助你理解这个系统的人倾听这些相关人员的描述，并从他们的角度来理解系统利用一个容易理解的模型来描述用户希望如何使用这个系统以及为他们提供的什么价值详细地描述系统和客户以及系统和外部系统之间的交互重构（refactor）这个详细描述以保证它是可读且易懂的-*-内容安排理解需求需求，难在何处？以用例为中心组织需求基于用例的需求分析过程-*-需求问题：对策难捕获易变从用户视角看问题合理的结构用例-*-以用例为中心组织需求用例可用性可靠性网络 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 业务规则……硬件接口界面约束性能用例的相关概念参与者（Actor）用例（UseCase）事件流参与者(Actor)参与者是在系统之外于系统进行交互的任何事物。参与者触发系统某项功能的执行(通过向系统输入某些信息，或请求系统输出某些信息)。最常见的参与者人（操作人员或系统的服务对象）设备（监控系统的摄像头等信息采集器）外系统用例(UseCase)用例(usecase):是对系统某个功能的一组动作序列的描述，系统执行这些动作序列将产生一个对某个特定的参与者有特定价值的结果。用例表示系统外部可见的功能单元。简言之：用例就是系统某功能一次执行的例子。事件流事件流是系统完成需求行为的事件描述应尽量写的详细。事件流通常包括4部分：简要说明前置条件主事件流和异常事件流（错误流）事后条件（并不是每个用例都有）-*-内容安排理解需求需求，难在何处？以用例为中心组织需求基于用例的需求分析过程-*-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图3详细、完整地描述需求进行用例阐述4重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-*-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图3.详细、完整地描述需求进行用例阐述4.重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-*-获取需求的技巧（MSF）技巧描述实地观察直接观察个人工作的情况，以发现现存的实践方式和问题访谈从个人处收集特定信息特定群体调查对一组人员进行调查，以便了解工作态度和共同看法问卷调查收集详细数据和统计意义上比较重要的数据用户指导让最终用户告诉你，他们是如何操作系统的原型制作模拟一个无法直接测试的系统统计版本使用具有统计功能的应用程序来记录用户完成任务的方式(RequisitePro)-*-获取需求：应用程序初次访谈记录开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 ：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……-*-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图：确定参与者和用例之间的关系3.详细、完整地描述需求进行用例阐述4.重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-*-2.1识别参与者参与者，Actor关键词：边界参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物-*-参与者要点系统外参与者代表在系统边界之外的真实事物，并不是系统的成分系统边界参与者透过系统边界直接与系统交互，参与者的确定代表系统边界的确定有意义的交互任何事物人、外系统、外部因素、时间-*-题外话：人与猪(1)-*-人与猪(2)众所周知，usecase图里的actor用一个小人表示。但是这个小人极具误导性，往往让初学者（包括客户）理解为一个真实的人。大多数UML学习者都要花好长一段时间来搞明白小人其实不一定代表的是人，而是很抽象的系统不可控的外部因素，比如说另一个系统。那么为什么不干脆用其它的符号来表示Actor呢？如果我开发一个猪圈自动供食供水系统，猪的前蹄触发一个开关系统就供食或供水。显然，这里的Actor是小猪。那么在usecase图里用小猪代替原来的小人不是更易于交流吗？-*-思考：参与者与系统边界？某企业要求开发一个企业信息管理系统，并与原来已有的库存系统相连接某企业要求开发一个企业信息管理系统，并把原来已有的库存管理系统加以改造，成为企业信息管理系统的一部分-*-思考：识别参与者？寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；在这个叙述里，谁是寻呼台系统的Actor？-*-识别参与者思路谁使用系统的主要功能谁改变系统的数据谁从系统获取信息谁需要系统的支持以完成日常工作任务谁负责日常维护、管理并保证系统正常运行系统需要应付（处理）那些硬设备系统需要和那些外部系统交互谁（或什么）对系统运行产生的结果（值）感兴趣时间、气温等内部外部条件……-*-识别参与者：考勤卡系统开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……-*-2.2识别用例关键词：价值定义用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值一个用例定义一组用例实例简洁：参与者使用系统达到目标-*-识别用例：考勤卡系统开发者：谁将使用这个应用程序？客户：所有用它来记录可记帐以及不可记帐的工时的雇员……开发者：现在考勤卡应用程序是什么样的？客户：每半个月就用一个Excel表格来记录。每个雇员都将通过他的表格填好，然后用电子邮件发给我。这个表格相当标准：纵向是收费项目代码，横向是日期。雇员可以在每个条目上填写说明。开发者：这个收费项目代码可以从什么地方得到？……开发者：谁来管理收费项目代码？客户：嗯，必要的时候由我（业务经理）来添加这个代码。而每个经理总会告诉他的下属应该填写什么。……-*-用例要点可观测→用例止于系统边界结果值→用例是有意义的目标系统执行→结果值由系统生成由参与者观测→业务语言、用户观点一组用例实例→用例的粒度-*-要点：用例止于系统边界描述交互，而不是内在的系统活动-*-要点：有意义的目标-*-要点：结果值由系统生成系统需要处理的，由系统生成-*-要点：业务语言而非技术语言用户词汇，而不是技术词汇如：发票，商品，洗衣机而不是：记录，字段，COM，C++等-*-要点：用户观点而非系统观点用户观点系统观点-*-用例VS.功能呼叫某人接听电话发送短信记住电话号码……传输/接收电源/基站输入输出（显示、键盘）电话簿管理……用户观点系统观点-*-用例的命名执行者视角：（状语）动词+（定语+）宾语-*-要点：用例粒度-1用例要有路径，路径要有步骤；而这一切都是可观测的最常犯错误：粒度过细，陷入功能分解过细的粒度，一般都会导致技术语言的描述，而不再是业务语言-*-用例粒度-2把步骤当用例把系统活动当用例是不合适的-*-思考：识别用例-1Email客户端（如：outlookexpress），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件-*-思考：识别用例-2-*-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图3详细、完整地描述需求进行用例阐述4重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-*-进行用例阐述：写用例规约用例规约：更进一步的精度用例文档的核心，作为用例文档的总图进一步的精度：有层次的文档文档中每一句话都有其价值用例图是骨架，而用例规约则是其内在的肉-*-谁来写用例文档最完美：业务人员接受训练，写出优美的用例文档最现实：业务人员提供素材，开发人员写用例文档最糟糕：业务人员不管，完全由开发人员杜撰-*-用例规约组成用例名称用例标识涉及的参与者描述用例的规格说明前置条件PreConditions后置条件PostConditions正常事件流Flowofevents异常事件流Alternateflow其它非功能需求、设计约束、尚存在的问题-*-前置、后置条件-1前置条件约束在用例开始前系统的状态把它们看做是看门人，它阻止参与者触发该用例直到满足所有条件说明在用例触发之前什么必须为真后置条件约束用例执行后系统的状态用例执行后什么必须为真对于有多个事件流的用例，则应该有多个后置条件-*-前置、后置条件-2某些用例依赖于其他用例一个用例在离开系统时，可能是另一个用例的前置条件（例如：“登录”和“管理系统”）有助于识别漏掉的用例如果一个用例的前置条件不能由执行其他用例满足，可能意味着丢失了用例（例如：“管理订单”却没有“登录”用例）-*-用例交互四部曲-事件流1.动作4.回应2.改变3.验证系统写：可观测的、体现客户利益的文字-*-事件流描述要点1.只书写“可观测”的（说人话）2.使用主动语句3.句子必须以参与者或系统作为主语4.不要涉及界面细节5.分支和循环-*-要点1：只写“可观测”的系统通过ADO建立数据库连接，传送SQL查询语句，从“商品表”查询商品的详细信息…系统按照查询条件搜索商品的详细信息-*-要点2：主动语句欧文丛贝克汉姆处得到传球，守门员…贝克汉姆传球给欧文，欧文射门，守门员扑救…出纳员……系统……-*-要点3：以参与者或系统作主语参与者……系统……出纳员接收顾客的付款—顾客的付款数可能高于商品总额出纳员录入顾客所付的现金总额系统显示出应找还给顾客的余额，打印付款收据-*-要点4：不涉及界面细节会员从下拉框中选择类别会员在相应文本框中输入查询条件会员点击“确定”按钮-*-要点5：分支和循环找清楚分支条件和循环条件-*-基于用例的需求分析过程1.获取原始需求2.开发一个可以理解的需求2.1识别参与者2.2识别用例2.3构建用例图3详细、完整地描述需求进行用例阐述4重构用例模型4.1识别用例间的关系4.2对用例进行组织和分包-*-对用例进行分类用例和开发周期开发周期是围绕用例的需求来组织的一个开发周期要被指派一个到多个用例，如果完全版本的用例在一个开发周期中处理起来太复杂的话，那就采用简化版本的用例开发周期开发周期开发周期用例A-简化版本用例A-完整版本用例B用例C*用例分级每一个用例都要根据它的风险、对用户和架构的重要性、团队是否有能力开发进行分级。一旦用例已经按这些类别来分类，就可以确定哪一个用例的子集是最重要的，并适合在第一次系统的迭代中实现。这个过程包括一些权衡和妥协的综合考虑。例如，一个用例的风险可能很高，这使得我们想在第一次迭代中实现它。但是，如果开发团队对实现这种用例完全没有把握，那么，作为妥协，我们应该选择一个风险较低的、较容易实现的用例。*用例分级为了让这些工作简单一点，将用例的风险、重要性、合适性分成从1到5的五个级别。级别越高，那么这个用例就越适合在第一个或者下一个迭代中实现。考勤卡应用程序找到了6个用例，下图显示了这个高层用例图。*1．风险(risk)你应该尽可能在开发周期的初期攻克系统有风险的部分。然后，即使出师不利，你仍然有足够的时间和机会来试着用其他的方法来做。在考虑用例的风险之前，需要先列出项目的风险清单。以下的风险，对多数的项目来说都是存在的，它们可以作为考虑项目风险的出发点，并按此顺序考察每一个用例。无法接受的系统性能。无法应付新的需求。不确定的进度以及开发周期。无法接受的用户界面。*在按风险分级用例之前，我们将问开发人员这样一个问题：他们是否有把握在第一次尝试中解决某个问题，然后让他们从以下的答案中选择一个：1)当然可以，我们的项目团队以前解决过这种问题。2)没问题，我们机构以前解决过这种问题。3)可以采用第三方提供的产品、培训、书或者其他的技术资源，但我们内部没有任何经验。4)可能吧，我们听过类似的可以解决的问题。5)我希望可以，但我们得做一些开创性的工作。在评估用例的时候我们将会看到，这个简单的风险“谱”将帮助我们识别出在下一次迭代中必须考虑的高风险用例。*2．重要性(significance)如果一个用例差不多就是系统的愿景，那它对用户以及架构就是很重要的。一个重要的用例应该能够体现系统的特性和目标。其他的用例也可能会很重要，但它们只是扮演支持的角色。第12章 案例 全员育人导师制案例信息技术应用案例心得信息技术教学案例综合实践活动案例我余额宝案例 -续*是否可以这样衡量用例的重要性：我们询问开发人员，如果这个用例在本次迭代中忽略掉，或者用其他的用例来取代，那么用户将会怎样反应?让他们从以下的答案中选择一个：1)他们几乎不会注意到这个用例不存在，在没有它的情况下使用这个系统不会有什么影响。2)他们会注意到这个用例不存在，但是，稍加想像，这个系统仍然可以很好的使用。3)系统的大部分可以独立于这个用例。4)系统的一部分可以独立于这个用例。5)没有它，就不可能使用这个系统。在评估用例的时候我们将会看到，这个简单的“谱”将有助于识别出在下一次迭代中必须考虑的重要用例。*3．合适性(suitability)如果你的项目组可以只经过最少的培训以及相对短的学习曲线就可以开始开发某个用例，那么这个用例就比较合适你的团队。当在机构中引入新的技术、语言和开发方法时，这两个标准就显得特别重要。由于在为第一次迭代选择用例的时候我们并没有考虑到技术选择，因此很难判断开发某个用例时需要学习多少东西。而实际上，一个项目组一般都知道他们是否需要采用一个新技术，比如面向对象开发。而且，他们一般也知道要采用的语言或者一族语言。第12章案例-续*考虑到这些，我们可以要求开发人员描述他们对方法和技术的把握有多高，让他们从以下的答案中做出选择：1)这个团队绝对需要一段培训时间来开发这个用例。2)对于这个用例来说，团队可能有了足够的能力，但是在一次迭代之后，团队的能力将会有本质的提高。3)团队可能有了足够的能力，但在一次迭代之后这个能力不会怎么提高。4)不需要很多的培训。要么是团队的能力已经绰绰有余，要么是这个用例相当简单。5)不需要很多的培训。团队有足够的经验，用例也很简单。手到擒来。第12章案例-续*2)重要性这是一个非常重要的用例，整个考勤系统的功能就是为各种不同的目标收集并获取考勤条目。它应该评为第5级——“没有它，系统就不可能使用”比较合适。3)合适性这个用例相对简单，团队可以应付它。评为第4级——“不需要很多的经验。要么是团队的能力已经绰绰有余，要么是这个用例相当简单”比较合适。4)结论考虑到重要性，这个用例显然应该在第一次迭代中实现。这将有助于同用户建立信任，并提供重要的架构功能。*选择第一次迭代的用例对于一个有相当开发经验的团队，我们可以在风险和重要性的基础上确定第一次迭代的用例。“RecordTime”和“ExtractTimeEntries”肯定应该属于第一次迭代。“CreateEmployee”、“CreateChargeCode”和“ChangePassword”可以推迟实现，“Login”也可以推迟，但是我们将它包含进来，使第一次迭代看起来更现实点。将所有架构上重要的用例都放在第一次迭代中，在这次迭代完成后，相关人员就可以得到一个关于这个系统的清晰的印象，而且开发者可以通过这几个关键用例来确保解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 的完整性。则第一次迭代的用例是：“RecordTime”、“ExtractTimeEntries”和“Login”。-*-用例分类原则用例分类的一个基本原则高级别的用例是那些对系统核心体系结构影响最大的用例提高用例级别的特性：a.对体系结构设计有重要影响的用例，如在领域层中增加多个类的用例或者需要持久化的用例b.不需要花费很多努力就可以从中获得重要信息和线索的那些用例c.含有开发风险、时间紧迫或功能复杂的用例d.涉及到重要技术研究或者新技术和高风险的用例e.代表主要的在线业务流程的用例f.能产生直接经济效益或者降低成本的用例-*-用例分类实施策略(1)可以使用一个简单的但是有些不精确的分类方法，如将用例划分成高、中、低三个等级-*-用例分类实施策略(2)依照上述的影响用例级别的特性给用例打分（用例也可能带有权值-*-用例的组织对用例进行分包让用例图能够更为清晰地表现出系统的业务逻辑关系和层次对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式常见的分包方式按参与者分包按主题分包按开发团队分包按发布情况分包可以先按主题分包，主题内再按开发团队和发布情况分包