需求分析综述

一、软件需求概述

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

质量成本时间

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

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

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

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

3．理解需求文档的重要性。

（1）项目交接时不用做重复工作

（2）哪怕需求明确无误并构思准确，如果我们没有编写文档，软件也达不到期望目标。

（3）需求文档恢复设计人员提出的各类问题

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

（1）深入理解用户的真正的意图和需要
（2）清晰完整的需求表达
（3）借助需求分析工具，E-R图、DFD图、DD、UML工具等等
（4）使用科学的需求管理方法，完善需求变更控制流程

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

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

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

借助当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题

（1）通过对现实环境的调查，获得当前系统的物理模型。

（2）去掉具体模型的非本质因素，抽象出当前系统的逻辑模型

（3）分析当前系统与目标系统的差别，简历目标系统的逻辑模型。

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

（1）错误的需求浪费了人力、物理、浪费金钱

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

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

（4）增加开发的成本

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

（1）无足够的用户参与

（2）用户需求的不断增加，无法控制

（3）许多模棱两可的需求

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

（5）忽略了用户分类

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

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

一致性和全面性，又引申为8个因素

【1】无歧义因素【2】完整性因素【3】一致性因素【4】可检验性因素【5】确定性因素【6】可跟踪因素【7】可行性因素【8】必要性因素

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

【1】业务需求：反映了组织机构或客户对系统、产品的高层次的目标要求，他们在项目视图与范围文档中予以说明

【2】用户需求：描述了用户使用产品必须要完成的任务，使用用例文档或场景描述予以说明

【3】功能需求：定义了开发人员必须实现的软件功能使得用户能完成他们的任务，从而满足了业务需求和用户需求。

【4】非功能需求：描述了系统展现给用户的行为和执行的操作的特性。

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

需求路线图：了解从用户需求到软件需求的一般路径，即从问题领域转向解决方案领域

二、软件需求工程及其过程

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

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

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

【1】建立基线：迅速制定需求文档的主体

【2】需求跟踪

【3】变更控制

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

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

【1】瀑布模型，计划、需求分析、设计、编码、测试、运行和维护

【2】RAD（快速应用开发）模型，是线性模型的高速版，基于构件开发。需求计划、用户描述、构建、结束

【3】螺旋模型，螺旋模型加入了风险分析，制定计划、风险分析、实施工程、评估

【4】RUP，是一套软件工程方法的框架，各个组织可以根据自身的实际情况进行裁剪和修改

【5】

4．理解RUP二维开发模型。

横轴通过时间组织，是过程展开的生命周期特征，提现开发过程的形态结构

纵轴以内容组织，为自然的逻辑活动，提现开发过程的静态结构

分为：初始阶段，细化阶段，构造阶段，交付阶段。

每个阶段实质上是两个里程碑之间的时间跨度，如果评审结果令人年满意的话，可以允许项目进入下一个阶段

RUP的特点：

【1】开发复用，减少开发人员的工作量，保证软件质量。

【2】可降低风险

【3】对需求进行有效的管理

【4】可视化建模

【5】使用组织体系结构使软件体系架构更具弹性

【6】贯穿整个开发周期的质量检查

【7】对软件开发的变更控制

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

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

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

（1）定义愿景和范围

（2）确定用例

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

【1】需求获取【2】需求分析【3】需求规格说明【4】系统建模【5】需求确认【6】需求管理

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

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

（2）面向数据，强调数据结构，如E-R模型

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

（4）面向对象，建立在对象间的交互基础上

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

职责

（1）收集，整理，分析，提炼，跟踪，控制用户的产品需求。

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

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

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

技能

（1）协调能力（2）观察能力（3）写作能力（4）组织信息能力（5）人际交往能力（6）建模能力

三、软件需求获取

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

【1】识别系统用户【2】用户调研与访谈【3】访谈结果整理【4】访谈结果呈现

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

明确双方权利和义务

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

需求规格说明书

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

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

5．对于MIS系统，通常情况下怎么样的需求，其优先级比较高？

（1）关键任务需求、基础性的数据处理要求，完不成此版本或下一版本需求就不能实现；只有这些需求实现后，客户才能接受软件。关键任务需求优先级为高
（2）业务流程处理中比较繁琐、容易出错，客户特别希望能改进、简化工作量、提高效率的业务需求，此类业务需求优先级为中
（3）客户的主管领导比较关心、容易得到领导认可的业务需求，此类业务需求优先级为中
（4）最后才是某些非功能类需求，实现或不实现均可的，一般此类业务需求优先级为低

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

作为客户认可需求的标志，简历需求协议的基线

7．项目的范围说明主要应该包括可哪些方面的内容？

（1）项目目的的合理性说明：

（2）项目目标

（3）项目可交付成果清单

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

（1）被提议的需求明显在范围之外

（2）需求显然是在定义好的项目范围之内

（3）不再范围内，但是它很有价值，因而需要对项目范围做出调整以容纳这一新的需求

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

（1）明确项目用户需求的来源
（2）明确使用该产品（软件）的不同类型的用户
（3）与不同用户类的代表进行沟通
（4）遵从项目的最终决策者的意见

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

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

【4】现有系统的问题报告和改进要求【5】市场调查和用户问卷调查【6】观察用户如何工作

【7】用户工作的情景分析

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

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

（1）为构造客户和开发人员之间的伙伴关系提供了有效途径
（2）是他所属用户类的成员与项目的需求分析员之间的主要联系人

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

（1）如果是个别用户之间的分歧，则由用户代言人来裁决
（2）用户经理表述的需求和其部门中实际用户的需求相矛盾。此时应该服从于用户代言人
（3）开发人员对产品的想法与客户的要求不一致，此时应当服从客户
（4）如果不同的用户类或客户群提出的需求发生冲突时，应支持最重要的用户类或对产品的商业前景影响最大的客户群提出的需求
（5）不同的企业客户有不同的需求。依据项目的业务目标来确定哪些客户对项目的成败影响最大

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

（1）用户访谈

（2）收集和研究资料

（3）调查问卷

（4）实地观察

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

问卷调查：【1】优点：大量发放、快速、低成本、保护隐私，便于归纳整理【2】问卷不够灵活，信息质量难于保证

用户访谈：【1】优点：*沟通，可以更深层次地挖掘用户需求，允许提问一些个性化的问题【2】缺点：占用时间比较多，访谈后的资料需要整理

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

业务规则：在特定条件下才能执行某一动作。如果一个药剂师在危险化学制品培训方面是可靠的，那么他就可以在一级危险药品清单上订购化学制品。

外部接口需求：描述了系统与外部世界的联系，比如：从某些设备上读取信号

约束：必须使用XX数据库

数据定义：描述某个数据项的格式、类型、允许值和缺省值

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

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

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

主执行者：提出请求的相关人员叫做主执行者，发起系统的一次交互来实现某个目标

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

四、结构化的需求分析与建模

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

模型：为了理解事物而对该事务做出的一种抽象，在软件工程中的模型由一组图形符号和组织这些符号的规则组成。

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

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

（1）帮助系统分析员理解系统的信息、功能和行为，使得需求分析任务更加容易实现，结果更加系统化。

（2）是评审焦点，是确定SRS完整性、一致性和精确性的重要依据

（3）是设计的基础，是软件要素的表示视图

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

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

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

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

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

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

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

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

五、面向对象分析与建模

1．UML是由什么构成的？

视图、图、模型元素、通用机制

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

（1）用例图描述角色与系统中的用例关系
（2）类图描述类及关系
（3）对象图类对象实例
（4）状态图描述类对象的状态及引起状态变化的事件，对类的补充
（5）序列图反映若干对象之间的动态协作状态，随时间流逝，对象间如何交互的
（6）协作图描述对象的关系及传递的消息
（7）活动图反映一个连续活动流，显示动作和结果，尤其能表示并发和同步
（8）组件图反映代码的物理结构
（9）包图多个组件组合成包图
（10）布署图描述系统软件和硬件的物理架构

3．可以根据场景画出活动图和序列（时序）图。

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

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

5．用例间的关系有哪些？理解它们间的关系。

（1）包含、扩展、泛化

6．能够根据背景材料，画出用例图。

7．理解包图的作用。

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

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

（1）用例模型包括用例图和用例规约

（2）用例规约的组成：

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

b. 事件流：包括基本事件流和异常事件流

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

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

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

9．理解并能说明原型法的工作流程。

①用户提出要求 ②识别归纳问题 ③开发系统原型 ④分析评价 ⑤不可行处理 ⑥不满意处理 ⑦修改 ⑧试运行

10．理解原型法的流程图。

六、需求分析文档编制

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

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

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

（1）文档、图形化模型、形式化规格说明

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

（1）对节、小节和单个需求的标记格式必须一致
（2）灵活地使用各种可视强调标志
（3）创建目录表，也许还需要创建索引，这有助于读者找到他们所需要的信息
（4）对所有图和表进行编号，并且给出标题，根据编号来引用这些图和表
（5）使用合适的模板来组织所有的必要信息

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

（1）需求标识方法：
a. *** ：如UR-2,SRS13
b. 层次型编号：如“第3.2.5部分—编辑功能”
c. 层次型文本标签：如“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。”被标识为“PRINT.COPIES.CONFIRM”

5．理解TBD的含义。

（1）使用TBD符号（待定）作为标准指示器来强调软件需求分析规格说明书中这些需求的缺陷
（2）把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目

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

（1）引言、总体描述、系统特性、外部接口需求、其他非功能性需求、其他需求、附录A：术语表、附录B：分析模型、附录C：待确定问题的清单

7．能根据软件需求编写原则，改进需求内容的表述。

七、需求验证与评审

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

（1）软件需求规格说明正确描述（无二义性和模糊内容）了预期的系统行为和特征
（2）从系统需求或其它来源中得到软件需求
（3）需求是完整的和高质量的
（4）对需求的看法是一致的
（5）需求为继续进行产品设计、构造和测试提供了足够的基础

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

（1）正式的需求评审：遵循预先定义好的一系列步骤过程。正式评审内容需要记录在案，它包括确定材料、评审员、评审小组，对产品是否完整，对所发现的错误和所提出的问题的总结
（2）非正式的需求评审：把工作产品分发给许多其它的开发人员粗略看看,或者走过场似地检查一遍(walkthrough) ，执行者描述产品，且征求意见，不需要记录备案
a. 优点：培养其他人对产品的认识，并且有利于获得反馈意见
b. 缺点：非系统化的，不彻底的

3．理解并能画出审查过程阶段图。

4．理解各种评审员的角色。

（1）作者（介绍员）、调解者（主持者）、读者（评审员）、记录员

5．能根据案例背景，判断评审问题的原因。

6．为做好需求评审，能理解并举出七例以上的合理建议。

（1）分层次评审
（2）正式评审与非正式评审结合
（3）分阶段评审
（4）精心挑选评审员
（5）对评审员进行培训
（6）充分利用需求评审检查单
（7）建立标准的评审流程
（8）做好评审后的跟踪工作
（9）充分准备评审

八、需求管理

1．理解需求基线的含义和内容。

需求基线（baseline）是需求开发与需求管理的桥梁，需求管理包括在工程进展过程中维持需求基线集成性和精确性的所有活动。

（1）典型需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线

2．需求管理在CMM2中的目标是什么？通过什么来管理文档？

（1）其目标是：
a. 建立软件需求基线，供软件工程和管理使用
b. 软件计划、产品和活动同软件需求保持一致
（2）通过版本控制和变更控制来管理需求文档

3．理解并举例说明版本控制混乱导致的问题。

（1）版本控制的混乱，将导致项目管理的混乱，常见的情况是需求变更只通知了需求分析人员和设计人员，开发组仍然在根据变更前的版本编码、测试组根据变更前的版本测试

4．变更控制系统通常包括哪些内容？

（1）变更控制委员会CCB
（2）配置管理
（3）变更信息的沟通过程

5．理解RCM的过程及输出。

（1）过程及输出：
a. 记录变更日志
b. 分析需求变更对工作、产品的影响（质量等）
c. 估计变更请求所需的工作量，重新估计交付成果的进度
d. 估计增加或减少的成本
e. 得出评审结果
f. 若评审通过，则更改相应的工作产品，使其与变更的需求保持一致
g. 若评审未通过，将需求变更请求表及相应文档存档

6．举例说明与需求相关的风险

（1）无足够用户参与
（2）用户需求不断增加
（3）模棱两可的需求
（4）不必要的特性
（5）过于精简的规格说明
（6）忽略了用户分类
（7）不准确的计划

7．为什么需要需求跟踪？

（1）确保每一个需求被实现、被测试
（2）当需求变更发生时，确保影响分析的完备性
（3）跟踪需求的状态，了解进度情况
（4）复用：系统升级时，可借助需求跟踪矩阵复用旧系统的资产，如功能需求、设计、代码和测试用例
（5）在测试出错时，可借助联系链，有效分析相关的代码
（6）借助联系链，将相关文档、代码关联起来

8．理解需求的各种属性。

（1）需求创建时间、版本号、作者、需求来源、确认需求的客户代表、需求涉及的子系统、需求对应的产品版本号、需求状态、需求优先级、测试标准

9．需求状态一般有几种？理解其含义。

（1）已建议、已批准、已实现、已验证、已删除

需求分析 综述