信息系统中的需求分析

需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是一件看上去很简单，做起来却很难的事情。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌（真实，深有同感😶） 。因此，需求获取只有与用户的有效合作才能成功。常见的需求获取方法包括++用户访谈、问卷调查、采样、情节串联板、联合需求计划++等。

2.2 需求分析

在需求获取阶段获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地方，也有矛盾的地方，这样的要求是不能作为软件设计基础的。

一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

++需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目于系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。++需求分析的关键在于对问题域的研究与理解。

为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。

使用结构化分析(Structured Analysis，SA)方法进行需求分析，其建立的模型的核心是数据字典。围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。在实际工作中，**一般使用实体关系图 (E-R 图)表示数据模型，用数据流图 (DataFlow Diagram，DFD)表示功能模型，用状态转换图(State Transform Diagram，STD)表示行为模型。**E-R 图主要描述实体、属性，以及实体之间的关系；DFD 从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；STD 通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为,指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。

面向对象的分析(Object-Oriented Analysis，OOA)的基本任务是运用面向对象的(ObjectOriented，OO)方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的 OOA 模型及其详细说明。OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模:分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型)，以及它们如何保持通信，实现系统行为(动态模型)。

2.3 需求规格说明书编制

软件需求规格说明书(Software Requirement Specification，SRS)是需求开发活动的产物,编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS 是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。

在国家标准GB/T 8567《计算机软件文档编制规范》中，提供了一个SRS的文档模板和编写指南，其中规定SRS 应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。

另外，国家标准GB/T9385《计算机软件需求说明编制指南》也给出了一个详细的SRS写作大纲，由于该标准年代久远，一些情况已经与现实不符，可以考虑作为SRS 写作的参考之用。

2.4 需求验证与确认

++资深软件工程师都知道，当以SRS 为基础进行后续开发工作，如果在开发后期或在交付系统之后才发现需求存在问题，这时修补需求错误就需要做大量的工作。++相对而言，在系统分析阶段，检测SRS 中的错误所采取的任何措施都将节省相当多的时间和资金。因此，有必要对于SRS的正确性进行验证，以确保需求符合良好特征。

需求验证与确认活动内容包括:

SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征;
SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的;
需求是完整的和高质量的;
需求的表示在所有地方都是一致的;
需求为继续进行系统设计、实现和测试提供了足够的基础。

在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS 进行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。需求的遗漏和错误具有很强的隐蔽性，仅仅通过阅读SRS，通常很难想象在特定环境下系统的行为。只有在业务需求基本明确，用户需求部分确定时，同步进行需求测试，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。

建议需求确认时，需求方方在场、或与需求方直接确认。

3、UML

统一建模语言(UnifedModeling Language，UML)是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持00A和00D(Object-Oriented Design，面向对象设计)，还支持从需求分析开始的软件开发的全过程。从总体上来看，UML 的结构包括构造块、规则和公共机制三个部分。

部分	说明
构造块	UML有三种基本的构造块，分别是事物(Thing)、关系(Relationship)和图(Diagram)。物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合
规则	规则是构造块如何放在一起的规定，包括为构造块命名:给一个名字以特定含义的语境，即范围:怎样使用或看见名字，即可见性;事物如何正确、一致地相互联系，即完整性:运行或模拟动态模型的含义是什么，即执行
公共机制	分类(通用划分)和扩展机制四种公共机制是指达到特定目标的公共 UML 方法，主要包括规格说明(详细说明)、修饰、公共

1) UML中的事物

UML中的事物也称为建模元素，包括结构事物(Structural Things)、行为事物(BehavioralThings，也称动作事物)、分组事物(Grouping Things)和注释事物(Annotational Things，也称注解事物)。这些事物是UML模型中最基本的OO构造块。

2) UML中的关系

UML用关系把事物结合在一起，主要有四种关系，分别为:

依赖(Dependency):依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
关联描述一组对象之间连接的结构关系。关联(Association):
泛化(Generalization):泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
实现(Realization):实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

3) UML 2.0中包括14种图

4) UML视图

UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息，包括5个系统视图:

逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。
部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
用例视图：用例视图是最基本的需求分析模型。另外，UML还允许在一定的阶段隐藏模型的某些元素，遗漏某些元素，可不保证模型的完整性，但模型逐步地要达到完整和一致。