需求分析思考题.doc

需求分析思考题.doc

《需求分析思考题.doc》由会员分享，可在线阅读，更多相关《需求分析思考题.doc（17页珍藏版）》请在冰点文库上搜索。

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

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

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

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

IEEE（电气电子工程师协会）软件工程标准词汇表中定义需求为：

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

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

（3）一种反映上面

（1）或

（2）所描述的条件或权能的文档说明。

对于这一定义的理解为：

（1）条件：

如CRM（客户关系管理）系统，有CALLCENTER、市场开发管理、销售管理、售后服务、统计分析、绩效分析等等模块，有满足市场人员进行客户关系管理的条件。

（2）权能（能力）：

系统的运算能力（速度和准确性）、系统平稳运行能力、系统可配置能力。

如，某一ERP系统，物料凭证到会计凭证的自动化，运算速度快、可靠性好。

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

案例一：

中途更换所有的开发者，这就使得客户需求从头开始；

重要性：

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

案例二：

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

重要性：

这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。

通过需求文档回复设计人员提出的各类问题。

依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。

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

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

②清晰完整的需求表达。

③借助需求分析工具，E-R图、DFD图、DD、UML工具等等。

？

使用科学的需求管理方法，

完善需求变更控制流程。

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

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

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

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

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

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

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

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

（4）增加开发的成本。

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

（1）无足够用户参与。

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

（3）模棱两可的需求。

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

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

（6）不准确的计划，往往低估开发时间。

9.好的软件需求特性有哪些？

理解其含义。

内涵一致，外延完整。

具体包含两个特征：

一致性和全面性。

引申为9个因素：

（1）无歧义因素

（2）完整性因素（3）一致性因素（4）可检验性因素

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

（9）必要性因素

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

①软件需求包括不同的层次：

业务需求、用户需求、功能需求和非功能需求。

②业务需求反映了组织机构或客户对系统、产品的高层次的目标要求，它们在项目视图与范

围文档中予以说明。

③用户需求文档描述了用户使用产品必须要完成的任务，使用实例文档或场景描述中予以

明。

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

业务需求和用户需求

⑤非功能需求描述了系统展现给用户的行为和执行的操作等

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

需求路线：

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

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

涉众：

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

软件或系统项目涉众包括：

客户、用户、需求分析员、开发人员、测试人员、文档编制人员、项目经理、法律人员、生产人员、市场营销

特性：

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

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

9．什么是需求工程？

了解其组成示意图。

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

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

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

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

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

（3）使当前的项目计划与需求一致。

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

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

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

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

软件产品经历需求、分析、设计、实现、部署后，软件将被使用并进入维护阶段，直到最后逐渐消亡。

这样一个过程，叫软件生命周期模型。

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

（第二章第22页ppt）

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

需求情况

瀑布模型

螺旋模型

RAD

迭代模型

需求容易定义或明确吗？

是

否

是

否

能在早期确定需求吗？

是

否

是

是

周期中需求经常变化吗？

否

是

是

是

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

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

注：

这是我自己翻译的结果，大家可以自己具体看看第2章的29页，可能会有更加准确的翻译。

1定义愿景和范围

2标识用户类

3标识用户代表

4标识需求决策者

5选择启发式技术

6标识用例

7排序用例

8开发用例

9指定质量属性

10导出文档的功能需求

11需求建模

12审查需求规格

13开发原型

14设计架构

15给组件分配需求

16开发测试用例

17确认用例，功能需求，分析模型，原型

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

需求获取

需求分析

需求规格说明

系统建模

需求确认

需求管理

使用的需求环境：

瀑布模型

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

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）8建模能力

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

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

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

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

合作关系建立的前提：

明确双方权利和义务

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

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

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

需求分析员应使用不同的示意图来配合SRS文本对需求进行描述。

客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。

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

2.关键任务需求、基础性的数据处理要求，完不成此版本或下一版本需求就不能实现；只有这些需求实现后，客户才能接受软件。

关键任务需求优先级为高。

（2）业务流程处理中比较繁琐、容易出错，客户特别希望能改进、简化工作量、提高效率的业务需求，此类业务需求优先级为中。

（3）客户的主管领导比较关心、容易得到领导认可的业务需求，此类业务需求优先级为中。

（4）最后才是某些非功能类需求，实现或不实现均可的，一般此类业务需求优先级为低。

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

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

②开发经理把签字作为冻结需求的方法。

③签字不仅仅是仪式，更重要的是建立需求协议的基线。

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

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

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

③项目可交付成果清单

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

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

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

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

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

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

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

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

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

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

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

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

③系统需求规格说明

④现有系统的问题报告和改进要求

⑤市场调查和用户问卷调查

⑥观察用户如何工作

⑦用户工作的情景分析

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

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

①为构造客户和开发人员之间的伙伴关系提供了有效途径。

②是他所属用户类的成员与项目的需求分析员之间的主要联系人。

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

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

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

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

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

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

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

①用户访谈②收集和研究资料③调查问卷④实地观察，即深入现场,跟班作业

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

问卷调查：

优点：

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

缺点：

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

用户访谈：

优点：

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

缺点：

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

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

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

“如果一个药剂师在危险化学制品培训方面是可靠的，那么他就可以在一级危险药品清单上订购化学制品”

“图书馆的借阅者最多可以同时借10本书。

”

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

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

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

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

数据定义：

“邮政编码”“物料序号”

17理解和说明用例法中的相关概念：

用例、角色、主执行者、场景。

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

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

③提出请求的相关人员叫做主执行者

④根据执行者作出的请求和请求涉及的条件，系统将执行不同的行为序列，每一行为序列

称之为一个场景。

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

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

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

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

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

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

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

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

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

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

5----9题ppt上面有很多的实例

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

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

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

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

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

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

11．UML是由什么构成的？

视图（views）、图（diagrams）、模型元素（Modelelements）、通用机制（generalmechanism）等构成。

12．UML用到的图包括哪些？

理解各图的作用。

名称作用

用例图 描述角色与系统中的用例关系

类图 描述类及关系

对象图 类对象实例

状态图 描述类对象的状态及引起状态变化的事件，对类的补充。

序列图 反映若干对象之间的动态协作状态，随时间流逝，对象间如何交互的。

协作图 描述对象的关系及传递的消息

活动图 反映一个连续活动流，显示动作和结果，尤其能表示并发和同步

组件图 反映代码的物理结构

包图 多个组件组合成包图。

布署图描述系统软件和硬件的物理架构

13．可以根据场景画出活动图和序列图。

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

执行者、用例、用例与执行者的关系（通信关联：

执行者与执行的用例之间存在通信路径。

）、

用例与用例的关系

15．用例间的关系有哪些？

包含、扩展、泛化

16．能够根据背景画出用例图。

17．理解包图的作用。

UML包图是表示顶层架构的适当机制。

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

18．用例模型包括什么？

用例规约由什么组成？

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

用例规约的组成：

简要说明：

介绍该用例的作用和目的。

事件流：

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

特殊需求：

非功能性需求和设计约束

前置条件：

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

后置条件：

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

19．软件顶层架构有哪四种模式？

客户/服务器模式

模型－视图－控制器模式

分层模式

流程处理模式

20．什么是类图？

类图中类的关系有哪几种？

UML类图是表示领域（指业务领域）概念模型的适当机制

类之间的关系：

实现：

如基类实现接口。

泛化：

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

关联：

类之间的相关性，包括聚集和组成关系。

依赖：

是关联的弱化。

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

①用户提出要求

②识别归纳问题

③开发系统原型

④分析评价

⑤不可行处理

⑥不满意处理

⑦修改

⑧试运行

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

（6）需求开发的最终成果是什么？

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

）

（7）表示软件需求最常用和最普遍的方式是什么？

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

（8）SRS指什么？

举例（四个以上）说明如何增强SRS的可读性。

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

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

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

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

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

（9）需求标识方法有哪几种？

各举一例。

需求标识方法：

1.序列号：

如UR-2,SRS13

2.层次型编号：

如“第3.2.5部分—编辑功能”

3.层次型文本标签：

如“当用户请求打印超过10个副本时，系统必须让用户进行确认判断。

”被标识为“PRINT.COPIES.CONFIRM”

（10）理解TBD的含义。

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

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

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

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

6.其他需求7.附录A：

术语表8.附录B：

分析模型9.附录C：

待确定问题的清单

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

（实例在ppt上）

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

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

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

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

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

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

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

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

正式的需求评审：

遵循预先定义好的一系列步骤过程。

正式评审内容需要记录在案，它包括确定材料、评审员、评审小组，对产品是否完整，对所发现的错误和所提出的问题的总结。

非正式的需求评审：

把工作产品分发给许多其它的开发人员粗略看看,或者走过场似地检查一遍（walkthrough），执行者描述产品，且征求意见，不需要记录备案。

优点：

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

缺点：

非系统化的，不彻底的

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

重写

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

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

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

（详细的例子在ppt第七章19-22页）

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

①分层次评审②正式评审与非正式评审结合③分阶段评审④精心挑选评审员

⑤对评审员进行培训⑥充分利用需求评审检查单⑦建立标准的评审流程

⑧做好评审后的跟踪工作⑨充分准备评审

第八章《需求管理》思考题

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

典型需求开发的结果应该有项目视图和范围文档、用例文档、软件需求规格说明及相关分析模型。

经评审批准，这些文档就定义了开发工作的需求基线。

34．需求管理在CMM2中的目标是什么？

通过什么来管理文档？

其目标是：

（1）建立软件需求基线，供软件工程和管理使用。

（2）软件计划、产品和活动同软件需求保持一致。

通过版本控制和变更控制来管理需求文档。

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

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

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

变更控制系统通常包括:

（1）变更控制委员会CCB

（2）配置管理

（3）变更信息的沟通过程

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

（1）记录变更日志

（2）分析需求变更对工作、产品的影响（质量等）

（3）估计变更请求所需的工作量，重新估计交付成果的进度（延后或提前多少？

）

（4）估计增加或减少的成本

（5）得出评审结果（通过否？

）

（6）若评审通过，则更改相应的工作产品（如软件），使其与变更的需求保持一致

（7）若评审未通过，将需求变更请求表及相应文档存档

38．理解IT项目风险管理定义与内容。

定义：

IT项目风险管理是指为了最好地达到项目的目标，识别、分析、应对项目生命周期

内风险的科学与艺术。

内容：

风险识别、风险量化、风险应对计划（含风险处理）和风险监控。

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

①无足够用户参与

②用户需求不断增加

③模棱两可的需求

④不必要的特性（如很“酷”但无实用价值的功能）

⑤过于精简的规格说明

⑥忽略了用户分类（如集团OA的推广）

⑦不准确的计划

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

①确保每一个需求被实现、被测试。

②当需求变更发生时，确保影响分析的完备性。

③跟踪需求的状态，了解进度情况。

④复用：

系统升级时，可借助需求跟踪矩阵复用旧系统的资产，如功能需求、设计、代码和测试用例。

⑤在测试出错时，可借助联系链，有效分析相关的代码。

⑥借助联系链，将相关文档、代码关联起来。

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

常用的需求属性包括：

①需求创建时间

②版本号

③作者

④需求来源

⑤确认需求的客户代表

⑥需求涉及的子系统

⑦需求对应的产品版本号

⑧需求状态

⑨需求优先级

⑩测试标准

（11）需求的稳定性

42．需求状态一般有几种？

五种，分别是：

（1）已建议

（2）已批准（3）已实现（4）已验证（5）已删除

43．了解需求跟踪矩阵的内容。

（具体例子在ppt第八章38-39页）

44．理解需求跟踪能力联系链。