一、定义边界

之前的文章关于边界，我们看到过，边界可大可小，不可衡量和无章可循。定义边界的目的是为我们确定一个分析的起点，边界会随着设计的深入而变得明确。

有没有茅塞顿开呢？

总结一:
要定义边界，可以根据业务目标确定业务主角，业务目标是为谁服务的。得出哪些是边界内边界外。

第二: 每个业务目标都有一个边界存在，边界的划分则指明了我们需求分析的起点。

不是在任何时候以业务目标为依据都是有效的，这是因为不是什么形式的系统都可以明确的题出业务目标。例如如果准备开发的系统是以计算、控制、自动化等为目的的，会比较难以找出业务目标。但是以业务目标为依据来划分边界这个思路还是可以适用的。

即使一个系统没有明确的业务目标，也有一些功能性目标的，也成为系统特性。比如手机的嵌入系统，其功能目标包括打电话、接听电话、电话薄等等，也可以用来建立边界，类似业务目标。

边界确立后，就可以获得业务主角，这些主角对这个边界代表的系统提出期望，就获得用例了。

总结: 主角、边界、用例三者相互影响。边界最为重要，定义了边界，主角就能确立，定义了主角，用例就能被发现。边界又来自某个特定的系统目标，这个系统目标可能是业务目标，也可能是系统特性。

二、发现主角

首先根据涉众报告中的涉众概要可以得到备选的涉众列表，其次所定义的边界，可以从中寻找哪些站在边界外的涉众。用主角的定义去审查这些备选的涉众在此边界内的行为，从中可以找出符合定义的涉众形成的主角。

三、发现业务用例

获取业务用例有很多方法，可以从岗位手册、业务流程指南等一些文件中获得，也可以涉众分析获得灵感，另外一种就是业务主角访谈获得。

我们可以通过以下问题引导业务主角代表说出他们的业务需求:

您对这个系统有什么期望？
希望这系统实现什么事？
做这件事的目的？

当客户谈及系统期望时，通常不是业务需求，更多会谈及希望系统能帮他们做什么？从这些期望中获取需求不容易，我们需要自己去分辨。需求分为功能性需求和非功能性需求。

在初步了解业务时，需要防止陷入业务细节，应当引导客户从独立的业务模块开始讲起。

判断用例是否合理是以该用例是否完整的达成了业务主角的一个目标为标准的，因此访谈中应引导客户从每一项业务的起因和目的(要达成的业务目标)谈起。

在获取业务用例时，不应当从谁做了什么作为出发点，而应当从谁为了什么而做什么作为出发点。

所谓的功能性需求是指如果缺少了它，业务目标就不能达成。而业务规则是指可以从业务员的期望提炼出一些非功能性需求。这些规则可以用来辅助和约束业务目标，因此他们应当是业务规则。通常情况下，业务规则也需要编码实现的。

通过之前的一些访谈我们会得到如上图所示的两个实例图，这些视图在业务方和建设方之间定了一个契约。如果双方都同意，那么该业务目标就是由这些构成的，系统建设的业务范围就这样初步确定下来。!

业务用例找到了，还需要使用适当得视图展现出来，而不是直接列出来。业务用例是在系统建设早期进行得，业务用例可以作为业务范围，也就是项目范围来使用。

四、业务建模

一个完整的业务用例建模包括:
业务用例视图
业务用例场景
业务用例规约
业务规则
业务对象模型
业务用例实现视图
业务用例实现场景
包图
业务用例视图在获取业务用例的时候已经基本完成了。

业务用例场景是用来描述该业务在实际过程如何做的，绘制这个业务用例场景可以使用以下用具（状态图），例如：
要描述参与者参加业务的职责和活动，可以用活动图来描述。
如果要强调该业务的完成时间顺序，可以使用时序图。
如果要描述参与该业务的各个参与者值加的交互过程，可以选择协作图。

一般是建议将活动图作为描述业务用例场景的必选方式，而时序图和协作图作为辅助。这是因为分析业务的阶段，最主要是得到参与者的职责。此时离设计与编程还很远。

使用活动图来描述业务用例场景，必须将参与者与业务工人作为活动图的泳道，将参与者和业务工人所完成的工作作为活动，。依据实际流程中的执行顺序将这些活动连接起来，形成业务用例场景。

场景必须符合两个基本要求:

1. 必须忠于真实业务
   

   2.一个场景只能描述业务的一种执行方式。就是说描述时不能带有设计、抽象、优化等。如下图示例：
   
   在绘制完这个场景后，就可以得到各个参与者职责和业务执行得过程了，职责代表将来用户要在系统做什么，活动代表将来系统设计得方向和内容。
   

   !

业务用例规约

业务对象模型

业务对象模型就是对业务用例中涉及得业务实体进行建模，不过业务对象的建模过程实际上一般是在稍后的领域建模中建立的。

业务用例实现场景

与业务用例场景有细微的区别，会比较着重描述如何通过人机交互来完成业务。跟客户就如何操作达成共识。这个也是制作系统原型的依据，会比业务用例场景细节很多，包含了实现的细节。

包图

在业务建模中，包图更多用于信息分类，例如将业务用例分类，将参与者分类。

包的分类没有一定的规矩，可以按业务部门分类，也可以按业务模块分类，也可以按业务过程。。。。

（用例： case,就是一个特定的事件，比如包含一个特定的目标、执行人和执行过程，执行人和执行过程是为了达到特定目标）

五、领域建模

顾名思义，建立领域模型首先要确定领域，才能为之建模。

领域就是我们分析问题时将整体分解后的相对独立部分。分解问题是人们了解事物的基本手段。但是确定领域的思路与确定业务用例及其过程方法的功能分解是不一样的。

建立领域建模，我们需经过提出领域问题，分析领域问题、建立领域模型和校验领域模型这些步骤。

1. 提出领域问题
   需要进行第二部分析，需要先了解关心该领域的所有可能涉众是如何理解和要求该领域的。
2. 分析领域问题
   提出问题领域后，需要进行秋节。实际上，领域模型要实现的就是为问题领域寻找和建立起合适的业务对象，由这些对象相互之间的交互来满足问题领域的需求。
   3.建立领域模型

4.校验领域模型

六、提炼业务规则

很多项目在建设时都不太注重业务规则，被当成是编写程序时的程序逻辑了。业务需求说明了人们希望系统做什么，而业务规则则说明人们希望这个系统怎么做。

在thinking in UML中，作者主张将业务规则提升至重视级别来对待，分为以下三类:

1.全局规则

是指对于系统的大部分业务或系统涉及都起约束作用的那些规则。在这里，所谓全局是与用例相关的，全局规则就是跨越用例的规则。会与所有用例相关，比如参与者操作用例需要获得响应的授权或登录，这就是所有用例都相关。在比如用户在系统的所有操作都需要记录，这也是对所有用例相关。

全局规则与非功能性需求有些相似，但是有着本质的区别: 非功能性需求都是系统目标，即系统要做到什么，而且会有一个指标来衡量，例如会话峰值并发数，而全局规则是用来限制功能性需求的，例如会话数量达到设定阙值时暂停新会话建立。全局规则一般会影响软件系统架构，全局规则的书写可以i使用表格形式

2. 交互规则

交互规则一般产生于用例场景中，用例场景是由活动图、交互图等来描述的，无论是获得、状态还是业务对象，他们在活动转移、状态变迁和对象交互时必然会有一些限制性条件。

比如订单提交，需要检查哪些数据必须填写，用户身份是否合法，否则提交不能成功。一般要写到用例规约中，因为他们与特定的用例场景相关，仅在用例场景中生效。

3. 内禀规则

是指那些业务对象本身具备的，并且不会因为外部的交互而变化的规则，比如每张订单至少一件商品，同一类商品数量不能大于几件，另一类是通用的数据校验规则，手机号，身份证号等。

内禀规则应该尽量封装到对象中去根据面向对象的规则。

分类业务规则对开发的意义

将业务规则进行分类将为系统开发带来许多好处，需求分析师专门进行需求收集和分析情况形成需求文档，架构师根据需求文档涉及软件架构和技术框架，决定技术路线，设计时在软件架构和技术框架内将需求转化为需求文档，解决从需求到实现的问题，程序员则根据设计文档编写程序真实需求。

七、获取非功能性需求

非功能性需求总是在固定的几个范围，完全可以通过固定的程序一个个收集整理，复杂的是随着软件规模不断扩大和应用环境日趋复杂，要确定非功能性需求指标需要考虑越来越多的因素了。

主要围绕以下几个因素:
一、可靠性

1、安全性

与业务内容和应用环境密切相关。看是否为政府安全相关的。安全性保障分为软件和硬件相关的。

2、事务性

就是保障系统的ACID能力，跟事务是一样的

3、稳定性

由故障的频率、严重性、可恢复性、可预见性、平均故障间隔事件等一些指标构成。

二、可用性

可用性用来衡量人们使用一个软件产品的满意程度，一般来说，可以从以下几个方面考虑:

易上手:客户需要多上时间掌握i软件的使用
使用频率: 客户需要多长事件、执行多少次操作来完成一个关键任务。
记忆性:当客户再次回来时，他们工作是否能够被记忆下来以便继续执行。
错误回复: 出现故障时，多久恢复，能否正常恢复。
主观满意度：客户使用软件是否满意。

三、有效性

有效性包括性能、可伸缩性、可拓展性这三个方面话题

性能包括速度、并发性、吞吐量、响应时间、资源占用等一些指标。

可伸缩性:指当向系统中增加资源时的性能改善，例如CPU、内存或计算机等。分为水平伸缩和存在伸缩。

垂直伸缩是指为系统置换更高级、快速的设备时性能的改善程度。假设系统是没有经过良好的涉及，程序有低效算法，存在IO瓶颈等，增大内存和更换快速的CPU性能也不会有明显改善的。

水平伸缩是指为当前系统增加额外的负载均衡的服务器时性能的改善程度，水平伸缩需要系统具备分布部署的能力。也就是说系统需要一些特殊的涉及。当一个系统部署在多台服务器上时，事务通常都会称为需要关注的问题。

可拓展性

这里的可拓展性是指系统级别或说软件架构级别的可拓展性。而非语言级别的程序拓展能力。一般来说，可拓展性包括三个方面:

资源可拓展性、应用可拓展性技术升级可拓展性三个方面。

资源指软件系统对增加或改变资源的支持能力。资源包括硬件（服务器、内存、硬盘、CPU）、软件资源（操作系统、应用服务器、驱动程序等）

应用是指，当硬件资源扩大时，应用是否能获得性能提升的能力，这个能力与软件架构相关，例如，一个应用只能支持一个数据库服务器，其应用拓展能力受限时，无法通过增加数据库服务器来改进性能。

技术升级拓展能力，随着某项技术的升级，系统性能能否随之提升的能力。

四、可移植性

指开发的软件可以在另一台机器上运行的能力。

如何采集非功能性需求？

待续。。

都是之前自己更细的，这次整理的差不多了，就跟上一篇一起更新了。