《软件需求分析（第二版）》第 10 章——编写需求文档 重点部分总结

文章目录

前言

一、单选题

二、简答题

三、名词解释

总结

前言

本文是对《软件需求分析（第二版）》第 10 章——编写需求文档的重点部分总结。《软件需求分析（第二版）》计划共十七个章节，其他章节的内容请前往专栏内查看。

上节回顾：《软件需求分析（第二版）》第 7 章——聆听客户的需求 重点部分总结

一、单选题

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

A、需求分析最终结果是产生

B、可行性分析报告

C、需求规格说明书

D、设计说明书

2、需求分析中，开发人员要从用户那里解决的最重要的问题是（A）

A、让软件做什么

B、要给软件提供哪些信息

C、需求软件工作效率怎样

D、让软件具有何种结构

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

A、主要功能

B、算法的详细过程

C、用户界面的运行环境

D、软件性能

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

A、软件设计的依据

B、用户与开发人员对软件要做什么的共同理解

C、软件验收的依据

D、软件可行性研究的依据

5、软件需求分析阶段的工作，可以分成4个方面：需求获取，需求分析，编写需求规格说明书以及（B）

A、用户

B、需求评审

C、总结

D、都不正确

二、简答题

1、需求分析阶段的基本任务是什么？

需求分析的基本任务包括：

1.问题识别

(1) 功能需求：明确所开发的软件必须具备什么样的功能。

(2) 性能需求：明确待开发的软件的技术性能指标。

(3) 环境需求：明确软件运行时所需要的软、硬件的要求。

(4) 用户界面需求：明确人机交互方式、输入输出数据格式。

2. 分析与综合，导出软件的逻辑模型

分析人员对获取的需求，进行一致性的分析检查，在分析、综合中逐步细化软件功能，划分成各个子功能。用图文结合的形式，建立起新系统的逻辑模型。

3. 编写文档

(1) 编写“需求规格说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。

(2) 编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。

(3) 编写确认测试计划，作为今后确认和验收的依据。

(4) 修改完善软件开发计划。在需求分析阶段对待开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。

2、需求分析的目的是什么？难点在哪里？需求分析为什么特别重要？

需求分析的目的是解决系统是“做什么”的问题。

难点在于：

(1) 客户常常并非计算机专业出生，难以描述清楚需求。

(2) 需求自身经常变动。

(3) 分析人员或客户理解有误。

需求分析就是分析软件用户的需求是什么，如果投入大量的人力，物力，财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的。需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位。

3、假设现在由你来负责所在学校选课系统的需求工作，现在需要你来安排一次群体面谈，你打算怎么做？

（1）目标和内容的确定；

（2）场地的确定；解释场地的条件：提供各种开会需要材料，会议室、道具、餐饮等；

（3）时间的确定；解释时间要求：全职的2～4天；

（4）人员的确定；解释多涉众的共同参与；

（5）会议准备；准备会议讨论材料；议程。

4、需求获取常见的方法有哪些？

1）用户访谈

用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组合议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照——定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列以一个粗糙的想法，根据访谈的民体情况来进行发挥。

2）用户调查

在进行用户防谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈。因此，就需要借助用户调杏的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求倍息，这样就可以克服上述的问题。

用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。

3）现场观摩

俗话说，百闻石如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之合效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随用户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记；建造软件系统不仅仅只是为了模拟客户的手下操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作为软件设计的目标。

4）文档考古

文档考古是指对历史存在的—些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。

5）建立联合分析小组

在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。

用广提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获地。

6）原型法

原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷。建造这样一个系统的目的是为了看，考察某一方面的可行性。如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于文物的有效沟通，从而帮助人们尽早解决软件开发个存在的各种不确定性。

7）模型驱动

前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通道一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。

8）基于上下文的方法

软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在—定环境下表现出来的行为，通过分析用户的行为得到信息。

三、名词解释

1、需求基线

需求基线就是被明确和固定的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求的集合。

2、需求验证

需求验证是为了尽量不给设计、实现、测试等后继开发活动带来不必要的影响，对需求规格说明文档中定义的需求是否正确、准确地反应用户的意图进行验证的一个活动。

3、需求规格说明

需求规格说明就是将需求及其软件解决方案进行定义和文档化，并传递给开发人员的需求工程活动。

总结

本文对本章内容编写需求文档从单选题、简答题和名词解释方面进行了总结，如有疏漏和错误欢迎大家指正。另外其他章节的内容大家可以移步专栏进行查看。

我是白鹿，一个不懈奋斗的程序猿。望本文能对你有所裨益，欢迎大家的一键三连！若有其他问题、建议或者补充可以留言在文章下方，感谢大家的支持！

专家 云社区 开发者 软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。