软件需求分析习题汇编

习题集

一、单项选择题

1、需求分析最终结果是产生（ ）。

A．项目开发计划 B．可行性分析报告 C．需求规格说明书 D．设计说明书 答案：C

2、需求分析中，开发人员要从用户那里解决的最重要的问题是（ ）。 A．让软件做什么 B．要给软件提供哪些信息 C．要求软件工作效率怎样 D．让软件具有何种结构 答案：A

3、需求规格说明书的内容不应包括对（ ）的描述。

A．主要功能 B．算法的详细过程 C．用户界面和运行环境 D．软件性能 答案：B

4、需求规格说明书的作用不应包括（ ）。

A．软件设计的依据 B．用户与开发人员对软件要做什么的共同理解 C．软件验收的依据 D．软件可行性研究的依据 答案：D

5、下面关于面向对象方法中消息的叙述，不正确的是（ ）。

A．键盘、鼠标、通信端口、网络等设备一有变化，就会产生消息

B．操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息 C. 应用程序之间可以相互发送消息

D．发送与接收消息的通信机制与传统的子程序调用机制不同 答案：B

6、面向对象技术中，对象是类的实例。对象有三种成份：（ ）、属性和方法(或操作)。 A. 标识 B. 规则 C. 封装 D. 消息 答案：A

7、软件需求分析阶段的工作，可以分成以下四个方面：对问题的识别、分析与综合、 制定规格说明以及（ ）。

A．总结 B．实践性报告

C．需求分析评审 D．以上答案都不正确 答案:C

8、软件需求规格说明书的内容不应包括对（ ）的描述。 A． 主要功能 B．算法的详细过程 C．用户界面及运行环境 D．软件的性能 答案:B

9、产品特性可以称为质量属性，在众多质量属性中，对于开发人员来说重要的属性有哪些（B ）

A 有效性、效率、灵活性、互操作性

B 可维护性、可移植性、可重用性、可测试性

C 完整性、可靠性、健壮性、可用性 D 容错性、易用性、简洁性、正确性

10、需求包括11个方面的内容，其中网络和操作系统的要求属于（B ），如何隔离用户之间的数据属于（C），执行速度、相应时间及吞吐量属于（D ），规定系统平均出错时间属于（A ）。

A 质量保证 B环境需求 C安全保密需求 D 性能需求

11、需求分析过程应该建立3种模型，它们分别是数据模型、功能模型、行为模型。以下几种图形中，（B ）属于功能模型，（A ）属于数据模型，（C）属于行为模型。

A 实体-联系图(ERD) B 数据流图(DFD) C 状态转换图(STD) D鱼骨图 12、常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向对象的分析方法（OOA），下列(D)不是结构化分析方法的图形工具。

A决策树 B数据流图 C数据字典 D快速原型

13、软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性。其中，（B ）和（C ）用完就可以丢弃，而（A）围绕原型修改、增加。 A 进化型 B 探索型 C实验型 D 以上都是 14、（ D）用于描述数据的处理过程。

A 数据字典 B决策树 C决策表 D 数据流图 15、DFD的基本符号不包括下列哪种（A）

A 数据字典 B 加工 C 外部实体 D 数据流 E 数据存储文件 16、DD的主要字典条目包括以下哪种（E）

A数据流 B文件 C 数据项 D加工 E以上都是 17、常用的动态分析方法不包括以下哪种（B）

A 状态迁移图 B 层次方框图 C时序图 D Petri网 18、需求分析阶段的文档包括以下哪些（E ）

A 软件需求规格说明书 B数据要求说明书 C初步的用户手册 D修改、完善与确定软件开发实施计划 E以上都是

19、需求验证应该从下述几个方面进行验证：（C ）

A 可靠性、可用性、易用性、重用性B可维护性、可移植性、可重用性、可测试性 C一致性、现实性、完整性、有效性 D 功能性、非功能性 20、风险管理的要素包括哪项（D）

A风险评价 B风险避免 C风险控制 D以上都是 21、下列描述中错误的是（D）

A每一个集成的需求变更必须能跟踪到一个经核准的变更请求。 B变更过程应该做成文档，尽可能简单，当然首要的是有效性。

C所有需求变更必须遵循过程，按照此过程，如果一个变更需求未被采纳，则其后过程不再予以考虑。

D可以从数据库中删除或修改变更请求的原始文档。

二、填空题

1、需求分析阶段产生的最重要的文档是（ 需求分析说明书 ）。 2、需求分析的主要任务是( 要回答“软件必须做什么?” )。

3、需求分析阶段，分析人员要确定对问题的综合需求，其中最主要的是（功能）需求。

4、需求分析阶段研究的对象是软件项目的（ 用户要求 ）。

5、软件生命周期：问题定义、可行性研究、需求分析、总体设计、详细设计、编码和单元测试、综合测试、软件维护。

6、信息系统必须实现的功能，或者说信息系统必须具备的属性和质量称为（系统需求（需求） ）。 7、（模型）是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，由一组图形符号和组织这些符号的规则组成。

8、软件需求分析阶段的目的是澄清用户的要求，并把双方共同的理解明确地表达成一份书面文档——（软件需求规格说明书）。

9、软件需求分类，分为（功能性）需求和（非功能性 ）需求。 10、需求分析的步骤包括（需求获取 ）、（分析建模 ）、文档编写、需求验证。

11、鱼骨图是一种用于确定、探索和描述问题及其原因和结果的图形工具，又被称为（因果图）。

12、大多数的需求分析方法是由信息驱动的，信息域具有三种属性：（信息流）、（信息内容）和信息结构。

13、在软件开发中，使用原型时可采取两种不同的策略，即：（废弃 ）策略和（追加）策略。

三、名词解释

1、需求分析：开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转换到相应的形式主义功能规约(需求规格说明)的过程。

2、软件需求：IEEE软件工程标准词汇表中定义需求为：用户解决问题或达到目标所需的条件或权能；系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或权能；一种反映上面（1）或（2）所描述的条件或权能的文档说明。

3、需求工程：整个软件需求范围内所进行的活动称为需求工程，需求工程包括需求开发和需求管理两部分，需求开发包括问题获取、分析、编写规格说明和验证。

4、业务模型：业务模型是理解一个组织业务过程的技术。可以用业务用例模型和业务对象模型来表达业务模型。业务用例模型是分别从与业务过程和客户对应的业务用例和业务参与者的角度来描述企业的业务过程；业务对象模型描述了如何由一组工作人员使用一些业务实体和工作单元来实现每个业务用例。

5、原型开发方法：一个软件原型是所提出的新产品的部分实现，使用原型有三个主要目的：1）明确并完善需求，2）探索设计选择方案，3）发展成为最终的产品。建立原型的主要原因是为了解决在产品开发的早期阶段不确定的问题。原型可分为抛弃型原型和进化型原型。

6、数据字典：一个定义应用程序中使用的所有数据元素和结构的含义、类型、数据大小、格式、度量单位、精度以及允许取值范围的共享仓库。

四、简答题

1、生命周期模型是什么？常见的生命周期模型有哪几种？

答：对软件开发流程的一种描述；为解决问题所定义的策略；对典型开发活动的抽象。 常见的生命周期模型： Waterfall,Prototyping,Phased,Spiral.

2、为什么要使用生命周期模型？

答：帮助开发组了解他们在开发项目中的活动、资源和限制；帮助项目了解在开发过程中的不一致，丢失，冗余等情况，把注意力集中在开发最终的产品上；帮助项目组裁剪开发过程－－ 没有基础就无从裁剪。

3、Waterfall的优势是什么？

答：具有良好定义的里程碑；利于向不熟悉软件开发的客户讲解流程；帮助开发人员理解需要做的事情；清楚地描述下阶段开始前需要的中间产品；是很多其他LC模型的基础。

4、需求分析阶段的基本任务是什么？ 答：需求分析阶段的基本任务是:

(1).问题识别：双方对问题的综合需求：a.功能需求b.性能需求c.环境需求d.用户界面需求.

(2).分析与综合，导出软件的逻辑模型. (3).编写文档

五、问答题

1、软件过程的概念及分类，基本过程包含些什么及每个过程的具体内容。 答：软件过程也称为软件生存周期过程或软件过程组，是指软件生存周期中的一系列相关过程。过程就是活动的集合，活动是任务的集合，任务则起到把输入加工成输出的作用。活动的执行可以是顺序的 、迭代的（重复的）、并行的、嵌套的或是有条件引发的。 软件过程可以分为三类：基本过程、支持过程和组织过程。 基本过程包括： 1）获取过程：（项目委托方）确定需求；招标；签订合同；对供应方的监督；验收完成。 2）供应过程：（项目承包方）理解需求；投标；签订合同；计划；实施；控制；评审评价；交付。

3）开发过程：（软件开发人员）过程实施准备；系统需求分析；系统结构设计；软件需求分析；软件体系结构设计；软件详细设计；软件编码和测试；软件集成；软件合格测试；系统集成；系统合格测试；软件安装；验收支持。 4）运行过程：（用户）运行准备；运行测试；产品转移；运行；运行支持；运行评价。 5）维护过程：（维护人员）过程实施准备；问题分析和修改设计；修改实施；对维护的评审和验收；软件移植；软件退役。

2、简述软件需求工程分为哪几类？其中需求获取和需求规约目的和任务。

答：软件需求工程细分为：需求获取、需求分析与协商、系统建模、需求规约、需求验证和

需求管理六个阶段。

需求获取：系统分析人员通过与用户的交流、对现有系统的观察及对任务进行分析，确定系统或产品范围的限制性描述、与系统或产品有关的人员及特征列表、系统的技术环境的描述、系统功能的列表及应用于每个需求的领域限制、一组描述不同运行条件下系统或产品使用状况的应用场景以及为更好地定义需求而开发的任意原型。

需求获取的工作产品为进行需求分析提供了基础 ,为后期开发设计人员提供需求分析报告。 需求规约：软件需求规约是分析任务的最终产物，通过建立完整的信息描述、详细的功能和行为描述、性能需求和设计约束的说明、合适的验收标准，给出对目标软件的各种需求。 需求规约作为用户和开发者之间的一个协议，在之后的软件工程各个阶段发挥重要作用。

3、简述软件体系结构的概念及基于B/S体系结构的实现方式。

答：软件体系结构：软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组组合连接起来。

B/S结构：浏览器（客户机）——WEB服务器——数据库服务器

B/S体系结构的实现方式：B/S模式下的客户机只需安装浏览器软件，无须开发前端应用程序；中间层的Web应用服务器，主要的数据计算和应用都在此完成，因此对中间层服务器的要求较高；后台数据库服务器主要完成数据的管理。

4、用户界面设计三个的任务和目的。

答：用户界面设计在工作流程上分为结构设计、交互设计、视觉设计三个部分。

1）结构设计：结构设计也成概念设计 ，是界面设计的骨架。通过对用户研究和任务分析，制定出产品的整体架构。基于纸质的的低保真原型（Paper Prototype）可提供用户测试并进行完善。在结构设计中，目录体系的逻辑分类和语词定义是用户易于理解和操作的重要前提。

2）交互设计：交互设计的目的是使产品让用户能简单使用。 任何产品功能的实现都是通过人和机器的交互来完成的。因此，人的因素应作为设计的核心被体现出来。 3）视觉设计：在结构设计的基础上，参照目标群体的心理模型和任务达成进行视觉设计。包括色彩、字体、页面等。视觉设计要达到用户愉悦使用的目的。

5、需求规格说明文档的作者及表现手段。 答：作者：

项目管理者：组织安排、提供条件 需求工程师：负责人、主导人

文档写作人员：有时会采用，节省需求工程师的时间 涉众（用户）：验证人 表现手段：

非形式化：自然语言、限制性文本

半形式化：结构化文本（伪码/结构化英语）、模型语言（图、表） 形式化：形式化语言（数学语言：BNF）

6、数据库设计的内容及常用方法。

答：数据库设计包括数据库的结构设计和数据库的行为设计。 1）数据库的结构设计

数据库的结构设计指是根据给定的应用环境，进行数据库的模式或子模式的设计。 它包括数据库的概念设计、逻辑设计和物理设计。数据库模式是各应用程序共享的结构，是静态的、稳定的，一经形成后通常情况下是不容易改变的，所以结构设计又称为静态模型设计。

2）数据库的行为设计

数据库的行为设计是指确定数据库用户的行为和动作。而在数据库系统中，用户的行为和动作指用户对数据库的操作，这些要通过应用程序来实现，所以数据库的行为设计就是应用程序的设计。用户的行为总是使数据库的内容发生变化，所以行为设计是动态的，行为设计又称为动态模型设计。

数据库常用设计方法：直观设计法、规范设计法、计算机辅助设计法、自动化设计法。

7、如何正确看待客户？

答：即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。 如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。

8、概括说明如何进行需求分析？

答:（1）需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。 （2）分析方法大体有两类：“问答分析法”和“建模分析法”。

第一：问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。 问答分析最重要的问题是：“是什么”和“为什么”。其它常见的问题有： 需求存在二义性吗？ 需求文档的上下文有矛盾吗？ 需求完备吗？ 需求是必要的吗？ 需求可实现吗？ 需求可验证吗？ 需求的优先级确定了吗？

第二：建模分析法：在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。 建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。

9、概括说明什么是好的需求规格说明书？

答：第一 ;正确 需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。第二： 清楚 清楚的需求让人易读易懂。 第三： 无二义性 “无二义性” 是指每个需求只有唯一的含义。第四：一致 “一致”（Consistent）是指《产品需求规格说明书》中各个需求之间不会发生矛盾。 第五 ：必要 《产品需求规格说明书》中的各项需求对用户而言应当都是必要的。第六 ：完备 “完备”（Complete）是指《产品需求规格说明书》中没有遗漏一些必要的需求。第七 ：可实现 《产品需求规格说明书》中的各项需求对开发方而言应当都是可实现的（Attainable）。第八： 可验证 《产品需求规格说明书》中的各项需求对用户方而言应当都是可验证的（Verifiable）。如果需求是不可验证的，那么用户就无法验收软件，可能会发生商业纠纷。 第九： 确定优先级 需求的优先级其实就是需求“轻重缓急”的分级表述，例如划分为“高、中、低”三级。一般地，由用户和开发方共同确定需求的优先级。 第十 ：阐述“做什么”而不是“怎么做” 《产品需求规格说明书》的重点是阐述“做什么”，而不是阐述“怎么做”。“怎么做”是系统设计和实

现阶段的事情。

10、如何定义产品说明书？

答：第一步：细化并分析用户需求 需求分析员首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需求。例如采用Rational 的Rose工具进行需求的建模分析，建模分析产生的文档可以作为《产品需求规格说明书》的附件。补充说明：建模分析的技术难度比较高，需求分析员应当根据自身水平进行取舍。 第二步：撰写产品需求规格说明书

需求分析员按照指定的文档模板撰写《产品需求规格说明书》。如果待开发的产品分为软件和硬件两部分的话，则应当撰写《软件需求规格说明书》和《硬件需求规格说明书》。 第三步：进行需求确认

项目经理邀请同行专家和用户（包括客户和最终用户）一起评审《产品需求规格说明书》，尽最大努力使《产品需求规格说明书》能够正确无误地反映用户的真实意愿。 需求评审之后，开发方和客户方的责任人对《产品需求规格说明书》作书面承诺。

11、需求说明书由哪些部分组成？各部分之间的关系是什么？ 答：软件需求说明书一般包括如下内容：

1）引言部分 编写目的；项目背景 (应包括：a.项目的委托单位、开发单位和主管部门；b．该软件系统与其他系统的关系。) ；定义；(列出文档中所用到的专门术语的定义和缩写词的原文。)参考资料。

2）任务概述 目标；运行环境；条件与限制。

3）数据描述 静态数据；动态数据 (包括输入数据和输出数据) ；数据库描述 (给出使用数据库的名称和类型) ；数据词典；数据采集。 4）功能要求 功能划分；功能描述。

5）性能需求 数据精确度；时间特性(如响应时间、更新处理时间、数据转换与传输时间、运行时间等)；适应性(在操作方式、运行环境、与其他软件的接口以及开发计划等发生变化时，应具有的适应能力。)

6）运行需求 用户界面(如屏幕格式、报表格式、菜单格式、输入输出时间等)；硬件接口；软件接口；故障处理。

7）其他要求 如可使用性、安全保密、可维护性、可移植性等。 8）附录。

12、简述优秀软件需求所应具有的特性。

答：优秀需求所具有的特性：完整性，正确性，可行性，必要性，划分优先级，无二义性，可验证性。

13、什么是软件需求开发，软件需求开发要做哪些工作？

答：软件需求开发分为：问题获取、分析、编写规格说明和验证四个阶段。包括软件类产品中需求收集、评价、编写文档等所有活动。包括以下几个方面：

? 确定产品所期望的用户类。 ? 获取每个用户类的需求。

? 了解实际用户任务和目标以及这些任务所支持的业务需求。

? 分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决方法和附加信息。

? 将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件。 ? 了解相关质量属性的重要性。 ? 商讨实施优先级的划分。

? 将所收集的用户需求编写成规格说明和模型。 ? 评审需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组接受说明之前将问题都弄清楚。

14、什么是软件需求管理，软件需求管理的主要活动有哪些？

答：需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动，包括：变更控制，版本控制，需求跟踪和需求状态跟踪。

15、试论述用例（USE CASE）在软件需求分析中的地位与作用？

答：用例描述了系统和一个外部ACTOR的交互顺序，用例表达了系统的功能需求。在表达系统需求时，用用例图、用例的脚本说明和词汇表等要素来表达系统功能需求，补充规约来表达系统的非功能需求。

16、在开发一个软件系统时，要获取哪些方面的需求？如何综合利用各种表达工具有效、全面的表达软件的需求？

答：软件需求包括功能需求、非功能需求，功能需求由用户需求和系统需求转化而成，非功能需求包括质量属性、约束条件和其他非功能需求。

用用例模型（用例图、用例规约）表达系统功能需求； 补充规约表达系统非功能需求；

ER图与数据字典可以表达系统数据需求； 数据流图（DFD）可以表达系统的功能需求； PETRI网、状态图可以表达系统的实时性需求。

六、分析题

1、在下面的描述中，辨识参与者（ACTOR）和用例（USE CASE），并画出一个用例图。 在医生的办公室里，接待员、护士和医生使用病人记录和计划安排系统。当病人第一次来这里看病时，接待员使用该系统来输入病人信息，并且他们安排所有的预约。护士使用系统来跟踪病人每次看病的结果并输入护理病人的信息，如医疗和诊断。护士也可访问这些信息以打印病人诊断结果或病人看病历史。医生主要用这个系统来查看病人的病史，偶尔也输入病人医疗信息，但通常他让护士输入这些信息。 解：

输入病人信息接待员安排预约登录医生输入医疗信息护士输入护理病人（诊断）的信息查询病史打印病历查询病人诊断结果打印病人诊断结果2、以下是一个简化的网上购物系统的描述：

该系统有3类用户：游客、用户、管理员。 管理员管理商品类别、商品、用户、订单等基本信息。用户可以对商品进行浏览、查询，可以把中意的商品放进购物车，并可以对购物车进行管理，最后可以进行结算下订单，可以登录个人用户中心，管理个人相关信息。游客可以对商品进行浏览、查询，把中意的商品放进购物车，可以对购物车进行管理，但是下订单前需要进行登录。

请同学们按自己的情况在(一)和(二)之间选择作答。

（一）用用例图描述本系统的功能需求；绘出该系统的主要实体类关联图（类要给出主要属性）。 （二）（1）用顶层数据流图和中层数据流图(顶层的下一层)描述本系统的功能需求；（2）绘出该系统的实体-关系图(要给出主要属性)。

3、围绕本学期你在工作室开发的项目，从需求工程角度展开论述（不少于800字）。

4、根据下列描述，说明新的直接销售和财务处理系统的业务需求有哪些？

Especially for You Jewelers是大学城的一个小珠宝零售商。在过去的两年里，Especially for You在它的商业方面经历了极大的发展，可是，它的财务业绩却与它的发展不同步。现在的事务处理系统部分手动、部分自动，不能有效的追踪客户账单和收据，Especially for You难以确定为什么它的成本这么高。此外，Especially for You频繁地实行特价以吸引顾客。它不知道这些特价是否有利可图，是否带来其他的销售。Especially for You也想增加回头客，所以它需要一个客户数据库。Especially for You想按照一个新的直接销售和财务处理系统以帮

助解决这些问题。

5、设想你自己就是ATM机的唯一用户:

a) 写出你对ATM机系统的用户需求。

b) 尝试将用户需求转换为系统（级）需求。

c) 除了功能性需求之外，还有哪些需求需要定义？请你一一写出这些需求。

6、职工福利和工资顾问遇到了一些问题。她的工作是为雇员提供他们的福利建议。公司刚刚磋商了一个新的医疗保险方案，这个方案要求雇员从7个保健组织和首选的供应商方案中进行选择。保健组织和供应商按照雇员的分类、贡献、免赔额、受益人、服务内容和允许的服务提供商而各不相同，目的是尽可能为雇员提供最灵活的福利，用以使公司的花费极小化并控制付给保险商的费用（这将对公司被收取的后续保险费产生一定的影响）。 这个顾问被请来为雇员选择最合适的保险方案。她目前以手工方式答复这些请求。但目前的选择比新计划中的选择要直接得多。她需要解释新的选择：它们包括什么，不包括什么，它们的费用和可能费用是多少，具有什么优缺点。但是，雇员对新计划不信任，这种情况迫使她需要向雇员提供更多具体的建议和答复。

她可能不得不为许多雇员逐步建立假定情境——可能的最坏假定情境。这种假定将要根据每个雇员的收入、婚姻和家庭状况、目前的健康风险等进行个人定制。在逐步建立一些样本假定时，她发现：（1）从信息系统部门获得工资和个人数据需要一天时间。（2）雇员数据存储在许多文件夹中，而且并不总是被正确地更新。当冲突数据变得很明显时，除非解决了矛盾，否则就不可能继续她的工作。（3）计算复杂。为一个雇员创建投资和退休假定常常需要花费一整天或更长时间。（4）有些人担心保险计划会被提供给未授权的个人，例如以前的配偶或者非直系亲属。（5）计算中可变条件的复杂性导致经常出错，很多错误可能一直未被发现。

假设现在需要你来开发一个软件，解决职工福利和工资顾问的问题。那么你认为她现在遇到的问题有哪些？你希望新的软件应该达成哪些业务目标？你怎样设计软件的高层解决方案和系统特性？解决方案有哪些重要的约束？

7、Rolland实业公司拥有着自己的软件开发部门——IS部门，负责为公司完成各种信息系统的开发。现在，IS部门给Rolland公司的部门结构重组带来了难题。

非IS部门的管理人员正施加压力，要求实施一种新的组织结构，其中大部分需求工程师将直接向他们的业务用户组（例如会计、财务、生产）汇报工作，而不是向IS部门汇报工作。非IS部门的管理人员认为：在目前的结构下，由于需求工程师向信息服务部门汇报工作，所以为了方法计算处理，他们往往希望“改变每一件事情”。为了保证系统能够满足IS的标准，非IS部门的管理人员同意在IS部门保留一个需求工程师小组，他们对所有的系统项目具有最终的决定权。

IS部门的经理们正抵制这种变化。他们认为：需求工程师如果离开IS部门，将会在技术上“走入歧途”；将需求工程师彼此分开会减少他们的思想交流，最终难以创新；数据文件和程序会产生不必要的重复；由于程序员仍属于IS部门，需求工程师和程序员的冲突将会增加。

在这个问题上，需求工程师分成了两个阵营，他们明白用户更直接地控制其系统的命运的好处。然而，他们担心当遇到预算超支和技术延迟时，用户和用户管理层将很难谅解。需求工程师还担心，如果他们被重新分配到IS部门之外，远离那些更侧重于技术的同事，会导致他们技术的退化。

17、一个好的目标应满足的原则（SMART）

必须是具体（Specific）的：目标必须能够指导具体的工作

必须是可以度量（Measurable）的：这样才能进行成本/效益分析 必须是可以达到（Attainable）的：否则是没有意义的目标 必须和其他目标具有相关性（Relevant） 必须具有明确的截止期限（Time-based）

18、需求开发过程

需求开发过程是一个迭代的过程，不要期望可以线性地、顺序地完成获取、分析、编写规格说明和验证这些需求开发活动。

19、划分主题域(构件图，也即UML中的组件图)

业务事件类型：

外部事件（来自系统外部的事件，也就是系统参与者发起的） 内部事件（系统内部触发的）

20、确定主题域（上下文关系图）

上下文关系图：针对每个主题域来绘制上下文关系图，确定出每个主题域的范围。 上下文关系图绘制要点：

首先用一个矩形表示系统，写上系统的名称，将整个系统看作一个黑盒子。 然后找到该系统的所有客户（处于主题域的外部），考虑他们会发起什么事件，这些事件会引发内部工作人员的什么动作，将这些序列逐一表示出来。 最后再看看系统的每个内部工作人员还有没有一些主动发起的事件。

当上下文关系图绘制出来之后，整个主题域的范围也就框定出来了，但是它还不足以为后续的需求捕获、分析与建模活动提供良好的基础。我们需要将主题域的内容以业务事件列表和报表列表表示出来。

21、需求分析人员的工作

需求分析人员是对项目相关人员的需求进行收集、分析、记录和验证职责的承担者，是用户群体和软件开发团队间进行需求沟通的主要渠道。

定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求等。

22、需求分析人员必备的技巧和知识

需求分析员必须掌握的技能：包括倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力。而这些能力可以概括为业务知识、技术知识和沟通能力三个方面。

需求分析人员必备的知识：具备从实践经验中积累的广博知识 需要将需求开发与管理活动贯穿于整个产品生命期中 掌握应用领域的知识

23、如何成为一名需求分析人员

优秀的需求分析员是培养出来的，而不是训练出来的。 这项工作包括很多面向人而不是技术的“软性技能”。

对于需求分析员的工作并没有标准的描述，因而也没有标准的培训课程。

24、需求捕获的主要方法

用户访谈、用户调查、文档分析、现场访问客户

25、获取客户需求的主要步骤

确定产品的不同用户类型。 确定用户需求的来源。

挑选出每一类用户和其他涉众的代表并与他们一起工作。 商定谁是项目需求的决策者。

26、需求捕获应该是主动的和聚集的 √ 27、需求的来源

与潜在用户进行交谈和讨论 描述现有产品或竞争产品的文档 系统需求规格说明

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

28、用户代表

用户代表应当自始至终参与项目的整个开发过程，而不是仅参与最初的需求阶段。

29、需求捕获要具有计划性和科学性

计划应针对下面这些内容来制定：

需求获取的目的

需求获取的策略和过程 需求获取工作取得的成果 进度和资源评估 需求获取的风险

科学性则体现在捕获方法的选取上

30、需求获取中各种心理如何应对

言过其实心理

差异展现法：也就是将不同用户代表的访谈结果进行整理，在系统开发之前把这些差异展示给中高层管理人员，就如何解决达成共识。

瓶颈分析法：对流程执行过程中的瓶颈进行分析，例如时间瓶颈、人员瓶颈（比如所有的申请都要由处长审批）等方面，以避免流程瓶颈导致系统无法顺利运转起来

越俎代庖心理

要解决这个问题，关键在于需求捕获人员能够识别出正确的被访谈者，也就是回答你要问的问题最佳的人选是谁。这里有两层意思：

问题的层次是否正确：高层管理人员解决宏观问题，中层管理人员解决脉络问题，操作者解决细节问题。

根据业务背景判断：也就是有效地识别该问题所针对的业务环节是由谁负责处理的？执行者往往是回答的最佳人选。

非正事心理

客观原因：办公室本身就是一个容易被干扰的环境。应对之道：访谈应该尽可可能的避开办公室。

主观原因：非计划的事情通常会被看做是低优先级的事情。应对之道：做好一周的访谈计划，列出访谈人，访谈要点，让对方统一安排。

抗拒心理

我们需要先“化敌为友”。这是主导的策略，实际的方法有很多

推卸责任心理

突破推卸责任心理的简单手段是让被访谈者介绍工作场景。

31、需求获取中的注意事项

如果没有一个有条理的组织方案（例如用例），要将来自众多用户的需求意见合并起来相当困难。

只向很少的用户代表收集意见，或者只听取声音最大、最固执已见的客户的意见，也是需求获取过程中存在的问题。

这将导致遗漏对某些用户类很重要的需求，或者引入一些大多数用户并不需要的需求。 解决这一问题的最佳平衡方式是让用户代言人参与需求获取，这些代言人必须具备为所属的用户类代言的权力，同时每个代言人都有数名来自同一用户类的用户代表作为后援。

需求获取过程中，你也许会发现项目范围定义不正确，或者太大，或者太小。

32、需求分析主要用来做什么

需求分析实际上是业务分析，也就是选择一种业务导向的线索将零散的需求串起来，形成一个体系完整、内容清晰的框架，以指导后续的设计、开发工作。

更具体地描述需求分析工作的任务：分解、提炼、消除矛盾。连成一句话就是：

需求分析就是先分解、再提炼，在这个过程中消除矛盾。

33、建模的要点与原则

建模的要点

设计要考虑到计划之外的变化 设计要文档化

用可视化的模型表达架构 切忌“为了建模而建模” 建模的原则

选择创建什么模型对如何动手解决问题和如何形成解决方案有着深远的影响 每一种模型可以在不同的精度级别上表示 最好的模型是与现实相联系的

单个模型是不充分的，对每个重要的系统最好用一组几乎独立的模型去处理

34、建模工具的选择

建模的要点是根据要完成的任务选择合适的建模工具。

35、UML的优点

首先UML是一种统一的、标准化的建模语言，它能为许许多多参与软件设计和开发的人提供一种公共“语言”，使他们能够基于共同的“模型”来理解业务、需求，理解软件和架构如何构造

其次UML是一种应用面很广泛的建模语言，它不仅可以用于软件系统建模，还可以用于业务流程、业务知识、数据库、嵌入式等多个领域；而且对于不同的领域，其所采用的本质元素是相同的。这样：不同的人就可以基于相同的语言沟通；不同的领域模型就可以通过相同的机制进行互换与迁移。这就是统一的趋势

36、流程分析（跨职责流程图、活动图）

跨职责流程图

适合于将流程分析的产物在企业管理中复用时，或者参与的人员有更强的业务背景。 要素：流程名称、职责带区、流程阶段、流程元素、并行、流程引用

活动图

活动图是一种表述过程机理、业务过程以及工作流的技术。它主要的应用包括两个方面：一是在业务建模阶段，对工作流进行建模；二是在系统分析和设计阶段，对操作进行建模

它的作用和传统的“流程图”是有着很深的渊源，也十分的相似。不过它与流程图最主要的区别在于，活动图能够支持并行的行为。

37、领域类图

标识类：发现类的方法很多，此处介绍最广泛使用的“名词动词法”

主要规则：名词与名词短语中提取对象与属性；动词与动词短语中提取操作与关联；所有格短语通常表明名词应该是属性而不是对象

38、用例模型

参与者：参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。参与者不仅可以由人承担，还可以是其他系统、硬件设备，甚至是时钟。 用例：用例实例是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果。

用例的特征：

用例是相对独立的：

用例的执行结果对参与者来说是可观测的和有意义的：

这件事必须由一个参与者发起。不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例：

用例必然是以动宾短语形式出现的：

一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元

两个用例之间可能存在的关系：包含、扩展、泛化，而通常不应该有通信关系 包含关系：在UML中，用构造型<>表示（箭头方向是从基用例到被包含用例），它是指基用例在它内部说明的某一个位置上显式地合并了另一个用例的行为 扩展关系：在UML中，扩展关系用构造型<>表示（箭头从扩展用例到基用例），它表示基用例在由扩展用例间接说明的一个位置上，隐式地合并了另一个用例的行为 泛化关系：用例间的泛化则表示子用例继承了父用例的行为和含义；子用例还可以增加或覆盖父用例的行为；子用例可出现在父用例出现的任何位置

关系名称 事件流类型 含义 面向用户

包含 扩展 泛化 子事件流 扩展事件流 公共事件流 表示两个以上用例共用的子事件流 抽取出优先级较低的扩展事件流 抽取多个用例之中的共性 开发团队 客户 开发团队 参与者之间的关系：只有一种，即泛化。

应用举例：

系统功能：以Internet的形式向客户提供座位预订的服务，并且如果暂时无法获取座位信息时，允许客户进入“等侯队列”，当有人退订之后将及时通知客户。另外，该系统还将为总台服务员提供座位的安排，以及结账的功能，要求能够支持现金和银行卡两种结账方式。

39、业务流程为主线的分解结构

业务流程为主线的分解结构：

这种结构是以业务流程为主线索的，也就是按“事”的角度进行分解。它对于联机事务处理系统、管理信息系统而言是非常适用的方法。 程序结构为主线索的分解结构：

适用于问题域不复杂，或者系统与问题域关联性不强的情况下，例如工具软件、面向设备的嵌入式系统等 基于场景的分解结构 对于决策支持系统、面向用户的嵌入式系统而言，决策场景、使用场景就是主要的线索。向上可以总结成一类相似的集合，再总结成一系列的关注点或功能域；而向下可以分成具体的决策步骤或操作任务。 基于数据的分解结构

适用于数据仓库之类的数据类项目。对于诸如数据仓库之类的数据类项目，“事”这条线索并不明显，或者并不重要，这时就需要采用以数据为主线的分解结构。

40、流程的层次

对部门级流程的抽象概括

需求分析的主线索，流程分析的主要输出

填充需求细节

41、部署图

部署图：表示该软件系统如何部署到硬件环境中。它的用途是显示该系统不同的组件将在何处物理地运行，以及它们将如何彼此通信。也就是说部署图描述系统硬件的物理拓扑结构以及在此结构上执行的软件。它可以显示计算机节点的拓扑结构和通信路径、节点上运行的软件构件等。

关键组成部分：节点、连接、构件、接口

节点：代表一类运行时的计算资源（例如：一类服务器、一类工作站、一个PC终端、一个打印机、一个传感器等）。

连接：表示两个节点之间的物理连接，用一根实现表示（关联关系）

图X 部署图示例2

42、非功能需求

对产品功能描述的补充。是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性。

43、软件需求规格说明书编写

常见的描述风格：

自然语言：

优点：易于编写、易于阅读，不用掌握特定的技能， 缺点：不够严谨，歧义性强，表述力差 图形化模型

优点：可视性、聚集性

缺点：要求编写和阅读人都能够正确地理解模型 形式化规格描述

优点：严谨、精确

缺点：编写和阅读人都会感觉很困难，易产生理解歧义 根据不同项目、软件开发团队的特点，选择不同的风格组合。 模板类型（3种）： 国标/ISO版本：该标准由1988年制定，于2006年发布了新的版本

RUP版本：其主要采用模型为主的思路，文字部分的模板显得有点过于简单，无法涵盖所有需要的内容

咨询商版本：比较追求通用性，有时难免出现“大而全”的弊端。典型代表：Volere 写作策略与技巧：

软件需求规格说明书是应用文，不强调优美的辞藻、工整的句子，而是强调信息的有效传递！

需求描述的两大原则：

简洁、段落文字少列表、图表相结合的表示法

44、需求评审

同级桌查/轮查：是个人级的评审方法，是需求人员之间私下进行的交叉审查。 桌查：两位需求人员之间交换文档产物，互相提出意见 轮查：多位需求人员之间交叉交换文档产物，互相提出意见 临时评审：

通常是个人的工作习惯。最常见、最简单的临时评审是在沟通过程中，由信息的接收者向信息的传达者做简要的、概括性的回顾，以期达成共识。 审查过程概述：

评审活动的直接目的：是找出软件需求规格说明书中的问题，但更有价值、更有意义的是解决问题，并且避免它。

解决问题：我们必须对提出的问题是否解决进行跟踪、督促

避免问题出现：对所有问题都应该进行分类、因果分析、找到出现这些问题的深层次原因

本文来源：https://www.bwwdw.com/article/czf7.html