3.用例驱动的需求分析方法

1、面象技术与哈尔滨工业大工面象技术与哈尔滨工业大工象技术与面徐汉需求回需求的分3.2用例技3.3 敏捷开发中的用户故2质量要求：可以工作质量要求：可以工作；进度要求：在预定的时间完成功能要求：完成用需求要求：约束下完成.开发要能够满足各方面的需3的数字是的数字是这样的45“构建一系统“构建一系统的部分是确定构建什么在出错之后严重影响随后实现的系统，并且在以后的修补是如此6开开发者开发的与用户所想得的存在着巨大期望差异7“IEEE, 需求“IEEE, 需求：以一种清晰、简洁、一致且无二义性的方式，描述用户目系统在功能、行为、性能、设计约束等方面的期望，是在发过程中对系统的约束需求通常用于表达“做什

2、么”，而不描述“如何做”8“RequirementistheBasicsof“RequirementistheBasicsof为9角度改变尺度把握角度改变尺度把握需求回需求的分3.2用例技3.3 敏捷开发中的用户故功能性需非功能性需业务需项目视图与范围文业务规用户需非功能需用例文功能性需非功能性需业务需项目视图与范围文业务规用户需非功能需用例文系统需约束条需求规格说需求的层次性需求的层次性业务需求(Business Requirements)：客户对于系统的 (high-levelobjectives)，业务需求(Business Requirements)：客户对于系统的 (high-lev

3、elobjectives)，定义了项目的远景和范畴(vi次目标要and例资料管理系统”的业务需。用户需求(User Requirements)：从用户角度描述的用户需求(User Requirements)：从用户角度描述的系统功能需求与功能需求，通常只涉及系统的外部行为而不涉特性例用户可以通ernet随时查信息和个人借阅情况，并可快速查找和浏览需要的电子资料针对CourseRegistration业务需 针对CourseRegistration业务需 用户需学生希望在选课期间系统能够24小时使用，系统使用方便快捷系统需求(System Requirements, SR)：系统应该系统需求(S

4、ystem Requirements, SR)：系统应该提供的功能或服务通常涉及用户或外部系统与该系统之间的交互，不考虑系统现细节；的例将用户需求转化为系统需求的过程是一个复杂的过程业务需求指导需求将用户需求转化为系统需求的过程是一个复杂的过程业务需求指导需求转化用户需求为系统图 不同抽象层次需求之间的联Functional Requirements, NFR)：从各个角Functional Requirements, NFR)：从各个角度对非功能需求系统质量和性能统的约束和限制，反映了客户andperformance)的额外要求，如响应时间、数据精度、可靠性等例注意：非功能需求隐含了对可选设

5、计方案的一些关键影体系结构设计(e.g.体系结构风格选择算法设计(e.g.排序策略的选择非功能性需求非功能性需求可支持性(Supportability):需求关注于在进行部署后系统的变化状况，比其他需求其他需求的等NFR：检验起来非，一NFR：检验起来非，一般采用一些可度量的特性进行描述例如 应修改为NFR：检验起来非，一般采用一些可度量NFR：检验起来非，一般采用一些可度量的特性进行描述失败时数的可能业务需求：“用户能有效地业务需求：“用户能有效地纠正文档中的拼写错误” 用户需求：“找出文档中的拼写错误，并通过一个提供的替换项列表来供选择替换拼错的词”；系统需求框非功能性需求正确的找到至少9

6、5%以上的错词并100%拼写检查的速度应至少达到5000约束条件s)：系统设时必须满约束条件s)：系统设时必须满足的限制条件对其进行权衡或调整是相的，甚至是不可能的例如系统开发过程和交付文档需遵循GB/T 85672006标准；政策、硬件/资源限制、开发语言、等等来源业务规则(BusinessRule)：对某业务规则(BusinessRule)：对某些功能的可执行性或通常表达为“如果，那么执行逻辑例如如果借书卡类型为“教师”，那么一次借阅的最大数量为8本如果订单金额大于10000元，那么该订单的折扣为如果采购单金额在10万到50万之间，那么需要总经；外部接口需求erface Requireme

7、nt)：描述系统与其所外部接口需求erface Requirement)：描述系统与其所处外部环境之间如何进行交互，包括通例如完整性：每一项需求都必完整性：每一项需求都必须将所要实现的功能描述清正确性：每一项需求都必须准确地陈述其要开发的功能可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从标下划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量无二义性：对所有需求说明的读者都只能有一个明的解可验证性：检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品

8、是否确实按需求实现活需求开产出需求管需求获活需求开产出需求管需求获需求分规格说需求验(1)需求获取、(2)需求获取需求分析ysis)：对收集(1)需求获取、(2)需求获取需求分析ysis)：对收集到的需求ion)：通过与用户交流，对现有系统的观察及行提炼、分析，为最(3)需求规格说明、(4)需求规格说明(Software Requirement (3)需求规格说明、(4)需求规格说明(Software Requirement Specification, 段需求验证(Requirement Verification)：以需求规格说明为输入，(5)需求管理(Requirement(5)需求管理(

9、Requirement定义需求基线(迅速制定需求文档的主体估计变更需求所产生影响并在此基础上协商新的承诺(约定需求回3.2 用例需求回3.2 用例驱动的需求分用3.2.2 用例建模的基本过3.2.3 用例模型的提交3.2.4活动图&泳道3.2.5案例分3.3 敏捷开发中的用户故结构化分析结构化分析方法：从数据的“输入加工输出”着眼，以“自顶下”的方式进行功能的分：非常容需求和设计的：非常容需求和设计的界限，这样的表述实际上已经包含了部分的设分各项系统功能的应用环境，从各项功能项入手，很难了解到这些功用例(Use用例(Use Case)：表示系统所提供的用例(Use用例(Use Case)：表示

10、系统所提供的服务或可执行的某种行需求：“系统做什么中增加三个词“for user”，使问题变为“系统应该为每个用户做什么?”，系统对用定义了系统是如何被参与者所使用的，描述了参与者为了使用系统所提供”（活动交互用例的概念在1986年由IvarJacobson，已成为OO、UML、RUP用例方法的基：从用户的角度来看，他们并不想了用例方法的基：从用户的角度来看，他们并不想了解系统的部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的。用例模型主要由以下模型元：参与者(Actor)：存在于被定义系统外部并与该系统发生交互的人或其他系用例(Use系统边界(Syste

11、mBoundry)通讯关联(Communicationtion)应关系，它表示参与者使用了系统中的哪些服务(用例)(用例)是被哪些参与者所使用的系统边用例：站在用户角度定四大特征用例：站在用户角度定四大特征系统的外部特行为序列ofactions)，这些行为是不可再分解的(接收用户输入、执行、产生结果为系统执行(systemperforms)可观测到的、有价值的结果(observableresultofvalue)：用例必须对用户特定的角色(particularactor)：Use参与者客参与者客客户使用自动提款机来帐户的查询、取款和转通讯关联表示的是参与者和用例之间的关系通讯关联表示的是参与者

12、和用例之间的关系的主动发起者，箭头所指方的用例用例名字？用例是文本文档，而非图形，用例图是系统的蓝图；用例建模主要是编写文本的活动，而非制图。用例模型：一张或几张用例图+若干用例描述文UseNameoftheUseCase用例的名字Description描述) Actor(s) (参与者)Flowofevents(事件流) Basic flow(常规流) Event 1 (事件)EventAlternate flow(扩展流) Pre-conditions (前置条件t-conditions (后置条件系统被看作是一个黑箱，并不关系统被看作是一个黑箱，并不关心能的是如何完成它所提供的首先描述了

13、被定义系统有哪些外部使用者(抽象为Actor)、这些使者与被定义系统发生交互针对每一参与者，又描述了系统为这些参与者提供了什么样的服务(抽象成为Use Case)、或者说系统是如何被这些参与者使用的；用例模型容易构建、书写简单、容易阅读强调了用户的目标和观点，从系统外部来描述功能是领或需求提供者自己编写（或参与编写）用例成为可能，参与到需求分析过程中来，其需求更容易表达出来用户能给出系统需求的情景，可以使人们理解需求的原因及系统如何实现它的目标需求回3.2 用例需求回3.2 用例驱动的需求分用3.2.2 用例建模的基本过3.2.3 用例模型的提交3.2.4活动图&泳道3.2.5案例分3.3 敏

14、捷开发中的用户故StepStep 1：确定系统边Step 2：识别并描述参与者Step 3：确定每个参与者目标，识别用例(use case) Step 4：识别参与者与用例之间的通讯关联Step5：给出每一个用例的详细描述 Step 6：细化用例模型Step1确定系统边界是为了识别出什么Step1确定系统边界是为了识别出什么在系统之内，什么在系统而识别系统的职责典型的系统边界包括中的部门或整个组织；硬件设备或件边界确定系统边界时要明例：学生成绩管理系Step2参与者的种类 主要参与者协助参与者(supportingStep2参与者的种类 主要参与者协助参与者(supporting幕后参与者(o

15、ffstage通过以下问题来识别(读写)那些外部硬件设备主要参与者置于图的左支持性参与者置于图的右主要参与者置于图的左支持性参与者置于图的右limittheusecasesto usergoal level usecases.ion the onthes. .例1：对一 管理系统来说，有哪些参与者例2：对ATM例1：对一 管理系统来说，有哪些参与者例2：对ATM系统来说，有哪些参与者有时候需要在系定时的执行一有时候需要在系定时的执行一些操作，如检测系统资源使用况、定期生成统计报表等等但这些操作并不是由外部的人或系统触发的对于这种情况，可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一

16、类定时操作；从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系所提供的用。在使用参与者为角色建模时是一种抽象，通常不为具体的人、机构、系统建模。李例：对在使用参与者为角色建模时是一种抽象，通常不为具体的人、机构、系统建模。李例：对职位的不合理建参与者一定是系统之外的人或外部系统参与者一定是系统之外的人或外部系统参与者一定是直接并且主动地向系统发出动作并获得反馈的去业务范围和系统范从业务角度或系统角度会得到不同的参与者机票预订系情况一：机机票预订系情况一：机者通过登机票情况二：机者通过呼叫中心，由人工坐席操作订票系机票，那么人工坐席才是真正的参与者，而机票心的参与者。者实际上是呼叫机票预

17、订系机票预订系情况三：机者通过呼叫中心的自动语音预定机票而不是人工席，则呼叫中心成为机票预定系统的一个参与者机票预订系情况四机票预订系情况四：如果扩大了系统边界，让呼叫中心成为机票预定系统的一子系统，并且假设机者可还是登预定机票，则机Step3：识别用例(use找到参与者之后，据此来确定系统的用例。主要分析各参与者目标，需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可Step3：识别用例(use找到参与者之后，据此来确定系统的用例。主要分析各参与者目标，需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手(针对每一个参与者、Use例1：馆管理系统

18、来说，有哪些参与者和用例 普例1：馆管理系统来说，有哪些参与者和用例 普通读者管理例2：对ATM系统来说，有哪些参与者和用例 客服务用例必须是由某一个actor触发而产生的活动，即每个用例至少应该涉及一个r。如果存在与用例必须是由某一个actor触发而产生的活动，即每个用例至少应该涉及一个r。如果存在与r不进行交互的用例，需要将其并入其他用例，或者是检查该用例相对应的参与者是否被遗漏。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在：用例必然是以动用例必然是以动宾短语形式出现不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。用例的执行结果

19、对参与者来说是可观测的和有意义测基本业务过测基本业务过程测 基本业务过程：一个人于某个时刻在一个地点所执行的任务，用以响应业务规模测 下面那个是有效用下面那个是有效用例-需要具体问题具体分误区1：用例和功能的误误区1：用例和功能的误，误区1：用例和功能的误 误区1：用例和功能的误 这个事物是什么这个事物能做什么人们能够用这个事物做什么例误区2：目标和步骤的误误区2：目标和步骤的误错误误区3：用例粒度的误误区3：用例粒度的误错误：用例过大或者过小过大：销售管理系统、采购管理系统；大粒度的合适还是小粒度大粒度的合适还是小粒度的合适业务建模阶 用例分析阶 用例能描述一个完整的事件流为宜，描述一项完整

20、业务中的一个步骤。如：系统建模阶 用例视角针对计算机，能够描述操作者与计算机的一次完整交互为宜，如：Step4Step4借管理读普通读预管信管理查询浏登记借借管理读普通读预管信管理查询浏登记借登记还Step5单纯的用例图并不能描述完整的信息，需要用文字描述形上的信息。在称为用例实例(usecaseinstance)。场Step5单纯的用例图并不能描述完整的信息，需要用文字描述形上的信息。在称为用例实例(usecaseinstance)。场景是使用系统的一个特定情节或用例的一条执行路径。例如：使用现金成商品的场景，或由付款造成失败场事件事件流（场景用例的事件流事件流（场景用例的事件流说明用例如何

21、启动，即哪些参与者在何种情况下启动用例说明参与者与用例之间的信息处理过程分为常规流和扩展流两类 常规流 扩展流/备选流常规事件流（场景每一个步骤都需要用数以清楚常规事件流（场景每一个步骤都需要用数以清楚地骤的先后顺用一句简短的标题来概括每一步骤的主要内对每一步骤，从正反两个方面来描 参与者向系统提交了什么信StepStep 对此系样的响StepStepStepStepStepStep扩展事件流（场景扩展流的描述格式可以与基本流的格式一致，也需要述其内容。并以标题Step扩展事件流（场景扩展流的描述格式可以与基本流的格式一致，也需要述其内容。并以标题StepStepStepStepStepSte

22、pStepStep以以无用户界面约束的本质风格编写用采用参与者和参与者目标的视案例用例描述用例：登记借1目标本用例允事件流常规流管案例用例描述用例：登记借1目标本用例允事件流常规流管理员登记普通读者的借当读者希望借书管理员准备登记有关的借时，本用例开始执行(1(3；扩展流读者没在主流程中，如果系统没有读者信息，系统将显示错误信息，用例结束(2所不存3 前置条件：用例开始前已被借出或者系统中无，系统将显示错误信息管理员必须在系统登录成功4 后置条件：如果用例执行成功，该读者的借被更新，否则，系统状态不变6案例用例描述 扩展（或替代流程案例用例描述 扩展（或替代流程 Step6在一般的用例图Ste

23、p6在一般的用例图中，只需表述参与者和用例之间的通讯关联除此之外，还可以描述参与者与参与者之间的泛化利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来用，使得用例模型更易。1.参与者之间的关系：泛化actor参与者1.参与者之间的关系：泛化actor参与者之间可以有泛化(Generalization)关系actor常规操用管理操管理员配置操“包含关系”是通过在关联关“包含关系”是通过在关联关系上加入标记来表示；用例指向被包含用例语义：用例1会用到用例2（无条件执行），用例2的事件流将到用例1的事件流中；基用例不能独立存在，必须依赖它的包含用例；被包含用例一定要执行一般表示为公共功入当一

24、个被包含的用例执行的时候，它在用例说明中当一个被包含的用例执行的时候，它在用例说明中体现为一个包含的用例）。包含点指明了在外层用例的什么位置执行被包地理信息系值应急组现邮件系应急预案启 事件编事件接事与反快速通“扩展关系”是通过在关联关系上加入标记来表示；扩展用例指向基用例(被扩展用例)语义：用例1在某“扩展关系”是通过在关联关系上加入标记来表示；扩展用例指向基用例(被扩展用例)语义：用例1在某些特定情况下（有条件执行）会用到用例2，此时用例2的事件流入到用例1的事件流中基用例能独立存在，不依赖于它的扩展用例；扩展用例可以不执行一般表示为异常功能，大多是扩展流一个用例中有许多替代物或选择时使用

25、扩展关系，管理变用例之间的关系：扩展打 常规流用例之间的关系：扩展打 常规流扩展流拨1a如果应答方正忙，用铃声建立通话链示应答方并保持拨号呼1b如果应答方无应答，进3 4扩展点)：用例行扩展点)：用例行为中扩展时机的点扩展点需要在用例文档中指明，也可以在用例图中指明例：取款(Withdraw)用例记载了一个打印的扩展点，打印收据Receipt)的行为入到打印扩展点WithdrawUseCase:Mainflow 输输入提款金退吐选择是否打印收据:打ExtendingUseReceiptUse进打吐扩展例：顾客订票(Reserve 例：顾客订票(Reserve Ticket)后，在选位(Assi

26、gn Seat)扩展用例，有三个扩展点:查询、选位、打印，入到流程的不同位置一个扩展关系会连到多个扩展点，有多个执行片断，但可以不需次执行完一个扩展点会连到多个扩展关系，可同时执行多个扩展用例(启动打，两个用例：显示收据，打印数据)优点：包含关系可指定共同功能，扩展关系可简化复杂流程优点：包含关系可指定共同功能，扩展关系可简化复杂流程：面包含的用扩展的用否是否是否是否是当多个用例共同拥有一种类似的结构和行为的时候，可将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用当多个用例共同拥有一种类似的结构和行为的时候，可将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。子用

27、例继承了父用例所有的结构、行为和关系例标出下面用例图上的关例标出下面用例图上的关例确定下面例确定下面用例模型中的几种关需求回3.2 用例需求回3.2 用例驱动的需求分用3.2.2 用例建模的基本过3.2.3 用例模型的提交3.2.4活动图&泳道3.2.5案例分3.3 敏捷开发中的用户故1用例1用例模2 每个用例的详细描3 术语表：所用到的术语说4 补充规约：非功能性需求的说需求回3.2 用例需求回3.2 用例驱动的需求分用3.2.2 用例建模的基本过3.2.3 用例模型的提交3.2.4活动图&泳道3.2.5案例分3.3 敏捷开发中的用户故活动图& UML活动图(ActivityDiagram)

28、提供活动图& UML活动图(ActivityDiagram)提供一种可视化的流程图方式，对Use 同时，UML活动图也可多个用例之间所形成的大粒度流程两种形式传统的活动图：只涉及一个参与者泳道图(swim-lanediagram)UML活动活动图的基本要素UML活动活动图的基本要素顾客携带商品付收银员开始一个顾客携带商品付收银员开始一个新交收银员输入商品条继续输完收银员告知顾客付款总刷现现金支支打印销售小完成交顾销售顾客携带顾销售顾客携带商品付现刷现金支支收银员开始一个新交收银员输入商品条继续输完收银员告知顾客付款总打印销售小完成交需求回3.2 用例需求回3.2 用例驱动的需求分用3.2.2

29、用例建模的基本过3.2.3 用例模型的提交3.2.4活动图&泳道3.2.5案例分3.3 敏捷开发中的用户故案例1 基本用(2)案例1 基本用(2)(4)参与案例1 预约（Record Booking）用预约事件案例1 预约（Record Booking）用预约事件流（常规事件流、预约，没有可用的餐桌（可选的事件流案例1 预约（Record Booking）案例1 预约（Record Booking）用例预约，餐桌过小（例外的事件流、案例1 注意事(1)事件案例1 注意事(1)事件(2)可选的事件流表示是允许中断基本事件流，可能会有另外的功能，如可(3)(4)记住，此例中接待员的职责就是是否能够

30、进行预约案例1 到达(Record arrival)用到达事件案例1 到达(Record arrival)用到达事件到达，无提前预定:可选事件案例1 可选事件流预约用例事案例1 可选事件流预约用例事件流存在共享功能，均包含显示预约能，增加“显示预约用例显示预约用例基本事件(1) (2) 预约（Record Booking）事件流(修改(1(2、(3) 案例1 案例1 案例1 到达(Record arrival)用未预约顾客事件流(案例1 到达(Record arrival)用未预约顾客事件流(修改(3) 在到达可选事件流中， 若系统一个顾客的预约，侍者领到达用例(Record arrival)

31、将创建一个未预约登记。这未预约顾客用例(Record Walk-in)之间是有关系的。什么关系案例1 取消预约(Cancel案例1 取消预约(Cancel Booking)用取消预约用例事件流(1(2) (3(4调换餐桌(Transfer table)用调换餐桌用例事件(1(2(3 案例1 案例1 案例用例商参与者：出案例用例商参与者：出纳类型：主要/次要/供选目的销售过程和支付过描述： 顾客带着的商品来到收款处，出纳下商品信息收款，付款完成后，顾客带着的商品离开从基本用例出发，快速获得对系统整个过程的理案例基本事件(1)顾客带着商品到达一个销售点终端，用例开始案例基本事件(1)顾客带着商品到

32、达一个销售点终端，用例开始出纳员录入每项商品的商品号，若出现相同的商品，出纳员还要录入该商品的数量确定商品价格，并将商品信息输入到正在运行的销售事务处理系统，显示当前的商品信息和商品价格。(4)输入完商品信息后，出纳员T发出提示，提示商品信息录入完毕(5)计算和显示该顾客的商品价值总额(6)出纳员将商品价值总给顾客(7)出纳员接收顾客的付款-顾客的付款可能高于商品总(10)出纳员收好现金并取出要找还给顾客的现金,将现金及打印的付款收据交给顾这次交(12)顾客带着的商品离案例扩展事件案例扩展事件输入的商品号无效，系统显示出错信息顾客没有足够的现金所选的商品，取消本次交易案例用例可以有判定案例用例

33、可以有判定点。现金支商品用例中，顾客的付款方式可以选择支支票支案例现金支付的过系统响参案例现金支付的过系统响参与者的动(1)顾客用现金支付商品，支付的金额可能大于商品的价值(3)显示找给顾客的余(2)出纳顾客所支余付的现金(4)出纳员收好顾客所支付的现金数，取出应找回给顾客的余额，并交给顾客可供选择的过(1)顾客没有足够的现金，可能取消交易或用(4)出纳员无零钱找，请管理员帮忙或顾客重新支式支案例支付的过参与者的动系统响(1)顾客提供他案例支付的过参与者的动系统响(1)顾客提供他信(2)产生一(4)接收来自CAS支付请求并机构批准信机这次支(5)发支付信息和批准应答息到应收款(6)显成功信可供

34、选择的过支付请求，要求顾客采用其他支付方案例支票支付的过参与者的动系统响案例支票支付的过参与者的动系统响(2)出纳这些标识信息并发(3)产生一个支票支付请求，并将其发一个支票支到外部支(5)接收来信息请求服务机构(4)支机了这次支付机构批准应(6)显成功信息可供选择的过(4)支票支付请求，要求顾客采用其他支付方式案例还有哪些情况没考虑?(规定和假设没有库存管商店案例还有哪些情况没考虑?(规定和假设没有库存管商店是个独立的商店,不是连锁店手工录入商品的UPC,无条形码读码机。不记税。商品不打折出纳员不一定非要登录进入系统,控系统中顾客购信息对装现金的抽屉无控制商店的名称、地址、交易时间和日期打印

35、在收据上出纳员的IDT的ID不打印在收据上己完成的购物交在一个历史日志当中案例3 用户管理：管理员案例3 用户管理：管理员和一般用户，权限管理计算机基本信息管理：录入、修改、删除、浏览、查询等计算机购置管理：购置申请等计算机调拨管理：调拨申请等计算机报废管理：报废申请等信息查询管理：品牌、型号、产地等案例3 计案例3 计算机管理信息系统用例此例的extend能否用include替换案例3 案例3 计算机基本信息管理用例案例3 案例3 计算机购置管理用例案例3 案例3 计算机调拨管理用例案例3 案例3 计算机报废管理用例案例4 教需要录入可选课程信息、任课教师案例4 教需要录入可选课程信息、任课

36、教师信息、学分政策，并从学管理系统中导入学生信息教师登录进入系统，查询本学期所开设课程课程；学生登录进入系统，查询本学期可选课，并选择自己所承担，并创建自己的选课，将某些课程加入到选课单中；学生可对选课单进行他课程、删除已选课程等；，包括加入学生也可对选课单中包含的数据进行学分政策验证，判断所选课程是否满足学校要求；在规定时间之前，学生将选课单做正式提交教检查每个学生的选课单，若不符合学分政策，退回重选。否，根据所有学生提交的选课单，生成课表和每门课程的学；教师可查看自己承担课程的课表与学，学生可查询自己的课表OOStepOOStep1：角色识Step 2：用例识别 Step3：绘制用例图St

37、ep 4：对用例图进行精针对每个Step 5：撰写用例Step 6：绘制用例的活动(泳道)Step7：识别分析类(边界类、控制类、实体类) Step 8：识别每个类的属性和方法Step9Step10：绘制领域类图 Step 11：绘制时序图步骤1：角色识教需要录入可选课程信息、任步骤1：角色识教需要录入可选课程信息、任课教师信息、学分政策，并从学管理系统中导入学生信息教师登录进入系统，查询本学期所开设课程课程；学生登录进入系统，查询本学期可选课，并选择自己所承担，并创建自己的选课，将某些课程加入到选课单中；学生可对选课单进行他课程、删除已选课程等；，包括加入学生也可对选课单中包含的数据进行学分

38、政策验证，判断所选课程是否满足学校要求；在规定时间之前，学生将选课单做正式提交教检查每个学生的选课单，若不符合学分政策，退回重选。否，根据所有学生提交的选课单，生成课表和每门课程的学；教师可查看自己承担课程的课表与学，学生可查询自己的课表步骤2：用例识教需要录入可选课程信息、任课步骤2：用例识教需要录入可选课程信息、任课教师信息、学分政策，并从籍管理系统中导入学生信息教师登录进入系统，查询本学期所开设课程的课程；学生登录进入系统，查询本学期可选课程，并选择自己所承，并创建自己的选单，将某些课程加入到选课单中；学生可对选课单进行入其他课程、删除已选课程等；，包括学生也可对选课单中包含的数据进行学

39、分政策验证，判断所选课程是否满足学校要求；在规定时间之前，学生将选课单做正式提交教检查每个学生的选课单，若不符合学分政策，退回重选。则，根据所有学生提交的选课单，生成课表和每门课程的学；教师可查看自己承担课程的课表与。，学生可查询自己的课步骤3：步骤3：绘制用例步骤4：对用例图进行精问题步骤4：对用例图进行精问题它与“查询开设课程”之间的关系是什么？include?如何修改问题选课单”与“加入其他课程”、“删除已选课程”之间什么关系？ 问题3：“检查学生选课单”是否有必要独立存在？它与“生成课表和”是什么关系？通常不会单独检查，而是在生成之前检查生问题4：“检查学生选课单”与“学分政策验证”是

40、什么关系？前者调用后者。步骤4：步骤4：对用例图进行精步骤5：步骤5：撰写用例描步骤5：步骤5：撰写用例描步骤5：步骤5：撰写用例描Step6：绘制用例的活动Step6：绘制用例的活动(泳道)Step6：绘制用例的活动Step6：绘制用例的活动(泳道)后续章节后续章节将继续此案例的分需求回3.2需求回3.2用例技3.3 敏捷开发中的用户故用户故事Aconcisewrittendescriptionofa用户故事Aconcisewrittendescriptionofapiecetwillbevaluabletoauser(orowner)of从用户的角度来描述用户渴望得到的功能：角色(谁要使用这个功能)三个组成部分(为什么需要这个功能CardAwrittendescriptionoftheuserstory forplanningpur a reminder 简要的文本陈述esandConversationAsectionforcapturingfurtherinformationabouttheuser story and details of any conversations 用户如何与系统交互ConfirmationAsectiontoconveywhatte