第四章 需求工程

一、需求工程概述（⭐）

1、什么是软件需求

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。

软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

 

二、需求分类（⭐⭐）

1、需求的层次

（i）业务需求：是指反应企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。通过业务需求可以确定项目视图和范围，为以后的开发工作奠定了基础。
（ii）用户需求：描述的是用户的具体目标，或用户要求系统必须能完成的任务。也就是说，用户需求描述了用户能使用系统来做些什么。
（iii）系统需求：是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。功能需求也称为行为需求，它规定了开发人员必须在系统种实现的软件功能，用户利用这些功能来完成任务，满足业务要求。非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性和其他非功能需求。设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明。

2、QFD

质量功能部署QFD是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。QFD将软件需求分为三类：
（i）常规需求（基本需求）：用户认为系统应该做到的功能或性能，实现越多用户会越满意。
（ii）期望需求：用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
（iii）兴奋需求（意外需求）：是用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

3、PIECES框架

PIECES框架是系统非功能性需求分类的技术。
性能（Preformance）：性能用于描述企业当前的运行效率，可以分析当前业务的处理速度。
信息（Information）：信息和数据指标用于描述业务数据的输入、输出以及处理方面存在的各种问题。
经济（Economics）：经济指标主要是从成本和收益的角度分析企业当前存在的问题。
控制（Control）：提高信息系统的安全和控制水平。
效率（Efficiency）：提高企业的人、财、物等的使用效率。
服务（Service）：提高企业对客户、供应商、合作伙伴、顾客等的服务质量。

三、需求开发-需求获取方法（⭐⭐⭐）【案例/论文】

（1）用户访谈：1对1-3，有代表性的用户。用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。用户访谈是通过1对1（或1对2，1对3）的形式与用户面对面进行沟通，以获取用户需求。用户访谈具有良好的灵活性，有较宽广的应用范围。但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。

（2）问卷调查：用户多，无法一一访谈。与用户访谈相比，问卷调查可以在短时间内，以低廉的代价从大量的回答中收集数据；问卷调查允许回答者匿名填写，大多数用户可能会提供真实信息；问卷调查的结果比较好整理和统计。问卷调查最大的不足就是缺乏灵活性。

（3）现场观摩：针对较为复杂的流程和操作。想获取系统某些较为复杂的流程和操作过程，则现场观摩方法比较合适。对于一些较为复杂的流程和操作而言，是比较难以用语言和文字进行表达的，对于这种情况，可以采用到客户的工作现场，一边观察，一边听客户讲解，从而更直观的了解客户需求。

（4）联合需求计划（JRP）：高度组织的群体会议，各方参与，成本较高。为了提高需求获取的效率，越来越多的企业倾向于使用小组工作会议来代替大量独立的访谈。联合需求计划（Joint Requirement Planning，JRP）是一个通过高度组织的群体会议来分析企业内的问题并获取需求的过程，它是联合应用开发（Joint Application Development，JAD）的一部分。

（5）情节串联板：一系列图片，通过这些图片来讲故事。

（6）收集资料：把与系统有关的、对系统开发有益的信息收集起来。

（7）参加业务实践：有效地发现问题的本质和寻找解决问题的办法。

（8）阅读历史文档：对收集数据性的信息较为有用。

（9）抽样调查：降低成本。采样是指从种群中系统地选出有代表性的样本集的过程，通过认真研究所选出的样本集，可以从整体上揭示种群的有用信息。对于信息系统的开发而言，现有系统的文档（文件）就是采样种群。当开始对一个系统做需求分析时，查看现有系统的文档是对系统有初步了解的最好方法。但是，系统分析师应该查看哪些类型的文档，当文档的数据庞大，无法一一研究时，就需要使用采样技术选出有代表性的数据。抽样能够提高需求获取效率，但抽样往往是由系统分析师来抽的，所以会受到他的主观因素影响。
样本大小＝ɑ*（可信度系数/可接受的错误）2
注： ɑ一般取0.25

 

四、结构化需求分析方法（⭐⭐）【案例/论文】

1、结构化需求分析过程

2、数据流图基本概念

3、数据平衡原则-异常现象

（1）父图与子图之间的平衡
（2）子图内平衡
（i）黑洞：一个加工只有输入数据流而无输出数据流。
（ii）奇迹：一个加工只有输出数据流而无输入数据流。
（iii）灰洞：若一个加工的输入数据流无法通过加工产生输出流。

4、数据流图题答题技巧

（1）详细分析试题说明
（2）利用数据平衡原则
（3）补充实体

实体可能是：
（i）人物角色：如 客户、管理员、主管、经理、老师、学生
（ii）组织机构：如 银行、供应商、慕捐机构
（iii）外部系统：如 银行系统、工资系统、后台数据库（当要开发的是中间件时）
（4）补充存储：存储的文字方面特征：“**文件”“**表”“**库” “**清单” “**档案”
（5）补充数据流
（i）数据平衡原则
顶层图与0层图对比，是否有顶层图有，但0层图无的数据流，或反之。
检查图中每个加工，是否存在只有入没有出，或只有出没有入，或根据输入的数据无法产生对应的输出的情况。
（ii）按题目说明与图进行匹配

说明中的每一句话，都能与图中有对应关系，当把说明中的实体与数据流标识出来之后，容易缩小对应范围，找出纰漏。
（6）补充加工名
加工是用于处理数据流的，所以要补充加工名，可以把该加工涉及到的数据流，在说明中标识出来，再在数据流名称所在的句子中，找“动词+名词”的结构，分析是否可作为加工。
“动词+名词”如：生成报告，发出通知，批改作业，记录分数，当然这只是普遍情况，也有例外，如物流跟踪、用户管理

5、STD-状态转换图

6、E-R图-数据库设计解题技巧

（1）补充E-R图
（i）根据题干描述
1）找实体
实体一般为名词形式，实体是现实世界中可以区别于其他对象的“事件”或“物体”。在E-R图中可根据相关实体间的联系，补充缺失的实体。实体以矩形表示，在矩形框内写明实体名。
2）找联系
在E-R模型中，联系用菱形表示，通常菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标注上联系的类型（1:1、1:n、n:m）。根据题干描述找出对应实体间存在的联系。

3）三元联系
对于题干描述中，一个联系涉及到3个实体的情况，我们称之为三元联系。以菱形表示联系，以无向边分别连接对应的实体。

（2）补充关系模式
（i）根据题干描述，找遗漏属性；
（ii）题干描述已完善，根据联系归并找参照属性，通常将联系归并到实体端时，需要补充另一端实体的主键，如果联系本身存在属性，归并后也需要列出。

（3）判断主键和外键
（i）找主键
1）候选码/候选键：若关系中的某一属性或属性组的值能唯一地标识一个元组，则城管属性或属性组为候选码。
2）主码/主键：选择一个候选码作为主键。如果题干描述明确指出可以唯一标识元组的属性，则可以直接判断为主键。
3）全码：关系模型的所有属性组是这个关系模式的候选码，称为全码。
（ii）找外键：如果关系模式R中的属性或属性组非该关系的码，但它是其他关系的码，那么该属性集对关系模式R而言是外码。

（4）扩展题型
（i）补充实体
根据题干描述添加实体，注意新实体与其他实体之间的联系。
（ii）完整性约束相关
了解主键、外键相关的概念，根据题干，做出相关判断。
（iii）规范化理论相关
了解规范化理论相关的概念，对于规范化程度没有达到3NF时，一般认为会存在数据冗余、修改异常、插入异常、删除异常问题。对于相关问题的解决，一般是将表进行模式分解，从而提高其规范化程度至3NF。
（iv）关于反规范化理论的考查。
（v）关于分布式数据库考查。
（vi）关于事务、缓存等技术结合考查。

五、面向对象需求分析（⭐⭐⭐⭐⭐）【案例/论文】

1、面向对象基本概念

对象：属性（数据）+方法（操作）+对象ID
类（实体类/控制类/边界类）
继承与泛化：复用机制
封装：隐藏对象的属性和实现细节,仅对外公开接口
多态：不同对象收到同样的消息产生不同的结果
接口：一种特殊的类，他只有方法定义没有实现
重载：一个类可以有多个同名而参数类型不同的方法
消息和消息通信：消息是异步通信的

2、UML图概念

UML包括两组公共分类，分别是类与对象（类表示概念，而对象表示具体的实体）、接口与实现（接口用来定义契约，而实现就是具体的内容）
（1）结构事物。
结构事物在模型中属于最静态的部分，代表概念上或物理上的元素。UML有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点。类是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口；接口是指类或构件提供特定服务的一组操作的集合，接口描述了类或构件的对外的可见的动作；协作定义了交互的操作，是一些角色和其它事物一起工作，提供一些合作的动作，这些动作比事物的总和要大；用例是描述一系列的动作，产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的；活动类的对象有一个或多个进程或线程。活动类和类很相似，只是它的对象代表的事物的行为和其他事物是同时存在的；构件是物理上或可替换的系统部分，它实现了一个接口集合；节点是一个物理元素，它在运行时存在，代表一个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
（2）行为事物：行为事物是UML 模型中的动态部分，代表时间和空间上的动作。UML有两种主要的行为事物。第一种是交互（内部活动），交互是由一组对象之间在特定上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序（消息产生的动作）、连接（对象之间的连接）；第二种是状态机，状态机由一系列对象的状态组成。
（3）分组事物。分组事物是UML 模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。UML只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统运行阶段。
（4）注释事物。注释事物是UML模型的解释部分。

3、UML图分类

（1）类图（class diagram）:类图描述一组类、接口、协作和它们之间的关系。
（2）对象图（object diagram）:对象图描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。
（3）构件图（component diagram）。构件图描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表示系统的静态设计实现视图。对于由小的部件构建大的系统来说，构件图是很重要的。构件图是类图的变体。一个封装的类和它的接口。
（4）部署图（deployment diagram）。部署图描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常一个节点包含一个或多个部署图。软硬件之间映射。
（5）制品图：系统的物理结构。
（6）包图，包的图标像是一个带标签的文件夹，包的基本思想是把共同工作的元素放到一个文件夹中。例：多个类或构件组成了一个子系统，就可以将它们放到一个包中。
（7）组合结构图。
（8）用例图：系统与外部参与者的交互。
（9）顺序图（sequence diagram，序列图）：顺序图是一种交互图（interaction diagram），它强调对象之间消息发送的顺序，同时显示对象之间的交互。强调按时间顺序。
（10）通信图（communication diagram）。协作图。通信图也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构（关系）。
（11）定时图：强调实际时间。用于展示交互过程中的真实时间信息，具体描述对象状态变化的时间点以及维持特定状态的时间段。
（12）交互概览图。
（13）状态图（state diagram）。是对类描述的补充。用于展现此类对象所具有的可能状态，以及某些事件发生时其状态转移情况。强调状态转换变迁。
（14）活动图（activity diagram）。活动图是一种特殊的状态图。活动图描述一个操作中要进行的各项活动的执行流程。同时，也常被用来描述一个用例的处理流程或者某种交互流程。活动图将进程或其他计算结构展示为计算内部一步步的控制流和数据流。它强调对象间的控制流程。

4、UML图关系

（1）用例关系包括：包含关系、扩展关系、泛化关系
（i）包含关系：其中这个提取出来的公共用例称为抽象用例，而把原始用例称为基本用例或基础用例系：当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。
（ii）扩展关系：如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。
（iii）泛化关系：当多个用例共同拥有一种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。

（2）类图/对象图关系：
（i）依赖关系：一个事物发生变化影响另一个事物。
（ii）泛化关系：特殊/一般关系
（iii）关联关系：描述了一组链，链是对象之间的连接。
•聚合关系：整体与部分生命周期不同。
•组合关系：整体与部分生命周期相同。
（iv）实现关系：接口与类之间的关系

5、常见UML图考查

（1）用例图常见考查形式：

（i）补充参与者：参与者一般为外部实体，可以是人，也可以是外部系统。
（ii）补充用例：根据题干描述补充缺失的用例，在补充过程中需要参照用例图中用例间的关系。（用例名从题干中直接获取或提炼）
（iii）分析用例间的关系
（iv）其他：可能会出现其他题型，比如添加新的用例等。
（2）类图/对象图常见考查形式（常与其他UML图结合考查）

（i）补充类名/对象名：一般为名词，来源于题干描述。
（ii）补充多重度：多重度体现类与类或对象与对象之间的对应关系，有0…1，1..1，1…*/n，*…*/m…n。
（iii）分析类与类或对象与对象之间的关系。

（3）顺序图常见考查形式

（i）补充类名/对象名
（ii）补充消息

（4）活动图常见考查形式

（i）补充动作名称
（ii）补充监护表达式
（iii）分析并发关系
（iv）活动图与状态图对比，活动图与进程图关系。

（5）状态图常见考查形式

（i）补充状态
（ii）补充触发事件、监护条件、动作
（iii）与状态模式结合考查

（6）通信图常见考查形式

（i）补充对象名
（ii）补充消息

（7）构件图常见考查形式

（i）补充构件名
（ii）补充接口名
（iii）分析接口关系

（8）部署图常见考查形式

（i）补充节点名
（ii）补充协议名
（iii）补充内部构件名

6、“4+1”视图（⭐⭐）

UML采用4+1视图来描述软件和软件开发过程：
（1）逻辑视图：以问题域的语汇组成的类和对象集合。
（2）进程视图：可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描绘了所设计的并发与同步结构。
（3）实现视图：对组成基于系统的物理代码的文件和组件进行建模。
（4）部署视图：把构件部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。
（5）用例视图：最基本的需求分析模型。

7、OOA需求建模

六、需求开发-需求定义（⭐）

 

七、需求开发-需求验证

 

八、需求管理-定义需求基线

九、需求管理-需求跟踪

 

十、需求管理-需求风险管理

带有风险的做法：无足够用户参与，忽略了用户分类，用户需求的不断增加，模棱两可的需求，不必要的特性，过于精简的SRS，不准确的估算