目录
一、需求工程、需求获取、需求分析的概念
1、需求工程：需求工程是介于系统工程和软件设计之间的重要桥梁。一方面，需求工程以系统规约作为基本出发点，并从软件角度对他们进行检查和调整；另一方面，需求规约又是软件设计，实现，测试直至维护的主要基础。
2、需求获取：需求获取是需求工程中后续活动（分析，规范化等）的基础，需求工程又是后续软件开发活动的基础。所以，需求获取对于软件项目的成败具有决定性影响。
3、需求分析：需求分析活动是在需求获取的工作成果的基础上展开的，其输入制品与需求获取活动的输出制品相同，在这些输入制品中，用例模型最重要。需求分析的输出制品主要是软件需求的分析模型，该模型是需求规约的主要组成部分，同时也是后续软件设计、构造和测试活动的工作基础。
二、需求的三个层次：业务需求、用户需求、系统需求
1、业务需求：是组织或客户对于系统的高层次目标要求，定义了项目的远景和范围，即确定软件产品的发展方向，功能范围，目标客户和价值来源
2、用户需求：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。
3、系统需求：更加详细的描述系统应该做什么，通常包括许多不同的分析模型：用例图，交互图，分析类图，状态图
三、需求的两大分类：功能需求、非功能需求
1、功能性需求：描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。
2、非功能性需求：从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如相应时间，数据精度，可靠性，开发过程的标准等。
四、怎样画用例图
用例图的节点有执行者和用例两种。用例图的边表示执行者与用例之间，两个用例之间，两个执行者之间的关系。
(1)执行者与用例之间的关系
执行者与用例之间的关系在用例图中表示为它们之间的连接边，其意义为执行者触发用例的执行，向用例提供信息或者从用例获取信息。触发用例执行的执行者称为主动执行者,仅从用例获取信息的执行者称为被动执行者。执行者与用例之间的连接边通常为无向边。对有向边的使用应当慎之又慎，因为用例模型的阅读者往往误以为有向边代表信息传递的方向。仅在以下两种情形下考虑采用有向边。
①当有多个执行者与用例相连时，有时为了强调其中某个执行者是该用例的主要执行者(primary aclo) .则从该执行者到用例之间连一条有向边。 在这种有向边之上，信息传递仍可能是双向的。执行者需要提供初始信息以启动用例，用例的执行结果也可反馈至执行者。
②为了强调被动执行者仅从用例获取信息，而不向用例提供信息，可以从用例到被动执行者之间连条有向边。
(2)用例之间的关系
用例之间的关系主要有3种:包含( include)、扩展( extend)和继承( ineritance)。业中
①如果B是A的某项子功能，并且建模者确切地知道在A所对应的动作序列中何时将调用B，则称用例A包含用例B。包含关系经常被用来将多个用例中公共的子功能项提取出来，以避免重复和冗余。
②如果A与B相似,但A的功能较B多,A的动作序列是通过在B的动作序列中的某些执行点上插人附加动作序列而构成的，则称用例A扩展用例B。在扩展用例的情形下，允许建模者不确定何时会出现导致附加动作序列必须执行的情况，甚至不确定这些情况是否会发生。A的附加动作在B的动作序列中的插人点称为A对B的扩展点。扩展关系经常用来区分正常的业务处理功能和带有例外处理的功能，这样可避免例外处理逻辑搅乱或湮灭正常处理逻辑。
③如果A与B相似，但A的动作序列是通过改写B的部分动作或者扩展B的部分动作而获得的，则称用例A继承用例B。用例之间的继承关系同样必须符合针对类间继承关系的可替代性原则:任何特化用例都可应用于其泛化用例能够应用的场合。从定义上看，用例之间的继承关系与扩展关系非常类似。在面对实际问题时，可按以下规则来决定二者的取舍:如果能够指出明确的扩展点，则采用扩展关系;如果希望区分正常的业务处理功能和带有例外处理的功能，应采用扩展关系;如果不仅要插人新动作，还要修改原动作，则采用继承关系。
为避免语义上的复杂性，用例之间的关系不应超过两层。例如，如果用例A B C.D之间依次两两之间都有包含关系，则表明建模青采用1功能分解方法，这与用例列列建模所处的需求工程阶段不协调，也不符合面向对象的思维方式。
在用例图中、每个执行青必须至少与一个用间相关联:反之，除被包合文例相关联，那么它就没有必个用例必须至少与个执行者相关联。 如果个执行者来 与任何用代该将它与其(用例继承要在用例图中出现。如果被维承的用例未与任何执行者相关联.那么应该将他与其特化用例合并。
(3)执行者之间的关系
在用例图中，执行者之间的关系只有继承关系一种,其意义与面向对象中基本的继承关系相似，但它主要强调子类执行者对父类执行者与用例之间的交互行为的继承。如果执行者B继承执行者A.A触发执行用例uC,那么B与uc之间的触发执行关系即不必显式表示。
(4)布局规则
用例图的布局决定了其可理解性。建议读者采纳以下布局规则:
①主要的执行者应置于用例图的左上区域。
②触发用例执行的主动执行者应位于用例的左面，接收用例产生的信息的被动执行者应置于用例的右面。
③多个用例沿垂直方向排列。如果用例A的执行时间一-定在B之前，那么最好将A置于B之上。
④在水平方向绘制包含关系,并将被包含的用例置于包含用例的右侧。
⑤在垂直方向绘制扩展和继承关系，并将扩展用例置于被扩展用例的下方,将继承用例置于被继承用例的下方。
五、用例描述的注意事项
1、前置条件：必须是系统在用例开始之前能检测到的。
2、后置条件：用例执行后对系统产生的所有改变
3、事件路径：书写尽量使用主动语句，以参与者或者系统为主语，不要涉及软件实现的细节(例如选择菜单、单击按钮或者修改数据库等)
4、事件路径的扩展点：一般是由参与者或系统引起的变更而形成的事件流
六、分析类、边界类、实体类、控制类的概念
1、分析类：分析类用于获取系统中主要的“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。如果期望获得系统的“高级”概念简述，则可以对分析类本身进行维护。分析类还可以产生系统设计的主要抽象一一系统的设计类和子系统。
分析类是跨越需求到设计的桥梁。分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类逻辑化，被计算机理解。
总用有三个分析类:边界类，控制类和实体类。
2、边界类：边界类位于系统与外界的交界处，承担系统与外界的信息功能；边界类处在用例图中，参与者与用例的关联处，可以根据用例图发现边界类
3、实体类：实体类对应着现实中的客观事务，用来保存信息，一般对应着数据表，文件等；实体类可以从现实中存在的客观事务，以及需要持久存放的信息两方面来发现
4、控制类：控制类承担着事务处理，控制调控的控制作用；一个用例中至少会有一个控制类，用来控制用例中的事件顺序，也可以在多个用例之间协调之间的联系
七、分析类图的阅读
