目录
[1.1 需求的层次](#1.1 需求的层次)
[1.2 质量功能部署](#1.2 质量功能部署)
[1.3 软件需求](#1.3 软件需求)
[3.1 需求分析的任务](#3.1 需求分析的任务)
[3.2 需求分析的方法](#3.2 需求分析的方法)
[4.1 结构化需求分析](#4.1 结构化需求分析)
[4.2 数据流图DFD](#4.2 数据流图DFD)
[4.3 状态转换图STD](#4.3 状态转换图STD)
[4.4 数据字典DD](#4.4 数据字典DD)
[五、 面向对象分析方法](#五、 面向对象分析方法)
[5.1 基本概念](#5.1 基本概念)
[5.2 面向对象的分析](#5.2 面向对象的分析)
[5.2.1 用例关系](#5.2.1 用例关系)
[5.2.2 类之间的关系](#5.2.2 类之间的关系)
一、软件需求概述
软件需求：
是指用户对系统在功能、行为、性能、设计约束等方面的期望。
是指用户解决问题或达到目标所需的条件或能力。
是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
1.1 需求的层次
软件需求包括3个不同的层次：业务需求、用户需求和功能需求(也包括非功能需求)。
- 业务需求：反映企业或客户对系统高层次的目标要求，通常来自项目投资人客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。
- 用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。
- 系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
- (1)功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能用户利用这些功能来完成任务，满足业务需要。
- (2)非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性(如可维护性、可靠性、效率等)和其他非功能需求。
- (3)设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。
1.2 质量功能部署
质量功能部署(QFD)是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。
- (1)常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
- (2)期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
- (3)意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能(但通常是软件开发人员很乐意赋予系统的技术特性)，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
1.3 软件需求
软件需求包含以下几方面的内容：
- (1)用户解决问题或达到目标所需条件或权能。
- (2)系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能。
- (3)一种反映上面(1)或(2)所述条件或权能的文档说明，即需求规格说明。
在统一过程(UP)中，需求按照"FURPS+"模型进行分类。"FURPS"具体指以下需求：
- (1)功能性(Functional)：特性、功能、安全性。
- (2)可用性(Usability)：人性化因素、帮助、文档。
- (3)可靠性(Reliability)：故障频率、可恢复性、可预测性。
- (4)性能(Performance)：响应时间吞吐量、准确性、有效性、资源利用率。
- (5)可支持(Sptability)：适应性、可维护性、国际化、可配置性。
"FURPS+"中的"+"是指一些辅助性的和次要的因素，用来强调各种不同的属性。如实现、接口、操作、包装、授权等。
二、需求获取
需求获取：是一个确定和理解不同的项目于系人的需求和约束的过程。
常见的需求获取方法包括：
- (1)用户访谈：1对1-3，有代表性的用户。其形式包括结构化和非结构化两种。
- (2)问卷调查：用户多，无法一一访谈。
- (3)采样：从种群中系统地选出有代表性的样本集的过程。样本数量=0.25*(可信度因子/错误率)2
- (4)情节串联板：一系列图片，通过这些图片来讲故事。
- (5)联合需求计划(JRP)：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。
- (6)需求记录技术：任务卡片、场景说明、用户故事、Volere白卡。
三、需求分析
需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。
3.1 需求分析的任务
- (1)绘制系统上下文范围关系图
- (2)创建用户界面原型
- (3)分析需求的可行性
- (4)确定需求的优先级
- (5)为需求建立模型
- (6)创建数据字典
- (7)使用QFD(质量功能部署)
3.2 需求分析的方法
3.2.1 PDOA
面向问题域的分析PDOA方法更多地强调描述，而较少强调建模。它的描述大致分为以下两个部分：
（1）关注问题域。用一个文档对含有的问题域进行相关的描述，并列出需要在该域中求解的问题列表也就是需求列表。只有这个文档是在分析时产生的。
（2）关注解系统(即系统实现)的待求行为。用一个文档对解系统的待求行为进行描述。该文档将在需求定义阶段完成。
在PDOA方法中，对整个过程有着清晰的定义：
（1）收集基本的信息并开发问题框架，以建立问题域的类型。
（2）在问题框架类型的指导下，进一步收集详细信息，并给出一个问题域相关特性的描述。
（3）基于以上两点，收集并用文档说明新系统的需求。
从上面的描述中可以看出，问题框架是PDOA的核心元素，是将问题域分为一系列相互关联的子域而一个子域可以是那些可能算是精选出来的问题域的一部分。
3.2.2 方法的对比
SA方法关注于功能的分层和分解，这非常符合人们自上而下、逐步分解问题直到可解决的思考方式。SA方法本身隐含着几个基本假设，即问题域是可定义的、问题域是有限的、通过有限的步骤总可以将复杂问题分解到可解决的程度。
OOA方法则遵循完全不同的思维方式，它基于抽象、信息隐藏、功能独立和模块化这些基本理念对系统进行分析。OOA方法建立的对象彼此之间通过接口来相互沟通，每传递一个消息即触发一个事件，并引起内部方法的执行。只有观测对象内部的时候，才能看到具体的属性和方法。否则，只能看到对象对外部开放的接口。
SA方法假定系统分析师理解问题域的全部，并且有能力正确地识别和分解问题。而OOA方法既不假定系统分析师理解问题域的全部，也不假定其能够建立正确的抽象对象，它只承诺一种可以持续"观测并理解"的方法，以及"观测后建立"的对象和现实世界的外在表象是一致的。
PDOA方法的特点是重新将重点定位在问题域和需求上，通过对问题域的分类，向系统分析师提供具体问题的相关指南，并且它将规格说明作为另外的任务处理，它的成果只是一份问题域的全面描述和一份需求列表而已。
四、结构化分析方法
结构化方法又称为面向功能的软件开发方法或面向数据流的软件开发方法。针对软件生存周期各个不同的阶段，有结构化分析、结构化设计和结构化编程等方法。
4.1 结构化需求分析
结构化特点：自顶向下，逐步分解，面向数据
三大模型：功能模型(数据流图)、行为模型(状态转换图)、数据模型(E-R图(实体-联系图))以及数据字典。
4.2 数据流图DFD
基本图形元素：外部实体、加工、数据存储、数据流。
数据流：由一组固定成分的数据组成，表示数据的流向。在DFD 中，数据流的流向必须经过加工。
加工：描述了输入数据流到输出数据流之间的变换，数据流图中常见的三种错误：
加工只有输入没有输出，称之为**"黑洞"。**
加工只有输出没有输入，称之为**"奇迹"。** 加工输入不足以产生输出，称之为**"灰洞"**。
数据存储：用来存储数据
外部实体(外部主体)：是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)。
数据流图的平衡原则
1.父图 ( 上层数据流图 ) 与 子图 ( 下层数据流图 ) 平衡
个数一致：两层数据流图中的数据流个数一致
方向一致：两层数据流图中的数据流方向一致
2.子图内部的平衡
加工只有输入没有输出，称之为**"黑洞"。**
加工只有输出没有输入，称之为**"奇迹"。**
加工输入不足以产生输出，称之为**"灰洞"**。
4.3 状态转换图STD
状态是任何可以被观察到的系统行为模式，每个状态代表系统的一种行为模式。在STD中，用圆形框或椭圆框表示状态，通常在框内标上状态名。状态规定了系统对事件的响应方式。系统对事件的响应可以是做一个(或一系列)动作，也可以是仅仅改变系统本身的状态。STD描述了系统如何在各种状态之间移动。
4.4 数据字典DD
数据流图描述了系统的分解，但没有对图中各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。
数据字典中一般有6类条目，分别是数据元素(数据最小组成单位)、数据结构(数据元素之间的关系)、数据流、数据存储、加工逻辑和外部实体。
| 符号 | 含义 | 举例与说明 |
|---|---|---|
| = | 被定义为 | x=a，表示x等于a |
| + | 与 | x=a+b，表示x由a和b组成 |
| [...,...]或[...|...] | 或 | x=[a,b]，x=[a|b],表示x由a或由b组成 |
| {...} | 重复 | x={a}，表示x由0个或多个a组成 |
| (...) | 可选 | x=(a)，表示a可在x中出现，也可以不出现 |
数据字典具有以下作用：
- (1)按各种要求列表。可以根据数据字典，把所有数据条目按一定的顺序全部列出，保证系统设计时不会遗漏。
- (2)相互参照，便于系统修改。
- (3)由描述内容检索名称。
- (4)一致性检验和完整性检验。
五、 面向对象分析方法
面向对象的分析方法 (Object-Oriented Analysis,OOA), 是在一个系统的开发过程中进行了系统业务调查以后，按照面向对象的思想来分析问题。 OOA 与结构化分析有较大的区别。OOA 所强调的是在系统调查资料的基础上，针对O O 方法所需要的素材进行的归类分析和整理，而不是对管理业务现状和方法的分析。
OOA 模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。在这种方法中定义了两种对象类之间的结构，一种称为分类结构；另一种称为组装结构。分类结构就是所谓的一般与特殊的关系。组装结构则反映了对象之间的整体与部分的关系。
5.1 基本概念
对象：由数据及其操作所构成的封装体，是系统中用来描述客观事务的一个实体，是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。
类 ：现实世界中实体的形式化描述，类将该实体的属性(数据)和操作(函数)封装在一起。对象是类的实例，类是对象的模板。类可以分为三种：实体类、接口类(边界类)和控制类。
实体类 的对象表示现实世界中真实的实体 ，如人、物等。
接口类(边界类) 的对象为用户提供一种与系统合作交互的方式 ，分为人和系统两大类，其中人的接口可以是显示屏窗口、Web 窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。
控制类 的对象用来控制活动流，充当协调者。
抽象：通过特定的实例抽取共同特征以后形成概念的过程。它强调主要特征，忽略次要特征。一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。
封装：是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象对数据的访问或修改只能通过对象对外提供的接口进行。
继承：表示类之间的层次关系(父类与子类)，这种关系使得某类对象可以继承另外一类对象的特征，又可分为单继承和多继承。
多态：不同的对象收到同一个消息时产生完全不同的结果。包括参数多态(不同类型参数多种结构类型)、包含多态(父子类型关系)、过载多态(类多态似于重载，一个名字不同含义)、强制多态(强制类型转换)四种类型。由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在低层。
接口：描述对操作规范的说明，其只说明操作应该做什么，并没有定义操作如何做。
消息：体现对象间的交互，通过它向目标对象发送操作请求。
**覆盖：**子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法。
函数重载：与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。
java
public int add(int x){
return x+10;
}
public int add(int x,int y){
return x+y;
}**绑定：**是一个把过程调用和响应调用所需要执行的代码加以结合的过程。在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。
5.2 面向对象的分析
面向对象的分析是为了确定问题域、理解问题。包含五个活动：认定对象组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。
面向对象需求建模:
5.2.1 用例关系
泛化代表一般与特殊的关系。在用例泛化中，子用例表示父用例的特殊形式。子用例从父用例处继承行为和属性，还可以添加行为或覆盖、改变已继承的行为。当系统中具有一个或多个用例是较一般用例的特化时，就使用用例泛化。泛化用带空心箭头的实线表示，箭头的方向由子用例指向父用例。
**包含(include)**关系是一种依赖联系，是指一个基本用例的行为包括了另一个用例。用一条从基本用例指向被包含的用例的虚箭头线表示，并在箭头上标识<<include>>。包含关系典型的应用就是复用，有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；
扩展关系( Extension**)**就是将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。
5.2.2 类之间的关系
依赖：一个事物的语义依赖于另一个事物的语义的变化而变化。
关联：是一种结构关系，描述了一组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。
组合是一种整体与部分的关系。但部分不能离开整体而单独存在，组合关系是关联关系的一种，是比聚合关系还要强的关系。例如鸟是整体，翅膀是部分->鸟死了，翅膀也就没用了。
聚合是一种整体与部分的关系。且部分可以离开整体而单独存在。聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。例如茶具，杯子和茶壶可以聚合成一套茶具，杯子也可以单独拿出来喝水。
泛化：一般/特殊的关系，子类和父类之间的关系。
实现：一个类元指定了另一个类元保证执行的契约。
