我们怎么做需求分析 笔记3

1,如图是一个子用例使用的例子。图中，用例“调整前信息查询”、“调整后信息查询”、“调整前时间段查询”、“调整后时间段查询”都用到了“按单位汇总考核结果”。它们是一种使用关系或者包含关系，因此被绘制成一条虚线，从使用者指向被使用者，并标注为use或include。

另外，在用例中还存在许多扩展流和异常流。当系统在运行到基本流程中某个步骤时，由于满足了某个分支条件或异常条件，这时系统就从基本流程流转到了扩展流或异常流中。扩展流和异常流其实不那么泾渭分明。在业务逻辑上扩展流依然是一种正常的操作，仅仅只是正常操作的另一个操作，而异常流其本身就是有什么东西不对劲了，需要进行一些异常处理，比如用户密码输错了、用户忘带身份证了，等等。扩展流和异常流最终都可能回到基本流程中，也可能不能回来，而从另一个结束点结束。

与子用例相似，扩展流和异常流中的流程如果相对独立、可以为其它流程所共享，则可以提取出来，形成一个单独的用例，叫扩展用例。如果扩展用例是直接从基本流程中某个环节扩展出来，则该环节被成为扩展点，进入扩展用例的条件叫扩展条件。在用例图中，扩展关系被绘制成一根虚线，从扩展用例指向被扩展的用例，并标注为extend。
2,用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。但是，正如任何事物都有两面性，用例图也不例外，也有自己不利的一面。在我看来，这集中体现在两个方面：只见树木不见森林、不生动形象。
3,什么叫“只见树木不见森林”呢？就是说，用例说明中对业务流程的描述，过早地将系统的整体流程，分散到了各个用例中了，丢失了对业务流程的整体描述。不生动形象，则是说用例说明中对流程的描述都是用枯燥无味的文字来表述的，缺乏生动形象的图形表示。针对这些不足，UML的另外两种视图，可以有效地弥补用例图的缺陷。它们就是行动图与状态图。
4,行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。在行动图中，往往是从一个实心圆的起始节点开始的。最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。活动节点可以表述为一个活动短语（如下订单），可以表述为一个表达式（如len=a.length+x），还可以表述为一个消息（如send(msg)）。同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序
5,本的活动图还不能完整的反映我们的业务流程，因此我们还需要在基本活动图的基础上增加元素。现在我们来看看泳道与业务对象流。
6,每个泳道代表一个参与者的业务操作，而整个图形表述了多个参与者间的协作过程
7,除了活动图，我们似乎对需求的描述还缺少点儿什么，那就是对关键对象中流程中状态变化的描述，在这种情况下，我们的状态图就上场了。
8,业务领域分析，就是对需求分析中涉及到的业务实体，以及它们相互之间关联关系的分析。前面我们谈到了功能角色分析，或者说用例分析，它是从整体的角度对整个系统人机交互的分析与整理。随后我们谈到了业务流程分析，它是在对系统人机交互的分析与整理的基础上，更加细致的去分析和整理那些业务流程，以及组成这些流程的一个个业务操作。业务流程分析是对系统进行的一种动态的分析，分析的是那些行为，那些操作。但是，所有的行为，所有的操作，最终施与的对象都是那些实体。这句话怎么理解呢？比如，我们执行填写操作，施与的对象必然是那些表单，最终产生的结果必然是形成一份完整的表单，表单就是那个行为施与的对象。再比如，我们执行查询操作，施与的对象必然是一个报表，最终产生的结果必然是查看到了这个报表的结果。这里的表单、报表，都是存在于系统的静态实体，它们中的大多数也最终以数据结构的形式持久化保存于系统的数据库中。因此，系统中应当有哪些实体，这些实体都有哪些属性，被赋予了哪些行为，它们之间的相互关系是怎样的，就成为了业务领域分析的重要内容，而业务领域分析也就成为了对系统进行的一种静态分析。
9,通过从用例中分析.领域模型中的实体，往往就在我们通过原文分析提取出来的这些名词中,系统之内的事物转化到领域模型中，可能会变成两种东西：实体与实体中的属性。什么变成实体而什么变成实体中的属性呢？自身有自己的属性，可以成为系统中行为的执行者或施与者的，才是实体.对用例说明中的动词分析，是为了定义各个实体之间的各种行为。同样，并不是所有动词都是实体的行为。参与者的行为显然不是实体的行为，应该被排除掉
10,最初的粗浅认识，深入到后来对四种情况的认识，正是体现了DDD的另一个思想：持续学习。需求人员在开始一个新的管理系统的分析工作时，都有可能面临着一个全新的业务领域
11,领域模型中，我们按照客户的思路，运用客户的术语，去绘制一个一个的对象，按照他们的思路去描绘对象间的关系，描绘对象间的操作，他们真的就会看不明白吗
12,那么哪些是非功能需求呢？我们可以简单归纳为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。而这5部分我们可以进一步细化。
13,需求分析是一个撒大网的过程，而不是姜太公钓鱼的过程。功能需求固然重要，非功能需求同样重要。我们在进行非功能需求的分析时，除了制订整体的原则以外，还要落实到各个具体的功能中，将这些功能所潜在的、特殊的非功能需求挖掘出来，提前进行分析设计，对于可行性不高的应及时与客户商讨，才能有效地避免日后存在的这些方面的风险
14,需求列表，又称之为需求跟踪表，是最原始的、用户对业务需求的描述。它不掺杂任何需求分析人员对业务需求的分析与设计，而是以简短扼要的语句，以业务人员的口吻表述的，今后要开发的这个系统应当提供给他们的各项功能。
15,需求列表不掺杂我们对业务需求的任何分析与设计，这是需求列表的核心，也是它存在的意义。从用例模型到领域模型我们不难发现，它是一个分析与设计的过程。需求分析员对业务需求进行捕获、认识、理解以后，需要结合软件专业知识进行分析设计，还要听取系统架构师和设计师对需求可行性的分析，最后才整理和编写出用例模型。在这样一个过程中，随着业务需求复杂度的提高，以及各种技术分析的掺杂，最终的结果很有可能偏离原有的业务需求。这种偏离常常表现为对业务需求正确性与完整性的偏离，即需求已经变味儿了，或者某些需求项目缺失。需求列表就是那个最开初的、最完整的、正确的业务需求。用这样一个列表来开始我们的分析，最后用它来验证我们的设计，使之成为我们的分析设计之旅树立的一个正确的航标。有了这样一个航标，就可以使我们最终能够到达一个正确的彼岸。
16,原型开发的快速与模拟到什么程度，是一对矛盾，我们要去把握。要快速开发，必然不可能和最终交付的软件系统一模一样，许多复杂问题被简化，非关键性流程被忽略，这就是所谓的模拟。因此，模拟到什么程度是关键，既能说明问题，又不耽误时间。根据我的经验，一般能拿出界面，并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能
17,快速原型法是美妙的，它给你与用户带来了从未有过的体验。但美妙的同时，也会带来一些的尴尬，不必要的误会，我们一定要注意。最常见的误会就是让用户将原型误以为最终交付的系统。开发一个系统需要持续数月，但你倒好，几天就搞定了，为什么还要在这个系统上投入大量资金呢？如果对方领导开始有这样的想法时，双方就开发费用进行的谈判就有一些不妙了。所以在给用户看到原型前，一定要跟用户解释清楚。

既然是原型，必要的校验、非正常操作的处理通通都被忽略。因此，当演示原型出错时，用户你可千万不要较真哟！这丑话可得说在前头，否则用户跟你较起真来，你在用户心目中的形象可就要大打折扣了
18,需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。但是，我认为，用户需求规格说明书与产品需求规格说明书的差别并不大。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言（一种混合语言），来表达大家都清楚明白的概念。从这个角度将，需求规格说明书就应当是一个，不区分用户需求规格说明书和产品需求规格说明书。
19,需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。从理论上说，需求评审会应当由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理，还有公司相关领导参加。但实际上，让如此多不同角色的人聚集在一起开会是不现实的。因此，我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实