需求分析-复习思考题_需求错误的代价-CSDN博客

本文链接：https://blog.csdn.net/qq_43688417/article/details/118095513

第一章《软件需求概述》思考题

1. 软件项目目标的三个要素是什么？

质量（需求是根本）、时间、成本

2. 理解IEEE对需求的定义。

（1）用户解决问题或达到目标所需的条件或权能（Capability）。

（2）系统或系统部件（组件）要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。

3. 谈谈需求文档的重要性。

案例一：中途更换所有的开发者，需求并未编写成文档，因此新的分析人员不得不从头做起；

重要性：如果只有一堆邮件、贴条、会谈过几次或一些零碎的对话，就确信已明白用户的需求，那是难以做到的。

案例二：某软件开发小组所开发的一套工具缺少某一特定的功能

重要性：这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件也达不到期望目标。通过需求文档回复设计人员提出的各类问题。依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。

4. 好的需求特征有哪些？

①深入理解用户的真正的意图和需要。

②清晰完整的需求表达。

③借助需求分析工具，E-R图、DFD图、DD、UML工具等等。？使用科学的需求管理方法，
完善需求变更控制流程。

5. 软件需求分析的目标是什么？

软件需求分析的目标是深入描述软件的功能和性能，确定软件设计的约束和软件同其它系统元素的接口细节，定义软件的其它有效性需求。

6. 需求分析的任务是什么？

需求分析的任务就是借助于当前系统（含手工作业）的逻辑模型导出目标系统的逻辑模型（如业务流程图等），解决目标系统的
“做什么” 的问题。

通俗地说,需求分析的任务就是准确地 定义 未来系统的 目标 ，确定为了满足用户的需求，系统必须 做什么 。用《需求规格说明书》规范的形式准确地表达用户的 需求。

7. 错误需求的代价有哪些？

（1）错误的需求浪费了人力、物力，浪费了金钱，总之，浪费资源。

（2）影响软件项目的成功，加大软件项目的风险。

（3）影响项目组及开发方形象，对用户满意度埋下“祸根”。

（4）增加开发的成本。

8. 产生不合格需求的原因有哪些？

（1）无足够用户参与。

（2）用户需求的不断增加。

（3）模棱两可的需求。

（4）过于精简的规格说明。

（5）忽略了用户分类。

如菜单驱动操作对高级用户太低效了，含义不清的命令和快捷键又会使不熟练的用户感到困难（如SAP的事务代码）。

（6）不准确的计划，往往低估需求分析工作的时间。

9. 好的软件需求特性有哪些？理解其含义。

“内涵一致，外延完整”，具体包含两个特征：一致性 和 全面性。引申为8个因素：

（1）无歧义因素（2）完整性因素（3）一致性因素（4）可检验性因素

（5）可跟踪性因素（6）正确性因素（7）可行性因素（8）必要性因素

10. 理解需求层次的构成，能识别业务需求、用户需求、功能需求和非功能需求。

软件需求包括不同的层次：业务需求、用户需求、功能需求和非功能需求。

业务需求反映了组织机构或客户对系统、产品的高层次的目标要求，它们在项目视图与范围文档中予以说明。
用户需求文档描述了用户使用产品必须要完成的任务，使用实例文档或场景描述中予以说明。
功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求和用户需求
非功能需求描述了系统展现给用户的行为和执行的操作等

11. 什么是需求的路线图，理解特性和涉众的概念。

① 需求路线：

了解从用户要求到软件需求的一般路径（从问题领域转向解决方案领域）

涉众需要（必须解决的业务或运作问题的反映）→系统特性（完成涉众需要而提供的服务）→软件需求（面向电脑语言的需求方案）

② 涉众：

涉众是与要建设的业务系统相关的一切人和事。

软件或系统项目涉众包括：客户、用户、需求分析员、开发人员、测试人员、文档编制人员、项目经理、法律人员、生产人员、市场营销

③ 特性：

所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。

第二章《软件需求工程及其过程》思考题

1. 什么是需求工程？了解其组成示意图。

需求工程是软件工程的核心组成部分，是指应用有效的技术、方法进行需求分析，确定客户需求，帮助分析和设计人员理解问题，并定义目标系统的一门学科。

它把整个软件需求工程研究领域划分为需求开发和需求管理两部分。

2. 需求管理活动的内容有哪些？

(1)定义需求基线（迅速制定需求文档的主体）。

(2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。

(3)使当前的项目计划与需求一致。

(4)估计变更需求所产生影响并在此基础上协商新的承诺（约定）。

(5)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。

(6)在整个项目过程中，跟踪需求状态及其变更情况。

3. 什么是软件生命周期模型？

软件产品经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后逐渐消亡。这样一个过程，叫软件生命周期模型。

4. 理解RUP（Rational United Process）二维开发模型。

在这里插入图片描述

5. 如何基于需求特点选择生命周期模型？

需求情况	瀑布模型	螺旋模型	RAD	迭代模型
需求容易定义或明确吗？	是	否	是	否
能在早期确定需求吗？	是	否	是	否
周期中需求经常变化吗？	否	是	是	否

6. 理解需求开发的迭代的过程图。

在这里插入图片描述

7. 掌握需求开发过程框架的内容（翻译成中文）。

在这里插入图片描述

序号	英文	翻译
1	define vision and scope	定义愿景和范围
2	identify user classes	识别用户类
3	identify user representatives	识别用户代表
4	identify requirements decision makers	识别需求决策者
5	select elicitation techniques	选择启发式技术
6	identify use cases	识别用例
7	prioritize use cases	确定用例优先级
8	develop use cases	开发用例
9	specify quality attributes	说明质量属性
10	Derive and document functional requirements	导出并记录功能需求
11	model the requirements	需求建模
12	Review requirements specifications	评审需求规格说明书
13	develop prototypes	开发原型
14	develop or evolve architecture	开发或发展架构
15	allocate requirements to components	给组件分配需求（组件复用）
16	develop test cases	开发测试用例
17	validate use cases, functional requirements, analysis models and prototypes	验证用例、功能需求、分析模型和原型

8. 理解Pressman的需求工程过程及其使用的需求环境。

在这里插入图片描述

9. 需求工程方法分成哪四类？

1.面向过程，注重输入输出, 如传统的结构化分析。

2.面向数据，强调数据结构，如E-R模型，DD描述。

3.面向控制，强调同步、并发，如DFD图。

4.面向对象，它建立在对象间的交互基础上，对对象模型、动态模型和功能模型三个方面对问题进行描述，如以UML为基础的Rose的建模工具。

10. 系统分析员的职责和技能有哪些？

① 职责：

1.收集、整理、分析、提炼、跟踪、控制用户的产品需求；

2.编写产品需求说明书，准确描述和解释业务需求；

3.编写设计文档，引导UI设计师制作产品原型（可选）；

4.编写详细产品需求分析书，提供给软件开发工程师，测试工程师。

② 技能：

（1）倾听的技巧（2）交谈和提问的技巧（3）分析能力（4）协调能力

（5）观察能力（6）写作能力（7）组织信息能力（8）人际交往能力

（9）建模能力

第三章《软件需求获取》思考题

1. 需求获取可以分成哪些活动？

查找需求源（识别需求的涉众）、网罗需求信息（收集各方面人员对产品的要求，得到“系统特性列表”）、整合需求信息。

2. 客户与开发人员的合作伙伴关系建立的前提是什么？

合作关系建立的前提：明确双方权利和义务。

3. 软件需求工程中，SRS指什么？

软件需求规格说明。需求分析员对来自不同客户的信息进行整理，把业务需求、业务规则、功能需求、质量目标、解决方案的建议等内容区分开来，形成SRS（软件需求规格说明）。

4. 如何更好地让客户听取对需求工作成果的解释？

需求分析员应使用不同的示意图来配合SRS文本对需求进行描述。客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

5. 对于MIS（管理信息系统，Management Information System）系统，通常情况下怎么样的需求，其优先级比较高？

使用频率高、使用人数多、核心业务、对经营和效益影响大（官方需要）、紧急程度高的需求。

6. 如何理解需求确认中客户的“签字”？

①
客户和开发人员之间合作伙伴关系的核心就是产品和需求达成一致。很多组织把在需求文档上签字作为客户认可需求的标志。

② 需求批准过程的所有参与者都应该明白签字意味着什么，否则会出现很多问题。

客户代表把在需求文档上签字视作毫无意义的仪式。

④ 开发经理把签字作为冻结需求的方法。
签字不仅仅是仪式，更重要的是建立需求协议的基线。

7. 项目的范围说明主要应该包括以下三个方面的内容？

① 项目的合理性说明（解释为什么要实施这个项目）

② 项目目标（也就是期望达到的产品或服务）

③ 项目可交付成果清单

8. 根据前景和范围文档，我们可以判断出某项特性或需求是否包括在项目中，一般有哪三种情况？

①一种是被提议的需求明显在范围之外。

②另一种可能是需求显然是在定义好的项目范围之内。

③第三种可能是被提议的新需求不再范围之内，但它很有价值，因而需要对项目范围做出调整以容纳这一新的需求。

9. 寻找客户需求中，为征求客户的意见，必须采取哪几步？

① 明确项目用户需求的来源。

② 明确使用该产品（软件）的不同类型的用户。

③ 与不同用户类的代表进行沟通。

遵从项目的最终决策者的意见。

10. 能举出和理解四种以上的软件需求来源。

① 与潜在用户进行交谈和讨论

② 描述现有产品或竞争产品的文档

③ 系统需求规格说明

现有系统的问题报告和改进要求
市场调查和用户问卷调查
观察用户如何工作
用户工作的情景分析

11. 画出客户和用户的层次结构图。

在这里插入图片描述

12. 用户代表（代言人）的作用是什么？

每个项目都有几位用户类的关键成员负责提供需求。我们称他们为用户代言人或项目（业务）协调人。
用户代言人为构造客户和开发人员之间的伙伴关系提供了有效途径。
每位用户代言人都是他所属用户类的成员与项目的需求分析员之间的主要联系人。
如果每位用户代言人都被赋予足够的权力，能够为他代表的用户类做出具有约束力的决定，他们就能发挥最大效应。

13. 理解不同情况下，需求“谁来做出决策”。

① 如果是个别用户之间的分歧，则由用户代言人来裁决

② 用户经理表述的需求和实际用户需求相矛盾，此时应该服从于用户代言人

③ 开发人员对产品的想法和客户要求不一致，此时应该服从于客户

④
不同用户类或客户群的需求相矛盾，支持最重要的用户类或对商业前景影响最大的客户群

⑤
不同的企业客户有不同的需求，依据项目的业务目标来确定哪些客户对项目的成败影响最大

14. 调查研究的主要方法有哪些？

① 用户访谈 ② 收集和研究资料 ③ 调查问卷 ④ 实地观察

15. 问卷调查和用户访谈的优点和缺点各是什么？

① 用户访谈

优点：为分析人员提供了与访谈对象自由沟通的机会；通过访谈可以挖掘更深层次的用户需求；访谈允许分析人员使用一些个性化的问题；成功的访谈在很大程度上取决于分析人员的经验与技巧；

缺点：访谈占用的时间较多，访谈后的资料整理，也需要花费较多的时间。

② 收集和研究资料

优点：获取大量历史、静态信息，有助于分析问题、数据精确。

缺点：需要整理归纳、深层次存在的问题不易发现。

③ 调查问卷

优点：大量发放、快速、低成本，保护隐私（不记名），便于归纳整理。

缺点：问卷不够灵活（内容局限）、信息质量难于保证。

④ 实地观察

优点：获取第一手数据、有助于弄清复杂流程（包括异常场景）、获取多方面数据，可以证实收集的资料正确与否，更正不正确的概念，澄清模糊的概念（某政府工资处的工改）。

缺点：必须懂得业务、跟随进行实际工作、较花费时间。

16. 各举两个例说明“业务规则”、“外部接口需求”和“数据定义”、“约束”。

**业务规则：**当客户说只有特定用户在特定条件下才能执行某一动作时。

“如果一个药剂师在危险化学制品培训方面是可靠的，那么他就可以在一级危险药品清单上订购化学制品”
、“图书馆的借阅者最多可以同时借10本书”。

外部接口需求：描述了系统与外部世界的联系

“从<某些设备> 读取信号” 、“以<某种格式>读取文件”

约束：对设计和实现的约束合理地限制了开发人员可用的选择

“不能申请多于一定数量的内存”、“操作必须与<其它系统>相同或类似”。

数据定义：“邮政编码” 、“物料序号”

17. 理解和说明用例法中的相关概念：用例、角色、主执行者、场景。

用例：描述了系统与外部角色之间的一系列交互。

角色：指与系统交互以实现某种目的的人、软件系统或硬件设备。

主执行者：提出请求的相关人员

场景：根据执行者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列
称之为一个场景。

第四章《结构化的需求分析与建模》思考题

1. 什么是需求分析模型？

经过对需求获取的资料进行分析，并以此建立起来的模型称之为需求分析模型。

2. 需求工程中，需求分析阶段模型的作用有哪些？

需求分析模型主要描述软件目标系统的数据信息、处理功能、用户界面及运行的外部行为，它并不涉及软件的具体实现细节。
模型帮助分析员理解系统的信息、功能和行为；模型成为评审焦点；模型也是设计基础。
建模充分体现了“分而治之”这一古老而有效的概念。把复杂而困难的问题分解细化后，逐个解决它们。
建模能有效地将需求映射到软件结构中。

3. 理解结构化分析模型图的组成。

在这里插入图片描述

4. 数据模型包括哪三种互相关联的信息？

数据对象、描述数据对象的属性和数据对象相互连接的关系。

5. 掌握E-R的画法，能根据背景编制E-R图，或根据E-R图描述其中的数据对象、属性和关系。

ER：实体—关系图

6. 掌握DFD图的画法，能根据背景材料编制DFD图，或根据DFD描述其数据流。

DFD: 数据流图（Data Flow Diagram）

7. 掌握STD的画法，能根据背景材料编制STD图。

Std: 状态转换图（State Transform Diagram）

8. 能根据DFD图的某图形元素，编写其数据词典。

数据字典：指对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述，其目的是对数据流程图中的各个元素做出详细的说明，使用数据字典为简单的建模项目。

名字: 定货报表
别名: 定货信息
描述: 每天一次送给采购员的需要定货的零件表
定义: 定货报表=零件编号+零件名称+定货数量+目前价格+主要供应者+次要供应者
位置: 输出到打印机

9. 理解结构语言，能根据处理逻辑的描述，编制判定树和判定表。

第五章《面向对象分析与建模》思考题

1. UML是由什么构成的？

视图（views）、图（diagrams）、模型元素（Model
elements）、通用机制（general mechanism）等构成。

2. UML用到的图包括哪些？理解各图的作用。

	作用	组成及与对象关系
用例图	描述角色与系统中的用例关系，主要用来描述系统的外部行为；	角色、用例	静态
类图	描述类及其关系，用来定义类的属性和操作；	名字、属性、操作(方法)；	静态
对象图	类实例对象		静态
状态图	对类的补充。描述类的对象所有可能的状态以及事件发生时状态的转移；	单个类对象状态、事件	动态
序列图	反映若干对象之间的动态协作状态，随时间流逝，对象间如何交互的。它强调对象之间消息发送的顺序，同时显示对象之间的交互。	多个对象、消息	动态
协作图	描述对象的关系及传递的消息，强调对象间的动态合作关系；		动态
活动图	反映一个连续活动流，显示动作和结果，尤其能表示并发和同步	单个或多个类对象	动态
组件图	反映代码的物理结构		静态
包图	多个组件组合成包图。		静态
部署图	描述系统软件和硬件的物理架构		静态

3. 可以根据场景画出活动图和序列图。

4. 用例模型是由哪些组成的？

执行者、用例、用例与执行者的关系（通信关联：执行者与执行的用例之间存在通信路径。）、
用例与用例的关系。

5. 用例间的关系有哪些？

包含（使用，include）：在基用例之上插入附加行为，并且具有明确的描述，包含公共用例。

扩展(extend)：在基用例上插入基用例不能说明的扩展部分。

泛化：用例之间的一般和特殊关系，其中特殊用例继承了一般用例的特性并增加了新的特性。

6. 能够根据背景画出用例图。

7. 理解包图的作用。

UML包图是表示顶层架构的适当机制。包是对类进行分组的一种机制，包的划分是实现“分而治之”的重要手段，将关系比较密切的关联类放在同一个包中。

8. 用例模型包括什么？用例规约由什么组成？

用例模型包括用例图和用例规约。

用例规约的组成：

简要说明：介绍该用例的作用和目的。

事件流：包括基本事件流和异常事件流。

特殊需求：非功能性需求和设计约束

前置条件：执行用例之前系统必须所处的状态。

后置条件：用例执行完毕后系统可能处于的状态。

9. 软件顶层架构有哪四种模式？

客户/服务器模式

模型－视图－控制器模式

分层模式

流程处理模式

10. 什么是类图？类图中类的关系有哪几种？

UML类图是表示领域(指业务领域)概念模型的适当机制类之间的关系：

实现：如基类实现接口。

泛化：抽象和具体，如交通工具和自行车。

关联：类之间的相关性，包括聚集和组成关系。依赖：是关联的弱化。

11. 理解并能说明原型法的工作流程。

在对用户需求作简要分析后，就快速地建立系统的原型，使用户能通过实际试用原型系统来认识优势与不足，多次反复地参与原型改进，直到得到满意的系统。

①用户提出要求②识别归纳问题③开发系统原型④分析评价

⑤不可行处理⑥不满意处理⑦修改⑧试运行

第六章《需求分析文档编制》思考题

1. 需求开发的最终成果是什么？

在客户和开发小组对所要开发的产品达成共识后，所编写的具体文档（）。这一文档综合了业务需求、用户需求和软件功能需求。

2. 表示软件需求最常用和最普遍的方式是什么？

文档、图形化模型、形式化规格说明.

3. SRS指什么？举例（四个以上）说明如何增强SRS的可读性。

SRS 需求规格说明书

可读性：

① 对节、小节和单个需求的标记格式必须一致

② 灵活地使用各种可视强调标志

③ 创建目录表，也许还需要创建索引，这有助于读者找到他们所需要的信息。

④ 对所有图和表进行编号，并且给出标题，根据编号来引用这些图和表。

使用合适的模板来组织所有的必要信息

4. 需求标识方法有哪几种？各举一例。

1. 序列号：如UR-2,SRS13

2. 层次型编号：如“第3.2.5部分—编辑功能”

3. 层次型文本标签
：如“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。”被标识为“PRINT.COPIES.CONFIRM”

4. 理解TBD的含义。

to be determined，TBD（待定）

使用TBD符号（待定）作为标准指示器来强调软件需求分析规格说明书中这些需求的缺陷。

把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目。

5. 理解软件需求规格说明模板中每个标题的含义及说明。

1. 引言 2. 总体描述 3. 系统特性 4. 外部接口需求 5. 其他非功能性需求

6. 其他需求 7. 附录A：术语表 8. 附录B：分析模型 9. 附录C：待确定问题的清单

6. 能根据软件需求编写原则，改进需求内容的表述。(实例在ppt上）

第七章《需求验证与评审》思考题

1. 软件需求验证活动要确定哪几方面的内容？

①软件需求规格说明正确描述（无二义性和模糊内容）了预期的系统行为和特征。

②从系统需求或其它来源中得到软件需求。

③需求是完整的和高质量的。

④对需求的看法是一致的。

⑤需求为继续进行产品设计、构造和测试提供了足够的基础。

2. 两种最重要的验证技术是什么？

正式和非正式的需求评审

**正式的需求评审：**遵循预先定义好的一系列步骤过程。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组，对产品是否完整，对所发现的错误和所提出的问题的总结。
非正式的需求评审：把工作产品分发给许多其它的开发人员粗略看看,或者走过场似地检查一遍(walkthrough)
，执行者描述产品，且征求意见，不需要记录备案。

优点：培养其他人对产品的认识，并且有利于获得反馈意见

缺点：非系统化的，不彻底的

需求文档的评审是一项精益求精的技术。