第二章需求过程与分析的核心理论架构设计过程分为两个阶段：高层设计阶段和详细设计阶段。
高层设计阶段的重点是软件系统的体系结构设计。
详细设计阶段的重点是用户界面设计、数据库设计和模块设计。
而高层设计的信息，主要来自于需求分析。
第一节需求过程在软件架构中的重要作用作为一个架构师，工作的主要舞台是系统设计，但设计的输入来自于需求工程，什么样的需求思想，就有什么样的架构思维。
这就是说，合理而且正确的需求分析过程，是架构设计过程的一个有机的组成部分，所以，我们首先必须讨论需求分析的领域建模的有关问题。
需求开发与需求管理是相辅相成的两类活动，它们共同构成完整的需求工程。
需求工程结构图如下所示：需求开发和需求管理的流程下所示。
其中，需求变更控制是指依据“变更申请－审批－更改－重新确认”的流程处理需求的变更，确保需求的变更不会失去控制而导致项目发生混乱。
需求的类型：作为一个检查表，需求可以按照FURPS+模型进行分类的，每个字母含义如下：F：功能性（Functional）：特性、能力、安全性。
U：可用性（Usability）：人性化因素，帮助，文档。
R：可靠性（Reliability）：故障周期，可恢复性，可预测性。
P：性能（Performance）：响应时间，吞吐量，准确性，有效性，资源利用率。
S：可支持性（Supportability）：适应性，可维护性，国际化，可配置性。
+：辅助和次要的因素，比如：实现（Implentation）：资源限制，语言和工具，硬件等。
接口（Interface）：与外部系统接口所加的约束。
操作（Operations）：系统操作环境中的管理。
包装（Packaging）：授权（Legal）：许可证或其它方式。
事实上，FURPS+模型并不是唯一的，但用它来作为需求范围检查表是很有效的，这可以降低考虑系统的时候遗漏某些因素的风险。
还有一些分类方式和FURPS+模型类似，比如ISO9126，它主要来自于美国软件工程研究所(SEI)。
第二节面向过程的需求分析核心知识传统的面向过程需求分析与面向对象分析是不同的，传统方法把系统看成一个过程的集合体，由人和机器共同完成一个任务，计算机与数据交互、读出数据、进行处理又把结果写回到计算机里面去。
在讨论事件的时候，过程方法强调组件的过程模型。
而对象方法把系统看成一个相互影响的对象集，对象重要的是具有行为（方法），行为发送消息请求另一个对象做事情，就本质而言，对象方法不包括计算机过程和数据文件，而是对象执行活动并记录下数据，当为系统响应建模的时候，对象方法包括响应模型、模型行为以及对象的交互。
两种方式的不同点如下图：下面我们先简单讨论一下面向过程分析的特点，一般来说，面向过程的分析必将导致面向过程的架构（设计）。
一、数据流程图DFD1，DFD的符号面向过程的核心理念是数据流，所以它的模型主要是数据流程图（DFD），它只用了5个符号。
概念：外部实体：在系统边界之外的个人和组织，它提供数据，或者接受数据输出。
过程：在DFD中的一个符号，它代表数据输入转换到数据输出的算法或者程序。
数据流：在DFD中的箭头，它表示在过程、数据存储和外部实体间的数据移动。
数据存储：保存数据的地方，将来一个或者多个过程来访问这些数据。
2，关联图系统内部在单个过程符号中概括所有处理活动的DFD。
下面是客户支持系统的关联图简单例子：注意，箭头表示数据的流向。
二、事件划分的系统模型（0层图）DFD的细节称作片段，片段的组合有多种方式，现代过程分析也是以事件为基础，所以完全集可以组合到一个事件划分系统模型或者称为0层图中去。
其中，每个过程为一个事件的处理。
三、分解过程如果一个DFD片断包括更多的处理，可以把过程进行分解，以便作更详细的研究。
四、评估DFD的质量高质量的DFD是可读的、内部一致的以及能准确表示系统需求的。
复杂性最小化：人们对复杂信息处理是有局限性的，当太多的信息同时出现的时候，人们把这种现象称作信息超量。
在这样的情况下，可以把信息划分为小的相对独立的子集，这样便于单独考察和理解信息，这也是建模最根本的目的。
7±2原则：这个原则也称之为Mille数，由心理学研究，一个人可同时记住或操纵的信息块的数目大约在7到9之间，也就是一个模型的过程数不要超过7±2个。
另外数据流进、流出一个过程、数据存储或者数据元素的个数不要超过7±2个。
这不是强制原则，但可以给我们提供一个警告。
接口最小化：这里的接口是指一个问题或者描述中的一部分与其它部分的连接。
源于7±2原则，连接数应该保持最小，如果超出了这个原则，可把一个过程分解为更多的过程，以使得分析简单。
数据流一致性：通过分析数据流的不一致，可以找到错误。
下面的例子使用了过程描述（面向过程英语）来描述内部过程，流入的B、C没有任何处理，也没有流出，被称之为“黑洞”。
下面的例子，流出的B、Y和内部的X并没有流入，被称之为“奇迹”。
面向过程的分析已经有了一套完整而且成熟的方法，像决策表和决策树等等，这里就不再讨论了。
五、案例：订单处理子系统1、问题陈述：1，功能分解图功能分解显示了一个系统自顶向下的分解结构，也为我们绘制数据流图（DFD）的提纲。
2，过程事件图现在我们的眼睛盯住具体的细节，为每个事件过程绘制一个事件图，这实际上是一个事件的上下文流图。
在研究事件图的时候，往往需要了街所有的数据存储。
必要的时候，数据库分析和设计可以提到前面先来完成，我们将在后面的章节来讨论这个问题。
要说明的是分析的时候并不需要数据库的详细设计，而只是把数据存储用实体的方式从大的方面规范清楚，以此作为详细设计的一个必要的输入。
大多数事件图包括一个单一过程，并且需要说明以下内容：1）输入及输入来源，来源被描述为外部代理。
2）输出及输出目的地，目的地被描述为外部代理。
3）必须读取记录的任何数据存储都应该被加入到事件图中，事件流应该加入命名。
4）对数据的任何增、删、改、查都应该加入到事件流中，事件流应该加入命名。
事件图的敏感性和简单性，使它成为专家和用户沟通的强有力的工具，下面是一个简单的外部事件图。
一个简化的“订单处理子系统”的过程事件图如下。
3，系统DFD图事件图并不是孤立存在的，它们集合在一起定义了系统和子系统，所以，构造一个或者多个系统或者子系统中所有事件相互关系的系统图也是有意义的。
在绘制系统图的时候，必须平衡不同详细程度的事件图，以保证一致性和完整性，必要的时候可以扩展为多个DFD。
系统图更多的是从宏观的角度看为题，更多的考虑相互关系，这点很重要。
4，基本图系统图中的某些重要的事件过程可以扩展为一个基本的数据流图，以揭示更多的细节，这对比较复杂的业务过程（比如订单处理特别重要），有些事件比较简单（比如报告生成），所以不需要进一步扩展。
5，完整的规格说明上下文图、系统图、事件图和基本图的组合构成了过程模型，一个工艺良好的完整过程模型可以在最终用户和计算机软件设计者以及程序人员之间有效的沟通需求，消除大部分系统设计、编程和实施阶段出现的混淆。
注意，完整的过程模型并不仅仅是这些图，更多的是文字说明，把图形和文字结合起来，设计就会非常的清晰而且避免歧义，这非常重要。
第三节面向对象的需求分析和用例在面向对象的需求分析中，对象、事件和响应成为分析的主体，分析的着力点转向了交互。
但是，还是有相应的方法来描述功能，这就是用例，这也是需求分析的重要部分。
一、用例及用例图的基本概念用户一定会有自己的目标，并且希望计算机能够帮助他们实现这些目标。
用例就是表达如何使用系统达到目标的一组情节。
用例的几个概念参与者（actor）：具有行为能力的事务，可以是个人（由其扮演的角色来识别），计算机系统，或者组织。
场景（scenario）：是参与者和被讨论系统之间一系列特定的活动和交互，通常被称之为“用例的实例”。
通俗地讲，场景实际上是在说故事。
一般来说，一个用例就是描述参与者使用系统达成目标的时候一组相关的成功场景和失败场景的集合。
用例分析的关键是专注于“怎样才能使系统为用户提供可观测的数据，或帮助用户实现它们的目标”，而不是仅仅把系统需求用特性和功能的细目罗列出来。
在需求分析中，我们必须专注于考虑系统怎么才能增加价值和实现目标。
用例的主要思想是：为功能需求写出用例（而不是老式的为“系统会怎么做”的功能列表），在统一过程中用例是发现和定义需求的主要方法，是功能性行为。
参与者的发现:发现参与者对提供用例是非常有用的。
因为面对一个大系统,要列出用例清单常常是十分困难。
这时可先列出参与者清单,再对每个参与者列出它的用例,问题就会变得容易很多。
二、用例（UseCase）及其定义1）用例：1．用例是关于单个活动者在与系统对话中所执行的处理行为的陈述序列（Jacobson）。
它表达了系统的功能和所提供的服务，用例的图示如下。
2．它描述了活动者给系统特定的刺激时系统的活动，是活动者通过系统完成一个过程时出现的一组事件，最终以实现一种功能。
3．通常，用例侧重于功能，但不重点描述该功能的实现细节。
4．所有的用例必须始于参与者（Actor），而且有些用例也结束于参与者。
2）用例的分类1．业务用例（Business Use Case）指系统提供的业务功能与参与者的交互，表现问题领域中各实体间的联系和业务往来活动（如果某个用例的范围包含了人以及由人组成的团队、部门、组织的活动，那么这个用例必然是业务用例）。
2，系统用例（System Use Case）指参与者与系统的交互，它表现了系统的功能需求和动态行为（如果仅仅是一些软件、硬件、机电设备或由它们组成的系统，并不涉及到人的业务活动，那么该用例是系统用例）。
3）用例的联系（横向方面）1．泛化关联泛化关联代表一般与特殊的关系，它充分体现了面向对象的继承性：子类具有父类的所有属性，还可以拥有自己的属性特点及行为。
泛化关联包括用例之间及活动着之间的关联关系。
例如，修改员工资料和修改开发部员工资料就是用例的泛化关联。
泛化关联用空心三角箭头的实线表示：其方向从特殊指向一般。
2，包含关联（include）包含关联指一个基本用例的行为包含了另一个用例的行为，这种关联是一种依赖关系，被包含的用例不能独立存在，只能作为包含它的用例的一部分。
例如，一个信息维护的模块，无论是录入人员信息还是修改人员信息，都必须对当前登录者进行验证，因而录入及修改人员信息这/两个用例都用到了对当前用户的权限验证的用例。
其表示方法为用一条虚箭线从基本用例指向被包含的用例，并标有构造型<<include>>：3，扩展关联（extend）扩展关联的基本含义与泛化关联类似，但是对于扩展用例有更多的规则，即基本的用例必须声明若干新的规则---扩展点（Extension Points），扩展用例只能在这些扩展点上增加新的行为并且基本用例不需要了解扩展用例的如何细节。
