《大象 Thinking in UML》学习笔记（九）——需求获取

72 阅读 0 评论 48 点赞

我是靠谱客的博主阳光狗，最近开发中收集的这篇文章主要介绍《大象 Thinking in UML》学习笔记（九）——需求获取，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

一、定义边界
定义边界的目的是为我们确定一个分析的起点。
每个业务目标都会有一个边界存在，每个边界的划分则指明了需求分析的起点。

二、发现主角
不是所有的涉众都会成为业务主角，只有那些直接与系统交互的涉众才能被称为业务主角。一个涉众可以衍生出多个主角。
涉众虽然是系统的利益相关者，但却未必直接与系统交互，他可以找到替代他行使利益的另一个角色。
业务主角总是在边界之外，只有边界之外的事物才有权利向由边界代表的系统提出要求。
业务主角可能带代表了多个涉众利益，对系统也有着许多要求，但是对于一个特定的边界来说，由于边界代表了某个业务目标，那些与业务目标无关的要求也不应当在该边界中体现出来。
业务主角，之所以加上业务二字，是因为业务主角确实区别于系统参与者，它有可能不会转化成一个系统参与者，但能够映射到现实业务中的工作岗位设置、工作职能说明。

三、获取业务用例
获取业务用例的方法有很多，可以从岗位手册、业务流程指南、职务说明等一些文件中获得，也可以从涉众分析中获得灵感。
除此之外，还一种方法就是业务主角访谈，可以通过以下问题引导业务主角代表说出他们的业务需求：
您对系统有什么期望
您打算在这个系统里做些什么事情？
您做这件事的目的是什么？
您做完这件事希望有一个什么样的结果？

业务用例找到了后，还应当用适当的视图把它们展现出来。
业务用例获取到已经把客户的业务弄清楚了就可以考虑结束了，不必等到事无巨细每件事都定义清楚。可以采用迭代式开发。

四、业务建模
业务用例场景用来描述该业务的实际过程中是如何做的，主要用到了活动图、时序图、协作图。
活动图侧重于描述参与业务的各个参与者在该业务当中所执行的活动。这种图适合于分析参与者的职责，并且有利于将业务用例分解成为更小的单元，为获得概念用例乃至系统用例带来好处。

时序图用于描述对象之间按一定的顺序互通消息而完成一个特定的目标。

活动图和时序图的差别：
活动图强调职责，时序图强调顺序；
活动图中活动是主要的内容，表达的内容是业务主角或业务工人做什么；时序图中，消息是主要的内容，表达的内容是业务主角或业务工人之间传递的是什么。

协作图本质上与时序图是可以互换的，只是表达不同的视角。

五、领域模型
领域是我们分析问题时将整体分解以后的相对独立的部分。
实际工作中，并不需要把问题完全分解成领域，也不需要为每个领域都建模，而只挑选那些对业务来说重要的、对过程来说核心的或者对系统来说复杂和困难的哪些部分来建模。

提出领域问题
了解关心该领域的所有可能的涉众是如何理解和要求该领域的。问题来源于业务核心、重点、难点，也可能来源于特殊的应用环境或客户特殊的要求，

分析领域问题
根据提出的领域问题提出假设，再获取解决方案。

建立领域模型
绘制出领域模型静态图，绘制出领域对象、领域对象之间的关系以及领域对象与业务对象之间的关系。

验证领域模型
验证领域模型的正确性以及业务用例如何使用这些领域模型。

领域模型和用例分析方法
用例分析方法可以说明一个系统的功能性需求，但是对于一个关联性的问题，因为用例本身是独立的，无法表达涉及跨越多个用例的问题。此时用领域模型可以很好解决这个问题。
用例分析方法只能够分析功能性需求，对于非功能性需求只能用领域模型来分析。

问题领域的原则
1.简单需求无需建立领域模型；
2.只针对核心业务建立；
3.针对难点建立；
4.关注非功能性需求。

领域模型与用例模型
在针对功能性需求时候，领域模型是对用例模型的抽象、优化和扩展。

六、提炼业务规则
业务规则是用来指导人们怎么做系统。

全局规则
全局规则是指那些对于系统大部分业务或系统设计都起约束作用的规则，主要用来限制功能性需求。

交互规则
交互规则产生于用例场景当中，活动转移、状态变迁和对象交互时必然会有的一些限制性条件。

内禀规则
内禀规则是指那些业务对象本身具备的，并且不因为外部的交互而变化的规则。

七、非功能性需求
可靠性
可靠性包括安全性、事务性和稳定性三个方面

可用性
可用性用来衡量人们使用一个软件产品的满意程度

有效性
有效性包括性能、可伸缩性、可扩展性三个方面。

可移植性