A002-181-2162-张小龙

摘要：

软件需求的获取和分析是软件系统开发中的一项重要任务，正确获取软件需求是软件技术人员必须掌握的基本技能。本课程从软件需求工程的角度出发，以需求开发过程为主线，完整描述了需求获取、需求分析、需求验证、需求规格说明和需求管理等需求工程活动。本书站在开发者的立场，侧重于实践者的技术与方法，系统全面地介绍了软件需求工程的各项进展，努力促进需求工程领域理论、方法和技术的全面融合应用，以指导需求工程各阶段的系统化实践。

一、需求分析认识

1.1需求分析到底做什么？

需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。此外，软件的一些非功能性需求(如软件性能、可靠性、响应时间、可扩展性等)，软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。为了促进软件研发工作的规范化、科学化，软件领域提出了许多软件开发与说明的方法，如结构化方法、原型化法、面向对象方法等。这些方法有的很相似。在实际需求分析工作中．每一种需求分析方法部有独特的思路和表示法，基本都适用下面的需求分析的基本原则：(1)侧重表达理解问题的数据域和功能域。对新系统程序处理的数据，其数据域包括数据流、数据内容和数据结构。而功能域则反映它们关系的控制处理信息。(2)需求问题应分解细化，建立问题层次结构。可将复杂问题按具体功能、性能等分解并逐层细化、逐一分析。(3)建立分析模型。模型包括各种图表，是对研究对象特征的一种重要表达形式。通过逻辑视图可给出目标功能和信息处理间关系，而非实现细节。由系统运行及处理环境确定物理视图，通过它确定处理功能和数据结构的实际表现形式。

需求分析概念图（来自百度）

1.3需求分析的内容

需求分析的内容是针对待开发软件提供完整、清晰、具体的要求，确定软件必须实现哪些任务。具体分为功能性需求、非功能性需求与设计约束三个方面：1．功能性需求，功能性需求即软件必须完成哪些事，必须实现哪些功能，以及为了向其用户提供有用的功能所需执行的动作。功能性需求是软件需求的主体。开发人员需要亲自与用户进行交流，核实用户需求，从软件帮助用户完成事务的角度上充分描述外部行为，形成软件需求规格说明书。2．非功能性需求，作为对功能性需求的补充，软件需求分析的内容中还应该包括一些非功能需求。主要包括软件使用时对性能方面的要求、运行环境要求。软件设计必须遵循的相关标准、规范、用户界面设计的具体细节、未来可能的扩充方案等。3．设计约束，一般也称做设计限制条件，通常是对一些设计或实现方案的约束说明。例如，要求待开发软件必须使用Oracle数据库系统完成数据管理功能，运行时必须基于Linux环境等。

1.4需求分析阶段的工作

需求分析阶段的工作，可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。

1.5软件需求的分析与设计方法

目前，软件需求的分析与设计方法较多，一些大同小异，而有的则基本思路相差很大。从开发过程及特点出发，软件开发一般采用软件生存周期的开发方法，有时采用开发原型以帮助了解用户需求。在软件分析与设计时，自上而下由全局出发全面规划分析，然后逐步设计实现。从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。(1)功能分解方法。将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。(2)结构化分析方法。结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。(3)信息建模方法。它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。(4)面向对象的分析力法。面向对象的分析方法的关键是识别问题域内的对象，分析它们之间的关系，并建立三类模型，即对象模型、动态模型和功能模型。面向对象主要考虑类或对象、结构与连接、继承和封装、消息通信，只表示面向对象的分析中几项最重要特征。类的对象是对问题域中事物的完整映射，包括事物的数据特征(即属性)和行为特征(即服务)。

1.6需求分析的特点及难点

主要体现在以下几个方面：(1)确定问题难。主要原因：一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。(2)需求时常变化。软件的需求在整个软件生存周期，常会随着时间和业务而有所变化。有的用户需求经常变化，一些企业可能正处在体制改革与企业重组的变动期和成长期，其企业需求不成熟、不稳定和不规范，致使需求具有动态性。(3)交流难以达到共识。需求分析涉及的人事物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难。(4)获取的需求难以达到完备与一致。由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。(5)需求难以进行深入的分析与完善。需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。

二、图类关键字

2.1实体关系图E-R图（Entity Relationship Diagram）

2.1.1 什么是E-R图
E-R图即实体-联系图(Entity Relationship Diagram)，是指提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。E-R方法:是“实体-联系方法”（Entity-Relationship Approach）的简称。它是描述现实世界概念结构模型的有效方法。

（图2.2.1高校人事管理系统的ER图）

实体联系模型，实体关系模型或实体联系模式图(ERD)是由美籍华裔计算机科学家陈品山(Peter Chen)发明，是概念数据模型的高层描述所使用的数据模型或模式图，它为表述这种实体联系模式图形式的数据模型提供了图形符号。这种数据模型典型的用在信息系统设计的第一阶段；比如它们在需求分析阶段用来描述信息需求和/或要存储在数据库中的信息的类型。但是数据建模技术可以用来描述特定论域(就是感兴趣的区域)的任何本体(就是对使用的术语和它们的联系的概述和分类)。在基于数据库的信息系统设计的情况下，在后面的阶段(通常叫做逻辑设计)，概念模型要映射到逻辑模型如关系模型上；它依次要在物理设计期间映射到物理模型上。注意，有时这两个阶段被一起称为“物理设计”。

2.1.2 E-R图的基本要素
通常，使用实体-联系图(entity-relationship diagram)来建立数据模型。可以把实体-联系图简称为ER图，相应地可把用ER图描绘的数据模型称为ER模型。ER图中包含了实体(即数据对象)、关系和属性等3种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体(或关系)的属性，并用直线把实体(或关系)与其属性连接起来。例如，上图2.1.2是我们高校人事管理系统的ER图。
人们通常就是用实体、联系和属性这3个概念来理解现实问题的，因此，ER模型比较接近人的习惯思维方式。此外，ER模型使用简单的图形符号表达系统分析员对问题域的理解，不熟悉计算机技术的用户也能理解它，因此，ER模型可以作为用户与分析员之间有效的交流工具。
实体型(Entity)：具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体;在E-R图中用矩形表示，矩形框内写明实体名；比如学生张三丰、学生李寻欢都是实体。如果是弱实体的话，在矩形外面再套实线矩形。
属性(Attribute)：实体所具有的某一特性，一个实体可由若干个属性来刻画。在E-R图中用椭圆形表示，并用无向边将其与相应的实体连接起来；比如学生的姓名、学号、性别、都是属性。如果是多值属性的话，再椭圆形外面再套实线椭圆。如果是派生属性则用虚线椭圆表示。
联系(Relationship)： 数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下 3 种类型：
(1) 一对一联系 (1 ∶ 1)
(2) 一对多联系 (1 ∶ N)
例如，本高校系统中的领导与教师之间存在一对多的联系“管理”，即每位领导可以管理多个教师，但是每个教师只能由一位领导来管理。
(3) 多对多联系 (M ∶ N)

2.2活动图(Simple State Machine)

1、简单状态机模式从实体显示的重要状态的角度描述了一个实体（例如块、参与者、用例或测试用例）。当进入一个状态时，一个进入动作可以被触发，而在这个状态下一个do动作可以被触发，离开状态时可以触发一个退出动作。
2、提供一种机制来表示系统工程师或其他涉众认为在块或其他元素的生命周期中很重要的条件（状态）。它描述了状态相关的行为，显示了元素如何从一个状态转换到另一个状态，以及在元素处于该状态期间调用了哪些活动。
3、首先开始注册事件，教师进行注册账号，系统判断是否有该账号，如果已被注册了，就提示该账号不可用，返回重新注册首页；如果账号没有被注册过，就由管理员进行审核，如果通过审核，就注册成功，流程结束；否侧注册失败，返回注册首页。

2.3用例图(Basic Use Case Model)

1、基本用例模型模式创建元素和用例图，描述用户角色希望从系统中实现的目标。用例都包含在系统边界内，参与者都在边界之外。
2、上图显示了一个用例图，其中包含参与者和系统边界中包含的多个用例。一个参与者表示一个系统，并使用矩形表示法。
3、该图目的是允许业务分析师和其他涉众描述参与者（用户扮演的角色）在与系统交互时想要实现的价值。
4、该模式通常用于计划的分析阶段，可用于实现任意数量的需求，并作为为实现团队提供规范的一种方式。
5、我们的高校人事管理系统主要有三个角色，管理员可以审核反馈信息、工资管理、审核请假申请、用户管理、职位管理；教师和工勤人员可以查看基本信息、查看工资和提交反馈信息。

2.4四方块图(Block with Four Parts)

表示块各部分之间的互连与连接。

2.5需求图(One Level Requirement Hierarchy)

1、一级需求层次结构模式允许在层次结构中可视化需求，允许将复杂的需求分解为更细粒度的需求，直至单个级别。
2、当需求描述一个完整的系统时，它通常是在系统描述的早期创建的；但是它可以在任何时候创建，特别是当需求描述一个子系统或系统的一部分时。
3、高校人事管理系统主要的系统需求有服务需求、性能需求、工资管理、请假管理、用户管理、职位管理。

2.6 约束块参数图(Constraint Block Parametrics Diagram)

1、约束块参数化图模式创建元素和一个图，表示在边界约束块上下文中三个约束块的用法。约束属性的参数相互绑定，然后绑定到边界约束块的参数，有效地描述方程组。
2、该模式的目的是允许系统工程师创建可用于约束块或约束块特性的方程组。
3、当控制或约束行为的约束和方程已确定时，通常在分析阶段使用该模式。用法包括：
·它们可以用作模拟的前光标，用于可视化方程和执行详细分析。
·它们可以作为权衡研究的基础。
·它们可以作为记录系统方程的形式化方法，以及它们在边界约束块的上下文中如何相互关联。

2.7 组织结构图(Organization Chart)

1、这是组织结构图，OrganizationChart模式创建元素和图表，为组织的角色、职责和报告线建模。各种各样的线条样式和颜色被用来帮助布局和吸引人的图表。
2、系统角色包括了普通用户、管理员和超级管理员。
3、普通用户有教师、后勤人员等。普通用户可以登录系统查看信息，进行反馈等。
4、管理员有领导和辅导员。管理员可以管理该系统的用户以及资源信息等。
5、超级管理员为系统管理员。权限最大，可以创建管理员，维护该系统等。

2.8 车道流程图(Business Process Diagram with Lanes)

1、车道的目的是组织和分类流动对象，通常用于指示谁执行或负责车道中包含的活动。这些通道可用于其他目的，例如指示正在执行活动的位置或谁管理一组活动。
2、模式可以在计划的任何时候使用，但通常在绘制基线（当前状态）过程或定义目标（未来状态）过程的早期使用。对于一个组织来说，在一个企业或业务单元级别开始详细描述所有基线（当前状态）过程是非常常见的，这样这些过程是可用的，并且可以被多个项目重用。
3、首先开始注册事件，教师进行注册账号，系统判断是否有该账号，如果已被注册了，就提示该账号不可用，返回重新注册，该流程2结束；如果账号没有被注册过，就由管理员进行审核，如果通过审核，就注册成功，流程结束；否侧注册失败，可以重新尝试注册。

2.9业务流程图(Basic Business Process)

1、基本业务流程模式使用埃里克森-彭克语言创建元素和图表来表示业务流程和交互。
该语言提供了一种对业务流程建模的内聚方式，它允许建模者在一个综合的、有表现力的图中表示目标、触发流程的事件以及流程的输入和输出。
2、该模式的目的是允许业务分析师、架构师和其他涉众创建和查看一个简单但富于表现力的图表，该图表在一个视图中捕获流程的所有方面。
3、该模式可在计划期间的任何时间使用，但通常在分析期间用于描述基线(当前)和目标(未来)流程。

2.10模型图(Domain Model)

1、领域模型模式在一个类图上创建类，该类图描述了正在讨论的领域中的重要概念或“事物”。 类可以命名，也有详细的注释。
连接器被用来描述元素之间的关系，就像动词在自然语言中被用来描述名词如何相互作用一样。
2、其目的是为一个领域中的重要概念创建一个模型，该模型可用作一种通信设备，以确保所有利益相关者对概念有一个共同且一致的理解。
3、领域模型通常是在一个计划中创建的第一批模型之一，它构成了开发存储库其他部分的基础。 它可以像字典一样被用作交流工具。

2.11交互图(Interaction diagram)

交互图是用来描述模型中不同元素之间的某种类型的交互的。这种相互作用是系统动态行为的一部分。这种交互行为在统一建模语言中由两个图表示，即序列图和协作图。这两个图的基本目的是相似的。序列图强调消息的时间顺序，协作图强调发送和接收消息的对象的结构组织。
在我们的高校人事管理系统中，教职工教师扮演Actor，在交互图中是这个图的主要推动者，也是在系统进行交互最多的角色，他通过打卡请教等等功能来实现对自己个人信息考评的间接控制，最终影响整个高校人事管理系统。

2.12构件图(Component diagram)

构件图是用来反映代码的物理结构。从组件图中，可以了解各软件组件（如源代码文件或动态链接库）之间的编译器和运行时依赖关系。使用组件图可以将系统划分为内聚组件并显示代码自身的结构。

高校人事管理系统 构件图分析：
在人事管理系统中，构件主要有两个，一个是用户登录子系统，用户进行注册、登录等等操作的组件；一个是用户功能子系统，用户进行打卡、注册、修改个人信息的组件。

2.13 交互概览图(Interaction Overview Diagram)

交互概述图是活动图的一种形式，其中节点表示交互图。交互图可以包括顺序图，通信图，交互图和时序图。交互概述图的大多数表示法与活动图相同。例如，初始，最终，决策，合并，派生和联接节点都相同。但是，交互概述图引入了两个新元素：交互发生和交互元素。
Interaction Occurrence（交互发生）：
交互事件是对现有交互图的引用。交互事件显示为参考框架；也就是说，在左上角带有“ ref”的框架。所引用的图的名称显示在框架的中央。

Interaction Element交互元素：
交互元素类似于交互事件，因为它们显示矩形框架内现有交互图的表示。它们的不同之处在于它们以内联方式显示参考图的内容。

Putting it all Together（全部放在一起）：
活动图上所有相同的控件（分支，联接，合并等）都可以用于交互概览图上，从而将控制逻辑置于较低级别的图上。以下示例描述了一个示例销售过程，其中子过程在交互事件中被抽象化。

三、第二类关键字

3.1软件架构设计(Software architecture design)

软件体系结构通常是指软件系统的更大结构，它涉及多个软件流程如何协作执行任务。软件设计是指较小的结构，它处理单个软件过程的内部设计。在本教程结束时，读者将对软件体系结构和设计概念有深入的了解，并可以为给定的软件项目选择和遵循正确的模型。
系统的体系结构描述了其主要组件，它们之间的关系（结构）以及它们之间如何交互。软件体系结构和设计包括几个促成因素，例如业务战略，质量属性，人员动态，设计和IT环境。

体系结构是系统的蓝图。它提供了一种抽象方法来管理系统复杂性，并在组件之间建立通信和协调机制。
• 它定义了一种结构化的解决方案，可以满足所有技术和运营要求，同时优化性能和安全性等通用质量属性。
• 此外，它涉及与软件开发有关的一组与组织有关的重要决策，并且这些决策中的每一个都会对最终产品的质量，可维护性，性能和整体成功产生重大影响。这些决定包括-
o 选择组成系统的结构元素及其界面。
o 在这些元素之间的协作中指定的行为。
o 将这些结构和行为元素组成大型子系统。
o 体系结构决策符合业务目标。
o 建筑风格指导组织。

软件设计提供了一个设计计划，该计划描述了系统的元素，它们如何适合以及如何共同满足系统的需求。制定设计计划的目标如下-
• 与系统需求进行谈判，并与客户，市场营销和管理人员建立期望。
• 在开发过程中充当蓝图。
• 指导实施任务，包括详细的设计，编码，集成和测试。
在详细设计，编码，集成和测试之前，在领域分析，需求分析和风险分析之后。
该体系结构的主要目标是确定影响应用程序结构的需求。布局合理的体系结构可减少与构建技术解决方案相关的业务风险，并在业务和技术要求之间架起一座桥梁。

3.2架构设计程序(Architectural design processes)

架构设计是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构设计是软件设计过程的早期阶段，它把需求分析和设计流程连接在一起。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。
所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。
在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。

3.3异动处理系统(Transaction processing)

事务处理是一种计算类型，通常由大型服务器计算机执行，支持交互式应用程序。在事务处理中，工作分为单个的，不可分割的操作，称为事务。相反，批处理是一种计算方式，其中一个或多个程序处理一系列记录（一批），而用户或操作员几乎没有采取任何行动。
我们的高校人事管理系统也将采用事务处理系统，当用户在使用系统时，出现异常操作或者突然断电等突发情况时，保护用户的数据。
常见的异常：

事务处理系统通过使应用程序免受事务管理细节的影响，使应用程序程序员可以专注于编写支持业务的代码：
1.它管理事务的并发处理。
2.它可以共享数据。
3.它确保数据的完整性。
4.它管理事务执行的优先级。
当事务开始处理时，CICS运行与该事务关联的程序。该程序可以在事务处理过程中将控制权转移到其他程序，从而可以组装由许多CICS程序组成的模块化应用程序。
在CICS系统中，任何时候，事务的许多实例都可以同时运行。正在运行的事务的单个实例称为任务。
在任务运行期间，它可以独占使用（或持有锁定）它更改的每个数据资源，从而确保事务的隔离属性。需要访问资源的其他任务必须等待，直到释放锁定。为了确保事务处理系统的整体响应能力，请设计CICS应用程序，以使它们在最短的时间内持有锁。例如，您可以将事务设计为短暂的，因为CICS在任务结束时释放锁。
• 事务的ACID属性
在事务处理的上下文中，缩写ACID指事务的四个关键属性：原子性，一致性，隔离性和持久性。
• 提交和回滚
为了确保事务的ACID属性，在事务过程中对数据所做的任何更改都必须提交或回滚。
• 工作单元
事务的一致性属性可确保数据在事务开始和结束时处于一致状态。在CICS中，由两个一致性点之间的事务执行的可恢复操作序列被称为工作单元。
• 分布式事务处理概述
这些主题描述了CICS分布式事务处理（DTP）的基本概念，以及在设计DTP应用程序时必须考虑的内容。
• 商业交易
CICS交易支持的商业交易通常涉及许多动作，这些动作有时会持续几天或几周。通过使用CICS商业交易服务（BTS），您可以控制复杂商业交易的执行。
• 恢复和重新启动
CICS连续记录有关区域状态以及该区域中每个工作单元状态的信息。重新启动区域时，将保留并使用此信息，从而使CICS能够重新启动而不会丢失数据完整性。

3.4架构设计决策(Architectural design decisions)

在大多数体系结构开发过程中，在不同的体系结构域中做出不同的决定。架构师可能会在概念体系结构中做出不同的决定，例如选择特定的组件，并遵循特定的体系结构模式。
但是，诸如开发人员，业务用户甚至其他架构师之类的利益相关者没有时间去通过不同的架构视图来理解架构的含义。例如，业务用户希望清楚地了解将要发生的更改，并确保体系结构满足其业务需求。其他领域的架构师希望对架构的关键方面有一个清晰的了解，包括架构师在构想阶段考虑的基本原理和替代方案。
作为一名架构师，您可能会面临不同的挑战或业务需求，这些挑战或业务需求可以通过不同的选项来实现，或者您需要选择特定的模式或样式。作为一种决定方式，您将必须经历一个过程并进行长时间讨论，以了解为什么需要做出这些决定并提出建议，而不是考虑其他决定。
那么，什么是架构决策？对软件体系结构的体系结构增减集，基本原理以及设计规则，设计约束和附加要求（部分实现对给定体系结构的一个或多个要求）的描述-软件体系结构作为一组Anton Jansen和Jan Bosch撰写的《建筑设计决策》论文，称为架构策略。
为什么架构决策很重要？通过交流架构变更和决策，我们可以将其视为一种思考方式，以总结我们为何需要此决策以及为什么决定进行此变更并为此选择此选项，并且还描述了此变更的影响已根据决定进行更改。这对于其他利益相关者（例如业务用户，域架构师或开发人员）很重要。结束开放的问题和漫长的讨论循环，在体系结构开发过程中，我们可能会进行大量讨论和集思广益会议，实际上，我们需要与其他利益相关者进行交流。在整个过程中，不同领域的其他利益相关者甚至新的建筑师将开始建议或讨论可能不符合所做出决定的另一种选择。在这方面，记录体系结构决策将消除该周期，并将决策的依据传达给所有利益相关者，并使其保持历史性，以了解如何也受新更改的影响。当我们知道我们为什么要执行这些决策，与这些决策相关的关注点和业务需求是什么，以及这些决策的贡献者时，它将提供一种可追溯性的方式。架构治理，决策日志和记录用于跟踪这些决策以及它们如何符合我们遵循的标准。

3.5分层式架构(Layered architecture)

SimArch是一种分层体系结构，通过从与执行环境有关的所有细节中删除开发人员，可以简化本地和分布式仿真系统的开发，该执行环境可以是常规的本地执行平台，也可以是分布式执行平台，例如基于HLA的平台。
下图为我们高校管理系统的分层架构图：

用户有领导、教师、后勤人员以及管理员。

在分层体系结构中，对象是使用构造块思路设计的。底层由执行低级，通常乏味的功能的对象组成。下一层具有较高的功能，并调用较低层中的对象。向上的每个连续层在功能上都更高。解释此分层的一种常见方式是“抽象了”细节，这意味着执行功能所需的一些繁琐细节仅通过将它们委派给较低级别的对象而对较高级别的对象隐藏了。在分层体系结构中，对象调用全部向下。这种架构是大多数高级语言（包括适用于Java等面向对象语言的应用程序编程接口（API）。

3.6 MVC(the Model-View-Controller)

在模型-视图-控制器（MVC）是分开的应用程序分为三个主要逻辑组件的体系结构图案：该模型，视图和控制器。这些组件中的每个组件都是为处理应用程序的特定开发方面而构建的。MVC是创建可伸缩和可扩展项目的最常用的行业标准Web开发框架之一。
以下是MVC的组件：

模型：
模型组件对应于用户使用的所有与数据相关的逻辑。这可以表示在View和Controller组件之间传输的数据，也可以表示任何其他与业务逻辑相关的数据。例如，客户对象将从数据库中检索客户信息，对其进行处理并将其数据更新回数据库，或使用它来呈现数据。
视图：
View组件用于应用程序的所有UI逻辑。例如，“客户”视图将包括最终用户与之交互的所有UI组件，例如文本框，下拉菜单等。
控制器：
控制器充当Model和View组件之间的接口，以处理所有业务逻辑和传入请求，使用Model组件处理数据，并与View交互以呈现最终输出。例如，客户控制器将处理客户视图中的所有交互和输入，并使用客户模型更新数据库。使用同一控制器查看客户数据。

3.7语言处理系统(Language processing system)

对于我们大多数人而言，言语表达似乎毫不费力。而且，这是一个多方面且复杂的过程，需要访问语言处理系统的不同组件。尽管单词的发音（即声道的发音运动模式）可能是终点，但该过程始于单词的概念化，从心理词典中选择其词汇表示形式和相应的声音属性以及映射这些语音表现形式进入发音计划和实施阶段。此外，说话者不仅会被动地发声，而且会持续地在瞬间进行监控，以根据听觉和体感同时适应短期或长期的输出。从产品本身收到的反馈。

尽管细节可能有所不同，但语音生产功能体系结构的当前模型通常会根据生产的不同阶段来识别语音生产的这些不同方面。这些阶段被认为在功能上是不同的并且按层次进行组织，在每个处理阶段都具有前馈和反馈机制（图55.1））。本章的目的是从神经心理学和神经生理学研究中检查语音生成过程的当前数据和模型。为此，我们首先提供从失语症文献中得出的简要历史观点，该文献已成为许多神经生理学研究的框架。然后，我们考虑概述的拟议生产阶段，首先回顾生产的语音阶段，然后是生产的语音/发音阶段，整合基于病变和神经生理学研究的结果。它们一起表明语音产生会募集一个包含语言网络的神经网络，包括时态，顶叶和额叶结构。

3.8网站服务器(Web server)

Web服务器是使用HTTP （超文本传输协议）和其他协议来响应通过万维网发出的客户端请求的软件和硬件 。Web服务器的主要工作是通过存储，处理并将网页交付给用户来显示网站内容。除了HTTP，Web服务器还支持SMTP（简单邮件传输协议）和FTP（文件传输协议），用于电子邮件，文件传输和存储。
我们的高校人事管理系统采用tomcat服务器来部署。

Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好Apache 服务器，可利用它响应HTML（标准通用标记语言下的一个应用）页面的访问请求。实际上Tomcat是Apache 服务器的扩展，但运行时它是独立运行的，所以当你运行tomcat 时，它实际上作为一个与Apache 独立的进程单独运行的。
Web服务器硬件连接到Internet，并允许与其他连接的设备交换数据，而Web服务器软件控制用户如何访问托管文件。Web服务器进程是客户端/服务器 模型的示例 。承载网站的所有计算机都必须具有Web服务器软件。
Web服务器用于Web托管或网站和基于Web的应用程序（或Web应用程序）的数据托管。
Web服务器如何工作？Web服务器软件可通过网站的域名进行访问，并确保将网站内容交付给发出请求的用户。软件方面还包括至少一个HTTP服务器的几个组件。HTTP服务器能够理解HTTP和URL。Web服务器作为硬件，是一台存储Web服务器软件和与网站相关的其他文件（例如 HTML 文档，图像和 JavaScript 文件）的计算机。当网络浏览器（例如Google Chrome或Firefox）需要在网络服务器上托管的文件时，浏览器将通过HTTP请求该文件。当Web服务器接收到请求时，HTTP服务器将接受该请求，查找内容并将其通过HTTP发送回浏览器。更具体地说，当浏览器从Web服务器请求页面时，该过程将遵循一系列步骤。首先，一个人将在网络浏览器的地址栏中指定一个URL。然后，Web浏览器将获取域名的IP地址-通过DNS（域名系统）翻译URL或在其缓存中搜索。这会将浏览器带到Web服务器。然后，浏览器将通过HTTP请求从Web服务器请求特定文件。Web服务器将做出响应，再次通过HTTP向浏览器发送请求的页面。如果请求的页面不存在或出现问题，则Web服务器将响应并显示一条错误消息。然后，浏览器将能够显示该网页。一台Web服务器上也可以托管多个域。

3.9应用程序服务器(Application server)

用程序服务器是分布式网络中计算机中的服务器程序，它为应用程序提供业务逻辑。通常将应用程序服务器视为三层应用程序的一部分，该三层应用程序由图形用户界面（GUI）服务器，应用程序（业务逻辑）服务器以及数据库和事务处理服务器组成。更具描述性地，可以将其视为将应用程序划分为：
1.基于Web浏览器的第一层，前端，图形用户界面，通常在个人计算机或工作站上。
2.中间层业务逻辑应用程序或一组应用程序，可能在局域网或Intranet服务器上。
3.第三层后端，数据库和事务服务器，有时在大型机或大型服务器上。
在许多用法中，应用程序服务器与Web（超文本传输协议）服务器结合或一起使用，称为Web应用程序服务器。Web浏览器为用户提供了一个易于创建的基于HTML的前端。Web服务器提供了几种不同的方式将请求转发到应用程序服务器，以及将修改后的网页或新的Web页面转发回用户。这些方法包括通用网关接口（CGI），FastCGI，Microsoft的Active Server Page和Java Server Page。在某些情况下，Web应用程序服务器还支持请求“代理”接口，例如CORBA Internet Inter-ORB协议（IIOP）。

3.10数据库服务器(Database server)

数据库服务器可以指用于运行数据库的硬件和软件。遵循传统的客户端-服务器模型，数据库服务器作为软件，是数据库应用程序的后端部分。该后端部分有时称为实例。它还可能是指用于承载数据库的物理计算机。在本文中提到时，数据库服务器通常是承载数据库的专用高端计算机。

请注意，数据库服务器独立于数据库体系结构。关系数据库，平面文件，非关系数据库：所有这些体系结构都可以容纳在数据库服务器上。
在客户端服务器计算模型中，有一个专用主机来运行和提供资源，通常是一个或多个软件应用程序。还有几个客户端可以连接到服务器并使用此服务器提供和托管的资源。
在考虑客户机/服务器模型中的数据库时，数据库服务器可能是数据库应用程序（实例）的后端，也可能是承载实例的硬件计算机。有时，它甚至可以指硬件和软件的组合。
在中小型设置中，硬件数据库服务器通常还将托管使用该数据库的软件应用程序的服务器部分。例如，如果我们考虑银行，则硬件数据库服务器将托管软件数据库服务器和银行的软件应用程序。该应用程序可能会通过特定的端口连接到数据库，并使用进程间通信来登录和访问驻留在数据库中的数据。银行中坐在个人计算机上的用户也将使用计算机上安装的应用程序的客户端模块来连接数据库。在此示例中，实际上我们正在查看两种客户端-服务器模型：数据库和应用程序。
在较大的设置中，事务量可能使得一台计算机将无法处理负载。在这种情况下，数据库软件将驻留在专用计算机上，而应用程序将驻留在另一台计算机上。在这种情况下，有一个专用的数据库服务器（由硬件和软件组成）和一个单独的专用应用程序服务器。

四、第三类关键字

4.1面向对象设计(Object-oriented design)

在分析阶段之后，使用面向对象设计（OOD）将概念模型进一步开发为面向对象模型。在OOD中，将分析模型中与技术无关的概念映射到实现类上，确定约束并设计接口，从而形成用于解决方案领域的模型。简而言之，构建了详细的说明，指定如何在具体技术上构建系统。
我们的高校人事管理系统主要有三个角色，管理员可以审核反馈信息、工资管理、审核请假申请、用户管理、职位管理；教师和工勤人员可以查看基本信息、查看工资和提交反馈信息。

面向对象设计的阶段可以标识为：
• 系统上下文的定义
• 设计系统架构
• 识别系统中的对象
• 设计模型的构建
• 对象接口规范
面向对象的系统设计涉及定义系统的上下文，然后设计系统的体系结构。
• 上下文-系统的上下文具有静态和动态部分。使用整个系统的简单框图设计系统的静态上下文，该框图被扩展为子系统的层次结构。子系统模型由UML包表示。动态上下文描述了系统如何与其环境交互。使用用例图对其进行建模。
• 系统体系结构-系统体系结构是根据体系结构设计原则以及领域知识在系统上下文的基础上进行设计的。通常，将系统划分为几层，然后分解每一层以形成子系统。
分解意味着按照分而治之的原则，将一个大型的复杂系统划分为具有较小复杂性的较小组件的层次结构。系统的每个主要组成部分都称为子系统。面向对象的分解可识别系统中的各个自治对象以及这些对象之间的通信。
分解的优点是-
• 各个组件的复杂度较低，因此更易于理解和管理。
• 它可以使具有专业技能的劳动力分工。
• 它允许替换或修改子系统而不会影响其他子系统。

4.2软件再利用(Software reuse)

软件重用的定义是从预定义的软件组件创建软件系统的过程。
比如我们高校人事管理系统，教师与后勤人员的系统操作界面基本相同，这里我们就可以使用代码重用来减少开发的消耗等。
软件重用的优点：

1. 可重用组件的系统开发。
2. 这些组件的系统重用作为构建新系统的基础。
   可重用的组件可能是代码，但是重用的更大好处来自对可重用内容的更广泛和更高层次的了解。软件规范，设计，测试用例，数据，原型，计划，文档，框架和模板都是重用的候选对象。
   软件重用可以减少软件开发时间和成本。软件重用的主要优点是：
3. 提高软件生产率。
4. 缩短软件开发时间。
5. 改善软件系统的互操作性。
6. 用更少的人开发软件。
7. 在项目之间更轻松地移动人员。
8. 降低软件开发和维护成本。
9. 产生更多标准化的软件。
10. 产生质量更高的软件，并提供强大的竞争优势。

4.3软件设计模式(Design patterns)

设计模式(英语 design pattern)是对面向对象设计中反复出现的问题的解决方案。这个术语是在1990年代由Erich Gamma等人从建筑设计领域引入到计算机科学中来的。这个术语的含义还存有争议。算法不是设计模式，因为算法致力于解决问题而非设计问题。设计模式通常描述了一组相互紧密作用的类与对象。设计模式提供一种讨论软件设计的公共语言，使得熟练设计者的设计经验可以被初学者和其他设计者掌握。设计模式还为软件重构提供了目标。
设计模式用于表示由经验丰富的面向对象软件开发人员改编的一些最佳实践。设计模式系统地命名，激励和解释了解决面向对象系统中反复出现的设计问题的通用设计。它描述了问题，解决方案，何时应用解决方案及其后果。它还提供了实现提示和示例。
创建型模式：
　　1. 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
　　2. 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
　　3. 工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
　　4. 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
5. 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
结构型模式：
　　1. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
　　2. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
　　3. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
　　4. 装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
　　5. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
　　6. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
　　7. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
行为型模式：
　　1. 模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
　　2. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
　　3. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
　　4. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
　　5. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
　　6. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
　　7. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
　　8. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
　　9. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
　　10. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
　　11. 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

4.4类别图(Class diagrams)

类图是静态图。它表示应用程序的静态视图。类图不仅用于可视化，描述和记录系统的不同方面，而且还用于构造软件应用程序的可执行代码。类图描述了类的属性和操作以及对系统施加的约束。由于类图是唯一的UML图，可以直接使用面向对象的语言进行映射，因此它们被广泛用于面向对象系统的建模中。类图显示了类，接口，关联，协作和约束的集合。也称为结构图。
类图的目的是为应用程序的静态视图建模。类图是唯一可以直接用面向对象的语言映射的图，因此在构造时被广泛使用。
UML图（例如活动图，序列图）只能给出应用程序的序列流，但是类图则有些不同。它是编码器社区中最流行的UML图。
类图的目的是为应用程序的静态视图建模。类图是唯一可以直接用面向对象的语言映射的图，因此在构造时被广泛使用。
UML图（例如活动图，序列图）只能给出应用程序的序列流，但是类图则有些不同。它是编码器社区中最流行的UML图。
类图的目的可以概括为：
• 分析和设计应用程序的静态视图。
• 描述系统的职责。
• 组件图和部署图的基础。
• 正向和反向工程。

4.5开源程序(Open-source code)

开源软件（英文全称：Open source software，英文缩写：OSS，中文全称：开放源代码软件）是一种源代码可以任意获取的计算机软件，这种软件的版权持有人在软件协议的规定之下保留一部分权利并允许用户学习、修改、增进提高这款软件的质量。开源协议通常符合开放源代码的定义的要求。一些开源软件被发布到公有领域。开源软件常被公开和合作地开发，开放源代码软件是开源发展的最突出的例子，也经常与用户生成内容（user-generated content）做比较。开源软件的英文“open-source software”一词出自free software（自由软件）的营销活动中。Standish集团一份报告指出，采用开放源代码软件的模式让消费者每年节省60亿美元。
我们高校人事管理系统也本着开源的理念，将代码开源，可供更多的开发人员参考和提出意见，这样才能我们的系统才会更加地完善。

4.6静态模型(Static model)

OOA和OOD活动都使用静态模型。下图中显示了另一个静态视图，用于说明对象分解，并提供了有关ATM Machine对象的更详细的视图。描述了ATM机与客户显示，交易和打印机组件之间的整体关系的汇总。继承与现金提取和支票存款一起显示为父交易的派生对象。

静态模型的另一种形式是如下图所示的模块架构图。这用于OOD阶段，并说明静态体系结构实体及其接口。每个设计图标都描述了用于与封装在图标边界内的对象之间收发消息的接口。可以通过连接对象的线上的箭头方向指示消息流。

4.7动态模型(Dynamic model)

动态模型，是指描述系统各组成部分之间及系统与外界之间的平衡关系以及这些关系的运动过程的模型。如系统动力学模型，弹簧振子的位移方程式等。动态模型能反映系统在运动变化过程中各种因素相互作用的动态特征，与静态模型相比，它加进了时间因素，因而能更有效地实现对真实系统的模拟。
动态模型描述与操作时间和顺序有关的系统特征、影响更改的事件、事件的序列、事件的环境以及事件的组织。
借助时序图、状态图和活动图，可以描述系统的动态模型。动态模型的每 个图均有助于理解系统的行为特征。对于开发人员来说，动态建模具有明确性、可视性和简易性的特点。
大量成功的软件工程实践难了动态模型的补助性，而动态模型的优越性使得该方法被广泛接受。动态建模的优势性列举如下：
1：如同建筑物或永恒的建筑模型可显示施工场地的结构和设计一样，动态模型使用户和开发人员能更容易地理解构思中的系统。
2：建模有助于解释状态的更改，并通过将不重要的方面与重要的方面分开而子降低复杂度。借助每个状态图和时序图可降低系统的复杂度。
3：借助于动态模型，可监视构思中的系统是否存在任何类型的缺陷，如果在开发开始后才发现这些缺陷，则可能需要付出昂贵的代价。
4：维护模型比维护系统容易得多，成本也降低了很多。

4.8接口规格(Interface specification)

标准接口在系统设计过程中发挥着重要的作用，可为设计实现互操作性与低成本，并减少设计所需的时间，但对需要实现产品差异化的设计团队而言，其实用性仍然很用限。设计人员还应依赖芯片厂商为其提供各种多组合标准接口。对芯片厂商而言，可帮助高效实施接口的高质量软件是实现差异化的其它因素。提供更高级别的灵活性也非常有帮助，能够通过TIPRU与UPP等可配置接口获得。系统设计人员利用其工具套件中的这些选项，即可发挥创造性，同时又能保持组件的低成本。

4.9状态机模型(State machine model)

状态机模型：要求设计者要考虑所有可能的状态，以及所有可能输入条件下可能进行的所有状态转移。
时序程序模型：它是通过一系列可重复执行或有条件执行的指令来变换数据的。状态机模型在许多场合中用来描述效果更好。因为用状态机来进行描述提供了更自然的计算方法。

五、第四类关键字

5.1工作流程管理系统(Workflow Management Systems)

工作流管理系统是旨在帮助创建，维护和存储信息的工作流程的各个部分的计算机系统。这种系统的目的是通过强调可以更快移动的事物和可以提高效率的领域来帮助创建报告和其他有用的数据，从而改善工作流程并帮助提高生产率。工作流管理是工作世界中一个相当新的概念。本质上，工作流管理的思想是，通过管理数据，文档，线索和其他与工作相关的项目的进度，可以简化工作流程，并且可以轻松记录流程中的任何故障。

工作流管理系统可用于收集有助于改进流程的数据和报告。
在当今的业务环境中，出于多种原因使用工作流管理系统。越来越多地使用和遵守工作流管理系统的一个主要原因是该系统可用于跟踪员工绩效。通过将所有内容记录到工作流管理系统中，如果以后出现问题，则很容易看到问题的根源并采取适当的措施。这样，可以确认每个员工都在正确，及时地完成工作。员工还可能对未及时完成或未正确完成的工作负责。
工作流管理系统的另一个用途是协助客户服务过程。为此目的使用的工作流管理系统通常称为客户关系管理系统或CRM。CRM通过确保客户服务人员可以访问详细记录来帮助客户进行投诉，从而帮助客户服务。这些系统还跟踪与客户的每一次联系，以便为可能出现的任何问题找到“与谁交谈”的证据。CRM还可在采用CRM的公司认为合适的任何时候对客户进行营销。
这样的系统还可以提高工厂环境中的生产率和产量。通过使用工作流管理系统跟踪从原材料到成品的生产过程，可以更轻松地识别生产周期中的瓶颈。识别导致延迟或过多工作和成本的低效率流程也将变得更加容易。因此，使用工作流管理系统可以成为提高任何公司的生产力，问责制和客户关系的好方法。

5.2 结构化分析 (Structured Analysis)

结构化概念在结构化分析方法中达到了顶峰，该方法目前以多种形式存在。在结构化分析方法中，当前的应用程序系统被捕获在“数据流程图”中。该技术本身主张将逻辑设计和物理实现分开。为此，现有的数据存储被视为旧的物理模型，并从中得出了新的逻辑模型。如果没有以前的系统，则将手动过程视为一个系统进行分析并记录下来。然后，这种新的逻辑设计将重点放在完成了什么而不是如何完成上。
然后可以将更改应用于包含客户所需更改的逻辑模型。更改后的模型将成为甚至更“新”的新模型，并转换为新的物理模型以供实施。由于这种方法对业务问题和程序解决方案之间的关系的演变产生了影响，因此改进了模块化的概念。这种改进使程序模块的结构，模块之间的接口和通信限制以及质量测量变得统一。后来，这段时间中的一些重要发现对于形成面向对象设计的概念根源很有用，我们将在其他地方更详细地介绍这些概念。

5.3 异步动作 (Asynchronous Action)

在工作流程执行期间，Mistral最终会运行操作。动作是与工作流任务相关联的特定功能（或一项工作）。 动作可以是同步的也可以是异步的。 同步动作是在没有第三方的情况下完成的动作，即由Mistral本身完成的动作。当Mistral引擎计划运行同步操作时，它将其定义和参数发送给Mistral执行器，然后执行器运行它，并在完成后将操作结果发送回Mistral引擎。 对于异步操作，执行程序不会将结果发送回Mistral。实际上，异步操作的概念假定执行程序运行它时，结果将不会为人所知。而是假设该操作只会将实际工作委托给第三方，该第三方可以是人为系统或计算机系统（例如Web服务）。因此，异步操作的run（）方法应该只是向能够执行所需工作的对象发送信号。 一旦第三方完成工作，它就有责任通过Mistral API将操作结果发送回Mistral。实际上，第三方只需要更新相应动作执行对象的状态即可。为了使其成为可能，它必须知道相应的动作执行ID。 值得注意的是，从Mistral引擎的角度来看，在同步和异步操作的情况下，架构本质上是相同的。如果动作是同步的，则执行器在动作完成后立即使用RPC机制（通常是消息队列作为传输）将结果发送回Mistral引擎。但是引擎本身并没有主动等待任何东西，它的架构完全基于异步消息。因此，在异步操作的情况下，唯一的变化是执行者不负责发送操作结果，其他事务接管了执行者。 让我们看看使用异步操作时需要记住的内容。

5.4 应用程序域(Application Domain)

.NET引入了应用程序域或应用程序域的概念。像过程一样，应用程序域既是容器又是边界。.NET运行时将应用程序域用作代码和数据的容器，就像操作系统将进程用作代码和数据的容器一样。由于操作系统使用进程来隔离行为异常的代码，因此.NET运行时使用应用程序域来隔离安全边界内的代码。
一个应用程序域仅属于一个进程，但是一个进程可以容纳多个应用程序域。与过程相比，应用程序域的创建成本相对较低（与流程相比），并且维护开销相对较小。由于这些原因，对于托管数百个应用程序的ISP来说，应用程序域是一个很好的解决方案。每个应用程序都可以存在于隔离的应用程序域中，并且许多应用程序域可以存在于单个进程中节省了成本。

5.5 关联结束(Association End)

一个关联端标识实体类型上的一个端部的关联，并且可以在关联的端部存在实体类型的实例的数目。关联结束定义为关联的一部分；一个关联必须恰好有两个关联结束。导航属性允许从一个关联端导航到另一关联端。
下图显示了具有两个关联的概念模型：PublishedBy和WrittenBy。关联的关联结束PublishedBy是Book和Publisher实体类型。Publisher末端的多重性是一（1），Book末端的多重性是许多（*），表示出版者出版了许多书籍，而一本书由一个出版者出版。

ADO.NET实体框架使用称为概念架构定义语言（CSDL）的领域特定语言（DSL ）来定义概念模型。下面的CSDL定义了PublishedBy上图中所示的关联。注意，类型，名称和每个关联端的多重性是由XML属性（指定的Type，Role和Multiplicity属性，分别地）。有关在一端执行的操作的可选信息在XML元素（OnDelete元素）中指定。在这种情况下，如果删除了出版商，则所有关联的书也将删除。

5.6 需求管理(Requirements Management)

需求管理是收集，分析，完善和确定产品需求的优先级，然后计划交付的过程。需求管理的目的是确保组织验证并满足其客户以及外部和内部利益相关者的需求。 需求管理涉及项目团队成员与利益相关者之间的沟通，以及在整个项目过程中对需求变更的调整。为了防止一类需求超越另一个需求，开发团队成员之间的持续沟通至关重要。 需求管理不随产品发布而结束。从那时起，收集有关应用程序可接受性的数据，并将其输入到下一代或发行版的调查阶段。因此，该过程再次开始。
需求是某些工作（在这种情况下为软件开发）的结果应满足的已定义能力。它是产品整个生命周期中的一个连续过程，许多利益相关者都可以产生需求，包括：客户，合作伙伴，销售，支持，管理，工程，运营，当然还有产品管理。当正确地制定和管理需求时，产品团队与工程成员之间将保持清晰，一致的沟通，任何需要的变更都将与所有利益相关者广泛共享。

5.7软件需求文件(Software requirements documentation)

  软件开发是一个令人兴奋的创造性解决问题、设计和工程的过程。但是在闪亮的应用程序和精致的网页之下，隐藏着一个不那么性感但非常重要的脚手架，它让好的软件成果成为可能:文档。文档确保团队和个人涉众在产品或软件应用程序的目标、范围、约束和功能需求方面意见一致。

不幸的是，创建和记录这些需求的过程可能是乏味、混乱和混乱的。软件需求文档可能很快变成冗长、笨拙、文本量大的文档，使它们特别容易出错、不一致和被曲解。正因为如此，编写和使用这些文档可能会很耗时，并导致代价高昂的(也是可以避免的)设计错误。
在高校人事管理系统中，软件需求文件就是对用户与领导等等涉众的需求的分析，在编写软件需求文件时主要考虑关键涉众即教职工、领导的需求，软件需求文件必须在项目开始的第一步就完成。

5.8需求管理(Requirements management)

需求管理是收集、分析、提炼产品需求并对其进行优先级排序，然后规划其交付的过程。需求管理的目的是确保组织验证并满足其顾客以及外部和内部利益相关者的需求。需求管理包括项目团队成员和利益相关者之间的沟通，以及在整个项目过程中对需求变化的调整。为了防止一类需求覆盖另一类需求，开发团队成员之间的持续沟通是至关重要的。需求管理不会随着产品发布而结束。从那时起，关于应用程序可接受性的数据被收集起来，并输入到下一代或下一个版本的调查阶段。这样，这个过程就会再次开始了。
在高校人事管理系统中，需求管理也包括在软件需求文件里，是在对项目关键涉众的需求分析完成后再进行进一步的分析管理，结合领导（利益相关者）与开发团队的利益，对软件需求文件的修改与完善，这一系列操作就是高校人事系统的需求管理。

5.9非功能性需求(Non-functional requirements)

非功能需求定义了系统属性，如安全性、可靠性、性能、可维护性、可扩展性和可用性。它们在不同的积压工作中作为系统设计的约束或限制。也称为系统质量，非功能性需求和功能性史诗、功能、特性和故事一样重要。它们确保了整个系统的可用性和有效性。未能满足其中任何一项都可能导致系统无法满足内部业务、用户或市场需求，或者无法满足监管机构或标准机构强加的强制性要求。在某些情况下，不合规会导致重大的法律问题(隐私、安全、安保等)。与功能需求不同，非功能需求是持久的质量和约束，通常在每次迭代、程序增量或发布时作为完成定义的一部分被重新考虑。非功能需求影响所有的积压工作:团队、项目、解决方案和投资组合。国家森林资源的适当定义和实施至关重要。过度指定它们，解决方案可能成本太高而不可行；对他们的详细说明不够或表现不佳，系统将无法满足其预期用途。探索、定义和实现非功能需求报告的适应性和增量方法是敏捷团队的一项重要技能。
高校人事管理系统 非功能性需求分析：
在高校人事管理系统中，非功能性需求可以简单理解为系统的质量需求，主要包含了安全性、可靠性、性能、可维护性、可扩展性和可用性等；这些都是非功能性需求，但是用户在使用时最考虑稳定性与可用性，不同于功能需求，非功能性大多都是隐性的。

5.10外显性质(Emergent properties)

外显性质是各种系统组件一起工作的结果，而不是任何单个组件的属性。换句话说，它是一个复杂系统或系统部件的集合所具有的属性，但却是单个部件所不具备的。该术语用于系统理论、科学、哲学，甚至是创造性的媒介，它概括了“大于其各部分之和”的习语。因为在更宏观的分析层次上可以看到涌现的特性，所以只检查系统的单个部分将会阻止人们看到涌现的特性。涌现属性的例子包括生化系统、大脑和蚁群。让我们仔细看看一些涌现属性的例子，并讨论该属性如何只在正确的分析级别上显示自己。
高校人事管理系统 外显性质分析：
在高校人事管理系统中，外显性质是一个复杂系统或系统部件的集合所具有的属性，但却是单个部件所不具备的，它属于一整个高校人事管理系统，是登录子系统、功能子系统（打卡子系统、请假子系统）、修改信息子系统等等共同工作时的结果。

六、第五类关键字

6.1项目关系人(Project stakeholders)

确定利益相关者是一项主要任务，因为项目启动、规划和执行阶段的所有重要决策都由这些利益相关者做出。五个主要的项目涉众是项目经理、项目团队、职能管理层、发起人和客户。从更大的意义上说，任何参与项目或受项目结果影响的人都是利益相关者。每个利益相关者都有重要的贡献，所有利益相关者的期望都需要得到满足。不同的人对项目的贡献是确定利益相关者的主要标准。
高校人事管理系统 项目关系人分析：
在高校人事管理系统中，项目关系人可以理解为涉众，主要有开发团队、教职工、领导、外界力量（专家、行业趋势、政府等）；其中，关键涉众有教职工、领导。

6.2 结构化分析(Structured Analysis)

结构化概念在结构化分析方法中达到了顶峰，该方法目前以多种形式存在。在结构化分析方法中，当前的应用程序系统被捕获在“数据流程图”中。该技术本身主张将逻辑设计和物理实现分开。为此，现有的数据存储被视为旧的物理模型，并从中得出了新的逻辑模型。如果没有以前的系统，则将手动过程视为一个系统进行分析并记录下来。然后，这种新的逻辑设计将重点放在完成了什么而不是如何完成上。
然后可以将更改应用于包含客户所需更改的逻辑模型。更改后的模型将成为甚至更“新”的新模型，并转换为新的物理模型以供实施。由于这种方法对业务问题和程序解决方案之间的关系的演变产生了影响，因此改进了模块化的概念。这种改进使程序模块的结构，模块之间的接口和通信限制以及质量测量变得统一。后来，这段时间中的一些重要发现对于形成面向对象设计的概念根源很有用，我们将在其他地方更详细地介绍这些概念。

6.3标记值(Tagged values)

原型和标记值扩展了现有的UML模型元素，使它们适应不同的目的。标记值是一个标记值对，可以用来给UML中的模型元素添加属性。在UML 2中，标记值只能应用于使用带有标记定义的原型的模型元素。标记值以tag = value的形式显示，其中tag是标记名，value是文字值。标记值与代码生成或配置管理特别相关。
高校人事管理系统 标记值分析：
在高校人事管理系统中，标记值在不同的阶段是具有不同的内涵的，在用户登录阶段时，标记值是用户的登录注册状态；在打卡请假阶段，标记值是用户的打卡请假申请；标记值与打卡请假代码生成或系统账号配置管理特别相关。

6.4子机状态(Submachine State)

状态机中的一种状态，相当于复合状态，但其内容由另一个状态机描述。
高校人事管理系统 子机状态分析：
在高校人事管理系统中，状态机中的一种状态，相当于复合状态，但其内容由另一个状态机描述。

6.5数据流图(Dataflow Diagram)

数据流图是一种图形化的系统模型，它在一张图中展示信息系统的数据流向——即系统的输入与输出数据分别是什么，数据从哪里来并最终流向何处，以及数据存储在什么地方。
数据流图的基本图形元素有：
数据流：是由一组固定成分的数据组成，表示数据的流向。值得注意的是，数据流图中描述的是数据流，而不是控制流。除了流向数据存储或从数据存储流出的数据不必命名外，每个数据流必须要有一个合适的名字，以反映该数据流的含义。
加工：加工描述了输入数据流到输出数据之间的变换，也就是输入数据流经过什么处理后变成了输出数据。每个加工都有一个名字和编号。编号能反映该加工位于分层的数据流图的哪个层次和哪张图中，能够看出它是由哪个加工分解出来的子加工。
数据存储：数据存储表示暂时存储的数据。每个数据存储都有一个名字。
外部实体：外部实体是存在于软件系统之外的人员或组织，他指出数据所需要的发源地或系统所产生的数据的归属地。
高校人事管理系统 数据流图分析：
在人事管理系统中，数据流图可以表示如上图，教职工、领导是系统外的两个外部实体，教职工把他的打卡请假申请信息输入系统中，系统内部则接收来自外部实体（教职工）的打卡申请信息，打卡成功之后，教职工的打卡记录会被记入用户数据库，然后系统输出打卡成功信息返回给教职工；领导则是输入修改教职工的工资申请信息给系统，系统则输出修改成功结果信息返回给领导。

6.6包含关系(Include Relationship)

包含关系将基本用例连接到包含用例。包含用例总是抽象的。它描述了插入到执行基本用例的用例实例中的行为段。基本用例控制着与包含的关系，并且可以依赖于执行包含的结果，但是基本用例和包含都不能访问彼此的属性。从这个意义上说，包含是封装的，并且表示可以在不同的基本用例中重用的行为。
高校人事管理系统 包含关系分析：
在高校人事管理系统中，基本用例是多样化的，这意味着包含关系也是多样化的，基本用例如查看信息等都控制着与包含的关系，依赖于执行包含的结果，但是包含不能访问基本用例的关系。

6.7过渡(Transitions)

过渡是源顶点和目标顶点之间的有向关系。它可能是复合转换的一部分，复合转换将状态机从一种状态配置带到另一种状态配置，表示状态机对特定类型事件发生的完整响应。从一个状态到下一个状态的过渡由事件触发。事件由一个名称和一系列可能的参数组成。一个状态可以对事件设置必须满足的条件，这样这个状态就可以被这个事件接受。这些条件可以独立于特殊事件。
高校人事管理系统 过渡分析：
在高校人事管理系统中，过渡是从一个事件到另一个事件之间的状态，同时它也有可能是从一个状态到另一个状态的转换过程，即它是对人事管理系统从打卡事件到修改个人信息的转换过程的描述，也是对打卡事件从提交打卡信息状态到打卡成功状态的转换过程的描述；过渡也可以是一个关系，描述提交打卡信息状态与打卡成功状态的关系，但是过渡的发生必须具备一定的条件，而且这些条件独立于特殊事件。

6.8应用程序域(Application domain)

操作系统和运行时环境通常在应用程序之间提供某种形式的隔离。例如，Windows使用进程隔离应用程序。这种隔离是必要的，以确保在一个应用程序中运行的代码不会对其他不相关的应用程序产生不利影响。应用程序域为安全性、可靠性和版本控制以及卸载程序集提供了隔离边界。应用程序域通常由运行时主机创建，运行时主机负责在应用程序运行之前引导公共语言运行时。
高校人事管理系统 应用程序域分析：
在高校人事管理系统中，应用程序域为用户数据的安全性、系统的可靠性和版本控制以及卸载程序提供了隔离边界，使系统的稳定性上升一个层次；在系统运行时由管理员创建，且管理员在应用程序域里进行对公共语言的运行的引导，避免应用程序运行时出错。

6.9内外关系图(Context Diagram)

上下文图(有时也称为0级数据流图)是业务分析师用来理解被检查实体的上下文的常用工具。
高校人事管理系统 内外关系图分析：
在高校人事管理系统中，上下文图（内外关系图）是一个常用的检查工具，用于检查几个外部实体的关系，便于管理员及开发团队理解。

6.10可维护性(Maintainability)

软件系统可以被修改以纠正错误或使系统适应不断变化的需求的容易程度。可维护性可以被描述为质量要求。可维护性的一个原因是如此重要，没有它你不能累积试验。平均来说，一个应用程序改写每年25%；如果与修改的部分相关的试验不能以合理的努力去改变，那么他们将被淘汰。因此，而不是逐渐提高测试覆盖率随时间积累越来越多的测试用例，你将重新测试而不是丢弃。
高校人事管理系统 可维护性分析：
在高校人事管理系统中，可维护性主要是由用户数据库的稳定性确定的，只要数据库的结构与信息不丢失，人事管理系统的可维护性就会一直保持着，当然有关的应用实施也不能太过落后。

6.11关联(Association)

关联是分类器之间的一种关系，用于表明分类器的实例可以相互链接，或者在逻辑上或物理上组合成某种集合。UML规范将关联归类为语义关系。一些其他的UML资源也将关联归类为一种结构关系。维基百科声明关联是实例级关系，关联只能在类图上显示。不知道他们是从哪里得到这些信息的，但它不是基于统一建模语言规范的。关联可以用于不同类型的UML结构图:
类图关联；
用例图关联；
部署图工件关联；
部署图通信路径。

高校人事管理系统 关联分析：
在高校人事管理系统中，关联也是关于分类器之间的连接关系的描述，用于不同的外部实体之间，如用户与管理员之间的关系（管理与被管理）就可以被称作是“关联”。

6.12关联终端(Association End)

关联端标识关联一端的实体类型，以及在该关联端可以存在的实体类型实例的数量。关联端被定义为关联的一部分；一个关联必须正好有两个关联端。导航属性允许从一个关联端导航到另一个关联端。关联结束定义包含以下信息:
关联中涉及的实体类型之一。(必需){注意：对于给定的关联，为每个关联端指定的实体类型可以相同。这就产生了自我联想。一个关联端多重性，指示可以位于关联一端的实体类型实例的数量。关联端多重性的值可以是1、0或1(0…1)，或者很多(*)。}
关联结束的名称。(可选)
关于在关联端执行的操作的信息，如删除时级联。(可选)
高校人事管理系统 关联终端分析：
在高校人事管理系统中，关联终端是关联的末端，一个关联对应两个关联终端，如在用户与管理员的关系中，它们的关系就是关联，而用户与管理员就是这个关联的末端，即关联终端。

6.13并发性(Concurrency)

在同一时间间隔内两个或多个活动的发生。并发性可以通过交错或同时执行两个或多个线程来实现。现实世界包含独立执行但相互交流的参与者。在世界建模中，许多并行执行必须被组合和协调，这就是并发性研究的切入点。
高校人事管理系统 并发性分析：
在高校人事管理系统中，并发性就是当同一个数据库或页面、功能在一段时刻内被多个用户访问时是否能够稳定运行，并且各个用户之间互不影响，数据不会被重复记录或是缺失。

6.14 系统边界(System Boundary)

系统边界一般在用例图中显示，如下：

通常将用例显示在系统内部，将参与者显示在系统外部。
每个系统角色与角色之间都应设有边界。

七、第六类关键字

7.1需求抽取技术(Requirements elicitation technique)

实际需求获取是对任何软件测试项目的完成至关重要的一个环节。令人震惊的是，这是一个经常被许多业务分析师忽略的过程。在时间和支出计划方面，这种疏忽对项目来说可能是昂贵的，然而，更重要的是，这可能会导致分散的需求，或者更严重的是，导致项目失败。有很多需求获取技术，而且任何一种技术都可靠地为你服务是可疑的。尽管有些人可能只提倡一种启发方法——但人们普遍认为，一种技术不可能对所有项目都合理。
高校人事管理系统 需求抽取技术分析：
在高校人事管理系统中，需求抽取技术跟需求管理一样，也是在编写软件需求文件时用到的一个技术或步骤，是在编写软件需求文件时不可或缺的一步。

7.2需求确认(Requirements validation)

需求验证是检查为开发定义的需求，定义客户真正想要的系统的过程。为了检查与需求相关的问题，我们执行需求验证。我们通常在开发的初始阶段使用需求验证来检查错误，因为在开发过程的后期检测到错误时，可能会增加过多的返工。在需求验证过程中，我们执行不同类型的测试来检查软件需求规范中提到的需求，这些检查包括:

完整性检查
一致性检查
有效性检查
真实性检查
歧义检查
可验证性
需求验证的输出是问题列表和对检测到的问题的一致行动。问题列表表明在需求验证过程中检测到的问题。商定措施的列表说明了应采取的纠正措施，以解决检测到的问题。
高校人事管理系统 需求确认分析：
在高校人事管理系统中，需求确认在需求抽取之后进行，是在编写软件需求文件时用到的一个技术或步骤，是在编写软件需求文件时不可或缺的一步。

7.3需求工程程序(Requirement engineering processes)

 需求工程是定义、记录和维护需求的过程。这是一个收集和定义系统提供的服务的过程。需求工程流程包括以下主要活动:

需求获取
需求规格
需求验证和确认
需求管理
高校人事管理系统 需求工程程序分析：
在高校人事管理系统中，需求工程程序是软件需求文件在编写时使用的一个总的手段，办函了需求识别、需求抽取、需求验证与确认、需求管理等步骤。

7.4需求规格制订(Requirements specification)

 在软件开发中，需求规格说明是一系列过程的结果，这些过程旨在收集和记录描述系统或应用程序行为的信息。无论是网站、移动应用程序还是任何其他类型的系统，您都应该在实现阶段开始之前编写一个需求规范。如果用户和开发者是不同的两方，这一点尤其重要。
 需求规格说明的目的是为相关方(如用户和开发人员)提供一个系统应该是什么样子的共同画面。此外，需求规格说明在实现阶段和稍后的测试阶段都非常重要(在测试阶段，功能与预定义的需求进行比较)。需要注意的是，规范永远不能取代相关方之间良好的持续沟通。

此外，在某些情况下，需求规格也可以作为招标文件，包括交付时间和开发商方的报价。由于几个原因，在开发过程中更新文档很重要。客户端可能会出现新的功能需求，开发人员可能会出现可能的延迟/实施问题。
高校人事管理系统 需求规格制订分析：
在高校人事管理系统中，需求规格说明是一系列过程的结果，这些过程旨在收集和记录描述系统或应用程序行为的信息。需求规格也可以作为招标文件，包括交付时间和开发商方的报价。需求规格说明在实现阶段和稍后的测试阶段都非常重要(在测试阶段，功能与预定义的需求进行比较)。

7.5统一塑模语言(Unified modeling language)

 UML，统一建模语言的简称，是一种标准化的建模语言，由一组集成的图组成，旨在帮助系统和软件开发人员指定、可视化、构建和记录软件系统的工件，以及业务建模和其他非软件系统。UML代表了在大型复杂系统建模中被证明是成功的最佳工程实践的集合。UML是开发面向对象软件和软件开发过程中非常重要的一部分。统一建模语言主要使用图形符号来表达软件项目的设计。使用统一建模语言帮助项目团队进行交流，探索潜在的设计，并验证软件的架构设计。在本文中，我们将向您详细介绍什么是统一建模语言，统一建模语言的历史和每种统一建模语言图表类型的描述，以及统一建模语言的例子。

高校人事管理系统 统一塑模语言分析：
在高校人事管理系统中，统一塑模语言帮助系统和软件开发人员指定、可视化、构建和记录软件系统的工件，以及业务建模和其他非软件系统。统一建模语言主要使用图形符号来表达软件项目的设计。

7.6系统塑模(System modeling)

 控制软件设计过程的第一步是开发被控制系统的适当数学模型。这些模型可以来自物理定律或实验数据。在这一节中，我们介绍了动态系统的状态空间和传递函数表示。

高校人事管理系统 分析：
在高校人事管理系统中，系统建模在确定系统需求之后进行，给后面的工作提供一个大致的开发架构。

7.7模型驱动工程(Model-driven engineering)

 模型驱动工程(MDE)是一个迭代和增量的软件开发过程。支持按照MDE范式开发的软件系统的分析和验证，要求在以更优化的方式执行这些关键任务时采用增量方法。

通信状态机是MDE工具中用于建模和描述分布式、并发和实时反应系统(例如，汽车和航空电子系统)行为的各种形式之一。对这种系统的整体行为进行建模是以模块化的方式在不同的抽象层次上进行的(即，它首先对系统中各个对象的行为进行建模，然后对这些对象之间的交互进行建模)。同样，分析和验证已开发模型的正确性以确保其质量和完整性是在两个主要层面上进行的。层内用于分析独立于其他模型的单个模型的正确性，而层间用于分析相互通信的模型的整体互操作性。
高校人事管理系统 模型驱动工程分析：
在高校人事管理系统中，模型驱动工程(MDE)在电信行业有着悠久的历史，因为这些公司是第一批面临创建大型、分布式、可靠系统复杂性的公司。

7.8案例模型(Use case modeling)

 用例模型描述了新系统的建议功能。用例代表用户(人或机器)和系统之间交互的离散单元。这种交互是一个有意义的工作单元，例如创建帐户或查看帐户详细信息。

每个用例描述了要在建议的系统中构建的功能，它可以包括另一个用例的功能，或者用它自己的行为扩展另一个用例。
用例描述通常包括:
描述用例的一般注释和注释。
需求——用例必须向最终用户提供的事物的正式功能需求，例如<更新订单的能力>。这些对应于结构化方法中发现的功能规范，并形成一个契约，用例执行一些动作或为系统提供一些价值。
约束——用例运行的正式规则和限制，定义什么能做什么不能做。其中包括:
运行用例之前必须已经发生或已经存在的前提条件；例如，<创建订单>必须在<修改订单>之前
一旦用例完成，后条件必须为真；例如，<订单已修改且一致>
在用例运行的整个过程中必须始终为真的不变量；例如，订单必须始终有一个客户编号。
场景——对执行用例所采取的步骤的正式的、连续的描述，或者在用例实例中发生的事件流。这些可以包括多个场景，以适应特殊情况和替代处理路径。这些通常以文本形式创建，对应于序列图的文本表示。
场景图——描述工作流程的序列图；类似于场景，但以图形方式描绘。
附加属性，如实现阶段、版本号、复杂度等级、原型和状态。
高校人事管理系统 案例模型分析：
在高校人事管理系统中，用例模型中每个用例描述了要在建议的系统中构建的功能，它可以包括另一个用例的功能，或者用它自己的行为扩展另一个用例。

7.9行为模型(Behavioral models)

 行为模型的概念：所需行为或所需行为模式的详细概念。这种概念化包括根据观察到的公开行为对心理障碍的系统描述。

高校人事管理系统 行为模型分析：
在高校人事管理系统中，行为模型并未被建立。

7.10实时系统(Real-time systems)

 实时系统出现在过程控制和自动化中，它们越来越多地涉及与安全相关的应用。实时操作模式在德国工业标准DIN 44300 (1985)中被定义为计算机系统的操作模式，其中用于处理来自外部的数据的程序是永久准备好的，使得它们的结果将在预定的时间周期内可用；根据不同的应用，数据的到达时间可以随机分布或先验地确定。因此，实时计算机控制系统总是嵌入在更大的环境中，它们必须跟上环境的动态变化。因此，它们通常被视为嵌入式系统的同义词。

实时操作的特点是时间维度的明确参与，体现在基本的及时性要求上，即使在极端负载条件下，实时系统也必须满足这一要求。根据外部流程的要求，必须按时进行数据采集、评估和适当的反应。处理速度并不是决定性的，而是在预定义的和可预测的时间范围内的及时反应，尽管目前的技术水平还远远不能保证这样的范围。因此，实时系统的特点是，它们的功能正确性不仅取决于处理结果，还取决于这些结果可用的时刻。特别是在错误情况下，用户希望系统行为是可预测的，例如性能下降。只有完全确定性的系统行为才能最终为安全关键应用的计算机提供有效的安全许可。因此，系统行为的可预测性对于实时操作模式至关重要。它补充了时间性需求，因为后者只有在系统行为在时间和外部事件反应方面是精确可预测的情况下才能得到满足。
高校人事管理系统 实时系统分析：
在高校人事管理系统中，实时系统是时间关键的，它们的实现效率比其他系统更重要。效率可以根据处理器周期、内存或功耗进行分类。这种约束可能驱动从处理器的选择到编程语言的选择的一切。

7.11平台独立模型(Platform independent model)

  平台独立模型侧重于高级业务逻辑，不考虑系统实现技术的特点，不包含对底层技术平台的引用的模型。

高校人事管理系统 平台独立模型分析：
在高校人事管理系统中，平台独立模型未被建立。

7.12计算独立模型(Computation independent model)

 CIM的一个候选是状态图，它将所有用例的状态图组合成宏或子状态。(宏观状态是包含微观状态和跃迁的状态。)

高校人事管理系统 计算独立模型分析：
在高校人事管理系统中，计算独立模型未被建立。

7.13平台特定模型(Platform specific model)

 以特定于特定实现平台的方式定义功能的软件或系统模型。

高校人事管理系统 平台特定模型分析：
在高校人事管理系统中，平台特定模型未被建立。

7.14视图(View)

图 是模型元素集的图形表示，通常是由弧（关系）和顶点（其他模型元素）相互连接构成的。而视图是表达系统的某一方面的特征的UML建模元素的子集，由多个图构成，是在某一个抽象层上，对系统的抽象表示。
视图的分类：
UML是用来描述模型的，用模型来描述系统的机构或静态特征，以及行为或动态特征。从不同的视角为系统构架建模，形成系统的不同视图。
(1) 用例视图(Use Case View)，强调从用户的角度看到的或需要的系统功能，是被称为参与者的外部用户所能观察到的系统功能的模型图。 (2) 逻辑视图(Logical View)，展现系统的静态或结构组成及特征，也称为结构模型视图(Structural Model View)或静态视图(Static View)。 (3) 并发视图(Concurrent View)，体现了系统的动态或行为特征，也称为行为模型视图(Behavioral Model View)或动态视图(Dynamic View)。 (4) 组件视图(Component View)，体现了系统实现的结构和行为特征，也称为实现模型视图(Implementation Model View)。 (5) 配置视图(Deployment View)，体现了系统实现环境的结构和行为特征，也称为环境模型视图(Environment Model View)或物理视图(Physical View)。 根据图在不同架构视图的应用，可以把9种图分成：
(1) 用户模型视图：用例图； (2) 结构模型视图：类图和对象； (3) 行为模型视图：状态图、时序图、协作图和活动图（动态图）； (4) 实现模型视图：组件图； (5) 环境模型视图：配置图。 用户模型视图由专门描述最终用户、分析人员和测试人员看到的系统行为的用案组成，它实际上是从用户角度来描述系统应该具有的功能。用户模型视图所描述的系统功能依靠外部用户或者另外一个系统来激活，为用户或者另一系统提供服务，从而实现用户或另一系统与系统的交互。系统实现的最终目标是提供用户模型视图中所描述的功能。在UML中，用户模型视图是由用案图组成。 结构模型视图描述组成系统的类、对象以及它们之间的关系等静态结构，用来支持系统的功能需求，即描述系统内部功能是如何设计的。结构模型视图由类图和对象图构成，主要供设计人员和开发人员使用。 行为模型视图主要用来描述形成系统并发与同步机制的线程和进程，其关注的重点是系统的性能、易伸缩性和系统的吞吐量等非功能性需求。行为模型视图利用并发来描述资源的高效使用、并行执行和处理异步事件。除了讲系统划分为并发执行的控制线程之外，行为模型还必须处理通信和这些线程及进程之间的同步问题。行为模型视图主要供系统开发人员和系统集成人员使用，它由序列图、协作图、状态图和活动图组成。 实现模型视图用来描述系统的实现模块它们之间的依赖关系以及资源分配情况。这种视图主要用于系统的配置管理，它是由一些独立的构件组成的。实现模型视图由构件图组成。其中构件是代码模块，不同类型的代码模块形成不同的构件。实现模型视图主要供开发人员使用。 环境模型视图用来描述物理系统的硬件拓扑结构。例如，系统中的计算机和设备的分布情况以及它们之间的连接方式，其中计算机和设备统称为节点。在UML中环境模型视图是由部署图来表示的。系统部署图描述了系统构件在节点上的分布情况，即用来描述软件构件到物理节点的映射。部署图主要供开发人员、系统集成人员和测试人员使用。 上面每一种视图反映了系统的一个特定方面，不同人员可以单独的使用其中每一种视图，从而可以关注特定的体系结构问题。但在通常情况下，由于系统的最终目标是提供用户模型视图中描述的功能以及其它一些非功能性需求，因此，用户模型视图是其它视图的核心基础，其它视图的构造都依赖与用户模型视图中所描述的类容。

7.15需求模型 (Requirements Model)

需求模型(RQM) 是一种文档式模型，它通过准确恰当地列出，解释开发过程程中需要实现的功能行为来描述待开发项目。你可以为开发过程中需要使用到的各种结构化技术文档（功能或技术规格说明书，测试计划）而使用需求模型。
需求模型(RQM) 是一种文档式模型，它通过准确恰当地列出，解释开发过程程中需要实现的功能行为来描述待开发项目。你可以为开发过程中需要使用到的各种结构化技术文档（功能或技术规格说明书，测试计划）而使用需求模型。

7.16结构化分析(Structured Analysis)

结构化概念在结构化分析方法中达到了顶峰，该方法目前以多种形式存在。在结构化分析方法中，当前的应用程序系统被捕获在“数据流程图”中。该技术本身主张将逻辑设计和物理实现分开。为此，现有的数据存储被视为旧的物理模型，并从中得出了新的逻辑模型。如果没有以前的系统，则将手动过程视为一个系统进行分析并记录下来。然后，这种新的逻辑设计将重点放在完成了什么而不是如何完成上。
然后可以将更改应用于包含客户所需更改的逻辑模型。更改后的模型将成为甚至更“新”的新模型，并转换为新的物理模型以供实施。由于这种方法对业务问题和程序解决方案之间的关系的演变产生了影响，因此改进了模块化的概念。这种改进使程序模块的结构，模块之间的接口和通信限制以及质量测量变得统一。后来，这段时间中的一些重要发现对于形成面向对象设计的概念根源很有用，我们将在其他地方更详细地介绍这些概念。

7.17关联类(Association Class)

一个关联类是UML构建体，它使协会具有属性和操作（功能）。这导致具有关联和类别特征的混合关系。
添加关联类连接时，Enterprise Architect还将创建一个自动连接到关联的类。当您隐藏或删除关联时，该类也会被隐藏或删除。要将关联类添加到类或部署图中，请单击工具箱中的关联类图标。在将线拖动到目标元素的同时，单击并按住图中的源对象，然后释放鼠标按钮。Enterprise Architect绘制连接器并添加类，然后提示您添加类名称。请注意，类和连接器的名称相同。您还可以将新的班级连接到现有的协会.通过选择关联连接器上的“查找关联类”上下文菜单选项，可以在项目浏览器中突出显示关联类的“类”部分。
如果要将带有Shape Script的构造型应用于关联类，请注意，Shape Script同时应用于Class部分和Association部分。因此，您可能必须在形状主体中包含用于测试元素类型的逻辑，以便可以为类和关联提供单独的绘制指令 • 在以下情况中，不需要这样的逻辑： • 形状源或形状目标，这些类别或类会忽略它们 • 装饰形状，被关联连接器忽略 • 如果将“类”与“关联”连接器分离，则两个部分都将保持其形状脚本，直到移除构造型为止。

7.18逻辑模型(Logical Model)

逻辑模型是构成设计/分析空间的对象和类的静态视图。通常，域模型是业务对象和实体的较宽松的高级视图，而类模型是更严格且注重设计的模型。该讨论主要涉及类模型。
The Class Model类模型：
类是一种标准的UML构造，用于详细说明在运行时将根据其生成对象的模式。类是一种规范-对象是类的实例。类可以从其他类继承（即，它们继承其父类的所有行为和状态并添加自己的新功能），具有其他类作为属性，将职责委派给其他类并实现抽象接口。 类模型是面向对象的开发和设计的核心-它表示系统的持久状态和系统的行为。类封装状态（属性）并提供服务以操纵该状态（行为）。良好的面向对象设计限制了对类属性的直接访问，并提供了代表调用者操纵属性的服务。数据的这种隐藏和服务的公开确保了仅在一个地方并根据特定规则进行数据更新-对于大型系统，在许多地方可以直接访问数据元素的代码的维护负担非常高。
该类表示如下：

该类具有三个不同的区域： 1.类名（和原型（如果有的话）） 2.类属性区域（即内部数据元素） 3.行为-私人和公共 属性和方法可以标记为：
1.不公开，表示班外的呼叫者看不到它们 2.受保护，它们仅对班级的孩子可见 3.公开，所有人都看得到
Inheritance遗产：
类继承如下所示：在这种情况下，抽象类是两个子代的父代，每个子代都继承基类的功能并以自己的行为对其进行扩展。

可以将类模型收集到相关行为和状态的程序包中。下图说明了这一点。

八、建议

了解需求本身，需求分析不是一蹴而就的，它应当贯穿整个开发周期，不断的分析确认的过程。这就是敏捷开发倡导的需求反馈。敏捷开发认为，需求分析阶段不可能解决所有的需求问题，因此在设计、开发、测试，直到最终交付客户，这整个过程都应当不停地用开发的成果与客户交流，及时获得反馈。只有这样才能及时纠正需求理解的偏差，保证项目的成功。需求是为了解决一定问题而被提出的，分析不当，后面的工作都会因此被拖慢，甚至是跑偏，可以从三个维度来了解需求本身。

8.1了解需求对象

首先，了解需求对象。换位思考，模拟角度去思考问题是需求挖掘的重要方法，当接触需求时，首当其冲的就是要找出它真正的主人。作为产品经理最不缺的就是需求，被动的需求从不同的渠道涌现而来，提出需求的并不一定是需求用户，需要我们细心的去甄别。一般而言，将其分为四类：用于解决客户问题的用户需求，用于建设品牌或跟进竞争的市场需求，用于解决团队或企业自身问题的内部需求，用于解决由产品架构产生连带问题的自身需求。

8.2定位需求场景

其次，定位需求场景。坐在电脑前，敲着键盘握着鼠标，这是PC场景，QQ、博客、优酷等产品的天下；拿着手机到处走，随手敲文、发图、发视频，这是移动场景，因为新场景的出现才孕育出微信、微博、抖音等新的巨匠产品。而百度正是错失移动化的时代，导致如今尴尬地位——BAT 名不副实，强行跳入下一代人工智能、物联网的场景已属无奈。所以场景化去思考产品，决定细节的成败。

8.3询问需求本质

最后，询问需求本质。福特造车的故事想必大家耳熟能详，用户说他想要一匹更快的马，但福特通过追究需求的本质，探测出用户真正的需求在于用更短的时间到达目的地，于是福特造出了汽车。需求被提出来有可能是个伪需求，也可能只是个表面需求，由于存在认知偏差，用户并无法准确的描述出他们不知道的产品。所以面对需求时，一定要多问几次为什么，在我们对用户穷问为什么后，兴许能得到用户真正的需求，5个为什么在这里得到很好的发挥，请善用它。

8.4需求价值定位

需求价值定位，解决需求的产生的价值得从两方面说起，分别是用户价值与产品价值，两者区别明显。用户价值，从需求者本身去衡量，即需求解决了用户什么问题，满足了用户的什么层级期待感。产品价值，从企业或经营者的角度出发，解决用户需求后能否提高用户粘度、带动市场份额，最终给企业带来什么样的利益。需求的价值当然以用户为中心，只有用户的问题被解决才能创造出更多的价值，互联网的博弈就是看谁能得到用户的芳心，因此，市场的竞争也是用户的竞争，如果抓不住用户核心问题将会被对手超越。也只有产生了用户价值，才能带来反哺性的产品价值。但是只考虑用户价值也是不合理的，做点产品、创个业，没有盈利怎么谈持续发展，不图那点钱怎么有动力，考虑给用户带来价值的同时也需要考虑如何让企业获得价值。

8.5匹配实现成本

匹配实现成本，想法最终需要落地，在开始的时候不谈详细的设计，但基本的可行性却需要推演一下的，有几个成本是需要了解下的。1. 代替成本。用户有多懒“惰”，需求就越多，但也是因为如此，用户接触新产品更多是被动式。百度之所以错过移动时代却依然屹立不倒，就在于百度搜索在PC端早已深入人心，替代成本之高远远高搜索技术的壁垒。2. 研发成本。不同于大局面的所有成本，这里所说的更多是关于周期与研发部门的开发成本。不要理所当然的认为小小的需求就是一句代码搞定的事，天晓得背后是否会牵扯出一系列架构或技术瓶颈问题，最好与研发人员提前探讨取经一番。3. 市场成本。好的产品会说话，也可能是痴人说梦话，是产品就免不了需要推广、营销、与竞争对手相互切磋的成本，只要好的产品加上市场运营手段才能把产品推销出去。4. 试错成本。一切理论都是推演的，只有走上市场接收反馈才是真实的，如果最终试验结果证明最开始的想法就是错误的，那么之前所付出的成本将付诸东流，这种风险应该在我们的承受范围之内。产品经理是需要去衡量投入产出比的，因为每一个决策都会影响整个团队前进的方向。

8.6做好需求调研

8.6.1初识：
我们对客户提出的需求进行深入理解以后，运用我们专业知识，提出比客户的原始需求更加合理、可操作的解决方案，让客户感觉你说的正是他们想要的。如果能够这样，客户不仅能够欣然接收你提出的方案，而且会感觉你非常专业，你在客户心目中的形象也会无形中提高，使你有更多的机会提出有利于开发的可行方案，降低开发的风险。这毫无疑问会形成一个良性循环，但要做到这一点并不容易，毫无疑问，在与客户接触初期的表现起到了极其关键的作用。(1)高层领导关心的是宏观的目标，因此软件研发目标、宏观统计报表、决策支持功能，我们应该怎样做需求分析,应当与高层领导谈。(2)中层领导关心的是具体的效益，即软件给各个部门信息化管理方面带来的效益，因此，中层领导是各项业务流程、功能模块的需求决策者。他们关心功能的定义、业务流转的衔接、查询报表的设计，但不太关心一些具体的操作，以及一些具体业务流程的细节。(3)基层人员是每一项业务流程的操作者，也是软件今后真正的使用者。他们是真正了解你所要开发的软件的业务需求的领域专家，是你进行需求调研的重点对象。但是，基层人员往往受到自身视野的局限，可能只清楚自己工作涉及的十分狭小的一个范围，因此我们需要努力寻找那些业务涉及面广，经验丰富，又有一定大局观的真正的专家。另外 ，他们就是软件今后真正的使用者，让他们参加，会让他们成为今后软件推行的忠实支持者，对其他操作人员的指导者，益处多多。而他们关心的则是每项操作的细节。
8.6.2拜访：
需求调研不是一蹴而就的事情，是一件持续数月甚至数年的工作（假如项目还有后期维护） 。在这漫长的时间里，我们需要依靠客户这个群体的帮助，一步一步掌握真实可靠的业务需求 。不仅如此，技术这东西总有不如意甚至实现不了的地方，我们需要客户的理解与包容，这都需要有良好的客户关系。尽管如此，我们也不能总是期望客户中的所有人都能与我们合作，很多项目都不可避免地存在阻碍项目开展的人。
研讨会：
(1)由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；(2)集中式的业务研讨形式和分散式的业务研讨形式；(3)有效抑制个性化差异、分模块组织专项研讨会。
8.6.3研讨会：
(1)由于业务人员自身的局限 ，不可能对所有业务领域的细节全面掌握，往往总是有自己熟悉的部分，也有自己不熟悉的部分。划分业务组，可以让业务人员分别在自己最熟悉的业务范围内参与讨论，可以有效提高业务讨论的质量；(2)集中式的业务研讨形式和分散式的业务研讨形式；(3)有效抑制个性化差异、分模块组织专项研讨会。
8.6.4业务研讨：
在需求分析过程中，客户存在的最大问题就是提不出正确的需求，这表现为几种形式：(1)由于对软件不了解，客户提不出需求，不知道软件最终会做成什么样子。这类客户在需求讨论过程中，往往只能描述目前自己手工管理的方式是怎样的，不知道计算机会怎样管理。(2)能提出一些业务需求，但当软件做出来摆在自己面前时，需求就变了。这类客户，他们能熟练使用电脑，对信息化管理是清楚的。他们提出的业务需求从整体上应当是八九不离十的 。但是，由于没有实物，在软件中的一些具体操作并没有完全想清楚。(3)能非常详细地提出业务需求，甚至有时候该怎么做的提出来了。这类客户，参与过很多软件信息化建设，甚至有些还是软件开发的半专业人士。但是他们提出的业务需求过于具体 ，甚至怎样实现都说出来了，但这些有时候不是最佳设计方案、可能在技术上难于实现，甚至有些就是过于理想化而不可实现。解决办法:
(1)我们做需求分析，眼界不能仅仅停留在软件本身，应当更开阔一些，应当扩展到跟这个业务有关的那些领域知识中。
(2)在客户提出的所有原始需求中那些与业务实现有关的需求都是无效的需求，它们仅仅只能作为我们的一个参考。
(3)还有一些是技术难于实现或者根本就无法实现的需求，我们应当耐心地说服和引导客户，并给他提出一个更加合理的方案。
(4)需求分析不是一种简单的你说我记的收集活动，而是在大量业务分析与技术可行性分析基础上的分析活动。只有建立在这种分析基础上的软件研发，才能保证需求的正确与变更的可控。
8.6.5迭代：
在第一次的需求分析阶段，我们在一段时期内需要与客户进行反复地讨论，这个过程往往是这样一个反复循环的过程：需求捕获->需求整理->需求验证->再需求捕获······
(1)需求捕获:就是我们与客户在一起开研讨会，讨论需求的活动,客户可能会描述他们的业务流程，这时我们在纸上绘制简单的流程草图，及时地记录下来；客户在描述业务的同时，可能会反复提到一些业务名词，详细询问这些名词的含义，以及它们与其它名词的关系，用类图或者对象图绘制简单的草图；客户在描述业务的同时，还会提出今后的软件希望实现的功能，如能够展示某个报表、能够导出文件，以需求列表的形式记录下来。一个功能，在需求列表中会有多个需求，而每个需求应当能够用 1、2 句话，在 20 个字以内就可以描述清楚 。需求列表是客户提出的最最原始的需求，他不掺杂任何分析设计，是我们的每项功能必须实现的内容。
(2)需求整理:就是在需求研讨会后，需求分析人员对研讨内容的分析和整理的过程。首先，需求分析人员应当通过用例模型，划分整个系统的功能模块，以及各个模块的业务流程。用例模型分析是一个由粗到细的过程，这样一个过程也是符合人类认识世界的思维习惯的一个过程。最先，我们应当对整个系统绘制用例图，设计用例场景，并依次对这些用例进行用例描述、流程分析、角色分析等分析过程。当然，在整体用例分析的同时，我们还应当进行一个整体的角色分析，绘制一个角色分析图，进行一个流程分析，绘制一个流程分析图（可以是传统的流程图、UML 中的行动图，甚至一个简单的示意图，等等）,再在整体用例图的基础上，依次对每个用例绘制用例图。每个用例图中，会更细致地划分出多个用例，并依次进行用例描述、流程分析、角色分析等分析工作。如此这般地不断细化，直到我们认为需求已经描述清楚为止。
(3)领域模型 :是对用户业务领域中相关事物、相互关系、相互行为操作的描述，它是以对象图和类图的形式表达的。需求人员对领域模型的分析，对业务理解的深度，对日后软件的设计，以及软件的功能扩展、升级演化，都起到了至关重要的作用。
(4)需求验证:需求验证工作应当贯穿整个研发周期，并且在不同时期表现出不同的形式。首先，在需求分析阶段，需求验证工作表现为对需求理解是否正确的信息反馈。需求分析人员与客户再次坐在一起，一项一项描述我们对需求的整理和理解，客户则时不时地对一些问题进行纠正，或者更加深入地加以描述。我们则认真地记录，回来整理，并等待下一次的验证。在需求分析后期，我们还可以制作一些简单的原型，更加形象地描述我们对需求的理解，会使我们与客户的沟通更加顺畅。随后的设计开发阶段，我们则应当以迭代开发的形式进行。每开发完一个迭代周期，将开发的成果与客户反馈。这样做的结果是，客户可以及时地提出我们对需求理解的偏差，或者及时提出对我们设计不满意的地方，使我们存在的问题得到及时地发现与解决。问题及时的解决，使我们修复问题的代价得以降至最小。
8.6.6需求捕获:
经过深入分析我们会发现，从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求 ，和客户压根儿就没有想到的需求。
(1)什么是客户嘴中没有说出来的需求：并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。然而 ，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。如果采用被动的方式去仅仅记录客户说出来的需求，毫无疑问会遗失这部分需求，这就是为什么直到项目后期，软件被研发出来即将交付使用，客户才提出说这不是我想要的软件，并提出大量变更需求的原因。要求我们在需求分析的整个过程，不断进行业务领域知识的学习。在我做需求访谈的初期，我往往不是跟客户谈需求，而是先跟客户谈业务。你们是怎样操作的？都经过些什么流程？谁来完成这些操作的？为什么这样操作？注意，在所有这些问题中，最后一个问题是最重要的。客户业务领域中的所有操作、所有流程都是有它存在的意义的，它体现了其内部的原因与作用。多问为什么，可以让我们深入地理解这些领域知识 。站在客户的视角去思考问题，进而深入地理解客户为什么要提出他们的那些业务需求
(2)另一种就是客户压根儿没有想到的需求：在需求分析阶段，虽然客户压根儿没有想到，但需求分析人员是软件研发领域的专业人员，他们应当在深入理解业务领域与需求的基础上，通过分析提前发现这些需求。作为需求分析人员，他们应当站在客户的角度去思考，我们的软件应当设计成什么样子，每个需求的真实意图是什么。站在这个基础上，再运用专业知识去整理、分析与设计。我前面谈到，客户描述的最原始的需求是编写在需求列表中的，而经过需求分析人员的整理、分析与设计，经过用例分析、领域建模，最终形成产品需求说明书（或称为产品规格说明书）。先在一些非正式的场合单独跟客户聊，产生第一手资料，最后将这些需求在比较正式的场合，如各部门参加的业务讨论会、有用户代表参加的需求评审会、需求定稿签字确认会等等，以比较正式的形式讨论和确定下来。

九、总结

软件需求的获取和分析是软件系统开发中的一项重要的任务，正确获取软件需求的能力是软件技术人员所应掌握的基本技能。
通过阅读需求工程——软件建模与分析，我了解到在需求获取中有很多困难时普遍存在的，了解这些困难对更好的了解需求分析获取活动的复杂性有重要意义。需求获取中常见的困难有用户和开发人员的背景不同，立场不同。用户和开发人员具有不同的词汇集，所以在用户传递一个信息时，开发人员可能连用户表达信息所使用的概念也无法理解，更别提信息本身。默认知识是指表达者看来简单认为不值得专门进行理解或提及的知识。在用户和开发人员的交流中，默认知识是大量存在的，而且大都涉及业务的处理细节，所以不可能要求开发人员的交流中，默认知识是大量存在的。普通用户缺乏概括性，综合性的表达能力。为了解决这个问题，要求开发人员在与用户接触之前就先行确定获取的内容主题，然后设计具体的应用环境和场景条件，让用户在执行细节业务的场景中来描述问题和表达期望。用户越俎代庖。在系统开发中用户是业务的主导者，拥有具体业务的话语权；开发者是解决方案的主导者，拥有设计方案的话语权。但在实际情况中，开发者常错误的替客户“创造”需求，而用户也会越俎代庖地行使开发者进行方案设计的权利。越俎代庖地典型情况包括以下几种：1.用户提出的不是需求，而是解决方案。2.用户固执坚持某些特征和功能。需求获取中常见问题还包括缺乏用户参与。用户数量太多，选择困难。用户认识不足，不愿参与。用户情绪抵制，消极参与。没有明确的用户。需求获取活动至少做到以下几点：研究应用背景，建立初始的知识框架；根据获取需求的需要，采用必要获取方法和技巧；先行确定获取的内容和主题，设定场景；分析用户的高层目标，理解用户的意图；进行涉众分析，针对涉众的特点开展工作。