软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。 根据IEEE的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
1.需求的层次
简单地说，软件需求就是系统必须完成的事以及必须具备的品质。需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。
质量功能部署(QualityFunctionDeployment,QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
2.需求的过程
需求过程主要包括需求获取、需求分析、需求规格说明书编制、需求验证与确认等。
1)需求获取
需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。需求获取是一件看上去很简单，做起来却很难的事情。需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。因此，需求获取只有与用户的有效合作才能成功。
常见的需求获取方法包括用户访谈、问卷调查、采样、情节串联板、联合需求计划等。
2)需求分析
在需求获取阶段获得的需求是杂乱的，是用户对新系统的期望和要求，这些要求有重复的地方，也有矛盾的地方，这样的要求是不能作为软件设计基础的。
一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。 需求分析对已经获取到的需求进行提炼、分析和审查，以确保所有的项目干系人都明白其含义并找出其中的错误、遗漏或其他不足的地方。
需求分析的关键在于对问题域的研究与理解。为了便于理解问题域，现代软件工程方法所推荐的做法是对问题域进行抽象，将其分解为若干个基本元素，然后对元素之间的关系进行建模。
使用结构化分析(StructuredAnalysis,SA)方法进行需求分析，其建立的模型的核心是数据字典。
围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型(也称为状态模型)。在实际工作中，一般使用实体关系图(E-R图)表示数据模型，用数据流图(DataFlowDiagram,DFD)表示功能模型，用状态转换图(StateTransformDiagram,STD)表示行为模型。
E-R图主要描述实体、属性，以及实体之间的关系；DFD从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能；STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作(例如，处理数据等)。
3.面向对象的分析
面向对象的分析(Object-OrientedAnalysis,OOA)的基本任务是运用面向对象的(Object-Oriented,00)方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责，以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。
OOA模型包括用例模型和分析模型，用例是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模；分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型),以及它们如何保持通信，实现系统行为(动态模型)。
3)需求规格说明书编制
软件需求规格说明书(SoftwareRequirementSpecification,SRS)是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。 在国家标准GB/T8567《计算机软件文档编制规范》中，提供了一个SRS的文档模板和编写指南，其中规定SRS应该包括范围、引用文件、需求、合格性规定、需求可追踪性、尚未解决的问题、注解和附录。 另外，国家标准GB/T9385《计算机软件需求说明编制指南》也给出了一个详细的SRS写作大纲，由于该标准年代久远，一些情况已经与现实不符，可以考虑作为SRS写作的参考之用。
4)需求验证与确认
资深软件工程师都知道，当以SRS为基础进行后续开发工作，如果在开发后期或在交付系统之后才发现需求存在问题，这时修补需求错误就需要做大量的工作。相对而言，在系统分析阶段，检测SRS中的错误所采取的任何措施都将节省相当多的时间和资金。因此，有必要对于SRS的正确性进行验证，以确保需求符合良好特征。需求验证与确认活动内容包括：
●SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征；
●SRS中的软件需求是从系统需求、业务规格和其他来源中正确推导而来的；
●需求是完整的和高质量的；
●需求的表示在所有地方都是一致的；
●需求为继续进行系统设计、实现和测试提供了足够的基础。
在实际工作中，一般通过需求评审和需求测试工作来对需求进行验证。需求评审就是对SRS进行技术评审，SRS的评审是一项精益求精的技术，它可以发现那些二义性的或不确定性的需求，为项目干系人提供在需求问题上达成共识的方法。
需求的遗漏和错误具有很强的隐蔽性，仅仅通过阅读SRS,通常很难想象在特定环境下系统的行为。只有在业务需求基本明确，用户需求部分确定时，同步进行需求测试，才可能及早发现问题，从而在需求开发阶段以较低的代价解决这些问题。
4.统一建模语言
统一建模语言(Unified Modeling Language,UML)是一种定义良好、易于表达、功能强大且普遍适用的建模语言，它融入了软件工程领域的新思想、新方法和新技术，它的作用域不限于支持OOA和OOD(Object-OrientedDesign,面向对象设计),还支持从需求分析开始的软件开发的全过程。从总体上来看，UML的结构包括构造块、规则和公共机制三个部分，如表5-1所示。
部分 | 说明 |
构造块 | UML有三种基本的构造块，分别是事物(Thing)、关系(Relationship)和图(Diagram)。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合 |
规则 | 规则是构造块如何放在一起的规定，包括为构造块命名；给一个名字以特定含义的语境，即范围；怎样使用或看见名字，即可见性；事物如何正确、一致地相互联系，即完整性：运行或模拟动态模型的含义是什么,即执行 |
公共机制 | 公共机制是指达到特定目标的公共UML方法，主要包括规格说明(详细说明)、修饰、公共分类(通用划分)和扩展机制四种 |
1)UML中的事物 UML中的事物也称为建模元素，包括结构事物(StructuralThings)、行为事物(BehavioralThings,也称动作事物)、分组事物(GroupingThings)和注释事物(AnnotationalThings,也称注解事物)。这些事物是UML模型中最基本的OO构造块，如表5-2所示。
建模元素 | 说明 |
结构事物 | 结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。UML有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点 |
行为事物 | 行为事物是UML模型中的动态部分，代表时间和空间上的动作。UML有两种主要的行为 事物。第一种是交互(内部活动),交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列 出，包括消息、动作次序(消息产生的动作)、连接(对象之间的连接);第二种是状态机，状态机由一系列对象的状态组成 |
分组事物 | 分组事物是UML模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。UML只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统运行阶段 |
注释事物 | 注释事物是UML模型的解释部分 |
2)UML中的关系 UML用关系把事物结合在一起，主要有四种关系，分别为：
●依赖(Dependency): 依赖是两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义。
●关联(Association): 关联描述一组对象之间连接的结构关系。
●泛化(Generalization): 泛化是一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象。
●实现(Realization): 实现是类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。
3)UML2.0中的图 包括14种图，如表5-3所示。
种类 | 说明 |
类图(ClassDiagram) | 类图描述一组类、接口、协作和它们之间的关系。在00系统的建模中，最常见的图就是类图。类图给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图 |
对象图(ObjectDiagram) | 对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的 |
构件图(ComponentDiagram) | 构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体 |
组合结构图(CompositeStructureDiagram) | 组合结构图描述结构化类(例如，构件或类)的内部结构，包 括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容 |
用例图(UseCaseDiagram) | 用例图描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行为进行组织和建模时是非常重要的 |
种类 | 说明 |
顺序图(SequenceDiagram,也称序列图) | 顺序图是一种交互图(InteractionDiagram),交互图展现了一种交互，它由一组对象或参与者以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图 |
通信图(CommunicationDiagram) | 通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之 间的组织结构(关系)。在UML1.X版本中，通信图称为协作图(CollaborationDiagram) |
定时图(TimingDiagram,也称计时图) | 定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序 |
状态图(StateDiagram) | 状态图描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模 |
活动图(ActivityDiagram) | 活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程 |
部署图(DeploymentDiagram) | 部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图 |
制品图(ArtifactDiagram) | 制品图描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构件 |
包图(PackageDiagram) | 包图描述由模型本身分解而成的组织单元，以及它们之间的依赖关系 |
交互概览图(InteractionOverviewDiagram) | 交互概览图是活动图和顺序图的混合物 |
4)UML视图 UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息，包括5个系统视图：
●逻辑视图：逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
●进程视图：进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
●实现视图：实现视图对组成基于系统的物理代码的文件和构件进行建模。
●部署视图：部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。
●用例视图：用例视图是最基本的需求分析模型。 另外，UML还允许在一定的阶段隐藏模型的某些元素，遗漏某些元素，可不保证模型的完整性，但模型逐步地要达到完整和一致。
4.面向对象分析
OOA的基本任务是运用OO方法，对问题域进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域和系统功能所需的类和对象，定义它们的属性和职责以及它们之间所形成的各种联系。最终产生一个符合用户需求，并能直接反映问题域和系统功能的OOA模型及其详细说明。 OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素，这也是OOA和OOD的区别之所在。OOA的任务是“做什么”, OOD的任务是“怎么做”。 面向对象分析阶段的核心工作是建立系统的用例模型与分析模型。
1)用例模型 结构化分析(StructuredAnalysis,SA)方法采用功能分解的方式来描述系统功能，在这种表达方式中，系统功能被分解到各个功能模块中，通过描述细分的系统模块的功能来达到描述整个系统功能的目的。
采用SA方法来描述系统需求，很容易混淆需求和设计的界限，这样的描述实际上已经包含了部分的设计在内。
因此，系统分析师常常感到迷惑，不知道系统需求应该详细到何种程度。
一个极端的做法就是将需求详细到概要设计，因为这样的需求描述既包含了外部需求也包含了内部设计。
SA方法的另一个缺点是分割了各项系统功能的应用环境，从各项功能项入手，很难了解到这些功能项如何相互关联来实现一个完整的系统服务。
从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，这就是用例方法的基本思想。用例方法是一种需求合成技术，先获取需求并记录下来，然后从这些零散的要求和期望中进行整理与提炼，从而建立用例模型。
在00A方法中，构建用例模型一般需要经历四个阶段，分别是识别参与者、合并需求获得用例、细化用例描述和调整用例模型，如表5-4所示。其中前三个阶段是必须的。
5.分析模型
构建用例模型的阶段
阶段 | 说明 |
识别参 与者 | 参与者是与系统交互的所有事物，该角色不仅可以由人承担，还可以是其他系统和硬件设备， 甚至是系统时钟。参与者一定在系统之外，不是系统的一部分。可以通过下列问题来帮助系统 分析师发现系统的参与者：谁使用这个系统，谁安装这个系统，谁启动这个系统，谁维护这个 系统，谁关闭这个系统，哪些(其他的)系统使用这个系统，谁从这个系统获取信息，谁为这 个系统提供信息，是否有事情自动在预计的时间发生 |
合并需 求获得 用例 | 参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。①要将获取到的需求分配给与其相关的参与者，以便可以针对每个参与者进行工作，而无遗漏：②在合并之前，要明确为什么合并，知道了合并的目的，才可能选择正确的合并操作：③将识别到的参与者和合并生成的用例，通过用例图的形式整理出来，以获得用例模型的框架 |
细化用例描述 | 用例建模的主要工作是书写用例规约(UseCaseSpecification),而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流(基本事件流和扩展事件流)和后置条件等，其他的还可以包括非功能需求和用例优先级等 |
调整用例模型 | 在建立了初步的用例模型后，还可以利用用例之间的关系来调整用例模型。用例之间的关系主要有包含、扩展和泛化。利用这些关系，把一些公共的信息抽取出来，以便于复用，使得用例模型更易于维护。 ●包含关系：当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例 ●扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰 ●泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系 |
前文从用户的观点对系统进行了用例建模，但捕获了用例并不意味着分析的结束，还要对需求进行深入分析，获取关于问题域本质内容的分析模型。
分析模型描述系统的基本逻辑结构，展示对象和类如何组成系统(静态模型),以及它们如何保持通信，实现系统行为(动态模型)。
为了使模型独立于具体的开发语言，系统分析师需要把注意力集中在概念性问题上而不是软件技术问题上，这些技术的起点就是领域模型。
领域模型又称为概念模型或简称为域模型，也就是找到那些代表事物与概念的对象，即概念类。
概念类可以从用例模型中获得灵感，经过完善将形成分析模型中的分析类。每一个用例对应一个类图，描述参与这个用例实现的所有概念类，而用例的实现主要通过交互图来表示。
例如，用例的事件流会对应产生一个顺序图，描述相关对象如何通过合作来完成整个事件流，复杂的备选事件流也可以产生一个或多个顺序图。
所有这些图的集合就构成了系统的分析模型。
建立分析模型的过程大致包括定义概念类，确定类之间的关系，为类添加职责，建立交互图等，其中有学者将前三个步骤统称为类-责任-协作者(Class-Responsibility-Collaborator,CRC)建模。
类之间的主要关系有关联、依赖、泛化、聚合、组合和实现等，它们在UML中的表示方式，如表5-5所示。
关系 | 图例 | 描述 |
关联 | 类A类B | 关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联体现的是对象实例之间的关系，而不表示两个类之间的关系。其余的关系涉及类元自身的描述，而不是它们的实例。对于关联关系的描述，可以使用关联名称、角色、多重性和导向性来说明 |
依赖 | 类A类B | 两个类A和B,如果B的变化可能会引起A的变化，则称类A 依赖于类B。依赖可以由各种原因引起，例如，一个类向另一个类发送消息，一个类是另一个类的数据成员，一个类是另一个类的某个操作参数等 |
泛化 | 子类父类 | 泛化关系描述了一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系。继承关系是泛化关系的反关系，也就是说，子类继承了父类，而父类则是子类的泛化 |
共享聚集 | 部分类整体类 | 共享聚集关系通常简称为聚合关系，它表示类之间的整体与部分的关系，其含义是“部分”可能同时属于多个“整体”,“部分”与“整体”的生命周期可以不相同。例如，汽车和车轮就是聚合关系，车子坏了，车轮还可以用；车轮坏了，可以再换一个新的 |
组合聚集 | 部分类整体类 | 组合聚集关系通常简称为组合关系，它也是表示类之间的整体与 部分的关系。与聚合关系的区别在于，组合关系中的“部分”只 能属于一个“整体”,“部分”与“整体”的生命周期相同，“部 分”随着“整体”的创建而创建，也随着“整体”的消亡而消 亡。例如，一个公司包含多个部门，它们之间的关系就是组合关系。公司一旦倒闭，也就没有部门了 |
实现 | 类A类B | 实现关系将说明和实现联系起来。接口是对行为而非实现的说明，而类中则包含了实现的结构。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作 |
小结：
1.需求分析 2.需求的层次 3.需求的过程 需求获取、需求分析、编制SRS、需求验证与确认。1.UML 2.UML事务 3.UML关系 4.UML2.0图 5.OOA 6.用例模型 7.分析模型
