软件需求分析真题精选文档格式.docx

软件需求分析真题精选文档格式.docx

《软件需求分析真题精选文档格式.docx》由会员分享，可在线阅读，更多相关《软件需求分析真题精选文档格式.docx（18页珍藏版）》请在冰豆网上搜索。

有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户，这些用户关于需求的目标互相冲突，需求工程师于是采用了模糊化的处理方法。

正确解决方法是在项目前景的指导下，促进用户之间的协商解决。

③信息遗漏。

信息遗漏也是一类常见的问题，包括明显的信息遗漏和不明显的信息遗漏。

明显的信息遗漏，其主要原因在于项目的范围定义不当，可以通过加强对业务需求的处理得以解决。

不明显的信息遗漏，是因为相关信息难以发现，只能靠需求工程师的经验来加以避免。

④不必要的需求。

产生不必要需求的原因主要是：

其一是用户将一些不必要的需求作为和开发人员谈判的筹码，然后通过自己对不必要需求的要求而在和开发人员的谈判当中取得真正想要的利益，例如金钱。

对此问题，唯一需要的就是开发人员代表的谈判技巧。

其二是用户在交流中，总是害怕信息有所遗漏，并因此产生不利后果，因此用户总是倾向于表达各种各样的需要。

要解决这个问题，就需要开发人员在进行用户需求的获取之前，先定义明确的业务需求，然后根据业务需求进行用户需求的过滤和选择。

其三是需求开发人员“画蛇添足”，添加“用户肯定会喜欢”的功能，该类功能既会造成项目额外的耗费，又不会给用户带来更多的帮助。

这就要求需求开发人员要保持以用户为中心。

⑤不切实际的期望。

不切实际的期望也是实践中常见的需求定义问题，而且它在很大程度上影响着项目的成败。

面对不切实际的期望，要求软件开发者提供可行性、成本等足够的技术参考信息，帮助用户对其进行取舍和调整。

2简要说明需求获取活动的过程。

（1）收集和应用背景资料，建立初始的知识框架。

分析涉众的高层次问题，总结出系统的业务需求。

（2）设计一个高层次的解决方案，并确定解决方案需要具备的系统特性。

高层次的解决方案和系统特性定义了项目的前景和范围。

（3）在项目的业务范围内，需求工程要寻找相关的涉众，并分析和涉众选择。

（4）对组织里存在大量的表格、单据等与业务相关的硬数据进行采样，它们是需求获取活动中一个重要的信息来源。

（5）针对某一次具体的需求获取活动，要依据项目范围确定主题和内容，涉众特征和硬数据，从而确定信息来源。

获取方法通常只有综合内容、来源和系统环境三者才能做出正确的决定。

在内容、来源和方法都确定之后，需求工程师就可以开展具体的获取活动，获取用户需求和问题域特性。

获取得到的具体信息要记录下来，以获取笔录的形式进行保存。

3需求获取

需求获取就是从人员、资料和环境中得到系统开发所需要的相关信息的过程。

4简述涉众识别的基本过程。

涉众识别的基本过程如下：

①将初始涉众集中起来，进行一次头脑风暴，尽可能地列出一个涉众类别列表。

②对上一步产生的涉众类别列表进行分析，判断它们和软件系统的相关性，找出其中的键涉众类别。

③为上一步的各个关键涉众类别选择代表，集中起来进行进一步的头脑风暴，列出新的涉众类别列表。

如果新列出的涉众类别列表趋于稳定，就可以结束涉众识别过程。

如果新列出的涉众类别列表有了新的发现，就提交新的涉众类别列表，转向第②步。

5试比较面谈问题组织的三种结构。

（1）金字塔结构

面谈问题的归纳式组织被看做是金字塔形状。

使用这种形式时，会见者以很具体的问题（通常是封闭式的问题）开始，然后逐渐提高问题的开放度，同时允许被会见者用越来越笼统的答案来回答问题。

在主动的情况下，如果会见者认为被会见者需要对话题进行预热，可以采用金字塔结构，通过逐步的引导使被会见者进入讨论。

在被动的情况下，如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论某个话题，也可以采用金字塔结构。

在某个话题讨论结束的时候，使用金字塔结构的提问顺序也是有用的。

（2）漏斗结构

在这种结构中，会见者使用演绎的方法，以一般的、开放式的问题开始，然后用封闭式的问题缩小可能的答复。

这种面谈结构可看做是漏斗型。

在主动的情况下，漏斗结构为开始一场面谈提供了一种容易而轻松的途径。

答复者即使答错了开放式问题，也不会感到压力。

在被动的情况下，当被会见者对话题有情绪，并且需要自由表达这些情绪的时候，需要采用漏斗型提问顺序。

或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组织方式。

使用漏斗结构的一个好处是：

用这种方式组织面谈能得出很多的详细信息，以至于没有必要使用长序列的封闭式问题。

（3）菱形结构

人们在面谈中常常会将上述两种结构结合起来使用，其中菱形结构就是一种最好的结合结果。

这种结构以一种非常明确的方式开始，然后考察一般问题，最后得出一个非常明确的结论。

会见者首先提出一些简单的、封闭式的问题，为面谈过程做好铺垫。

在面谈的中间阶段，向被会见者提出明显没有“正确答案”的一般话题的看法。

然后，会见者再次限制问题以获得明确的答复，这样就为会见者和被会见者提供了面谈的结束时机。

菱形结构结合了其他两种结构的长处，但是也有缺点，即所花的时间比其他任何一个都长。

6需求规格说明

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

7需求基线

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

8简述软件开发中为何使用原型工具以及使用的好处。

因为原型是在最终系统产生之前的一个局部真实表现，所以原型方法可以让人们在系统的开发过程中，就能够对一些具体问题进行基于实物的有效沟通，从而帮助人们尽早解决软件开发过程中存在的各种不确定性。

不确定性是指人们已经拥有的知识是不充分的，不足以预测将来的事件发展，或者不足以清晰、准确地描述某个事物。

实践证明，利用原型有如下好处：

①及时、有力地响应用户需求的变化。

②减少返工。

③帮助控制不完整需求所带来的风险。

④可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤。

⑤减少开发成本，提高经济效益。

⑥增加开发者之间的交流，帮助确定技术解决方案的可行性。

⑦有效地识别风险和解决风险，帮助进行风险管理。

⑧提高用户在软件开发中的参与程度。

9需求验证

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

10试说明在哪些情景下原型法可以帮助需求工程师及早解决需求的不确定性。

①产品以前从未存在过，而且难以可视化。

这些产品属于创新性产品，它们的基本需求是潜在的，有着很大的不确定性。

②产品的用户对相关类别的产品没有经验，而且对将要采用的技术也没有经验。

此时用户无法明确工作的具体细节，产品的细节需求存在着不确定性。

③用户进行自己的工作已经有一段时间了，但在完成工作的方式上仍然存在障碍。

此时用户无法判断问题的解决方案是否现实可行，所以产品在整体方案的可行性上存在着不确定性。

④用户在清晰说明他们的需求方面存在困难，例如默认需求或者潜在需求。

这些相关的需求是有着不确定性的需求。

⑤需求工程师在理解用户的需求上存在困难。

在澄清和理解之前，这些需求存在着不确定性。

⑥需求的可行性值得怀疑，即具体需求的可满足性存在着不确定性。

11什么是需求分析？

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

需求分析：

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

基本任务：

⑴问题识别：

双方确定对问题的综合需求，这些需求包括功能需求，性能需求，环境需求，用户界面需求。

⑵分析与综合，导出软件的逻辑模型。

⑶编写文档：

包括编写"

需求规格说明书"

，"

初步用户使用手册"

确认测试计划"

修改完善软件开发计划"

。

12试比较原型开发方法的三种类型。

（1）探索式

探索式原型法是以缺陷需求开始继而不断调整和修正需求的原型开发方式。

探索式的原型方法通常要尽可能地调整各种设计选项（例如需求内容、软件化内容以及软件支持方式等），并比较多种设计方案下的用户反馈以得到理想的用户需求。

探索式的原型方法能够帮助开发者更深入地了解用户的业务、问题和期望。

（2）实验式

实验式的原型方法初始时拥有清晰的用户需求，但是开发者对这些需求的实现方法、实现效果和可行性没有太大的把握。

实验式的原型方法需要首先定义一个对原型的评估方法，确定评估的属性（例如可行性、适用性、效率、吞吐量等），据此评估各种技术方案下的原型，明确需求的可行性和有效的技术实现方案。

（3）演化式

在演化式的原型方法中，原型的开发并不是一个独立的活动，而是整个项目的持续开发过程中的一个部分。

原型开发的初始点既有要求原型化的需求，也有项目积累下来的原型资产。

积累下的原型资产所没有实现的需求，往往是清晰的需求。

在开发原型时，还要能够以一个整体的方式传递给下一个原型开发过程。

这个被不断传递和不断增强的原型资产将成为最终的软件系统。

通过在持续开发过程中使用原型方法，可以使软件开发过程更好地处理用户需求的不断变动。

在探索式、实验式和演化式这三种原型方法中，前两种方法产生的原型往往是在经历

了很多次错误的尝试之后才产生的。

这些错误的尝试过程会在最终的原型产品中留下痕迹，原型中的一些代码是在错误的前提（错误的需求、错误的技术方案）下完成的，它们会使原型产品具有很差的质量，所以人们在得到正确的尝试之后往往会抛弃这些原型产品，另起炉灶。

为此，探索式和实验式方法产生的原型产品又被称为抛弃式原型（ThrowawayPrototype）。

抛弃式原型的贡献不在于它的代码，而是它所包含的内容，它说明了正确的需求和正确的技术方案。

因为抛弃式原型的代码是要被抛弃的，所以在建立抛弃式原型时，应该尽量花费最小的代价，争取最快的速度。

为此，原型的开发者会使用一些简易的开发工具和不成熟的构造技术，忽略或简化一些和原型目标不相关的功能特征。

13试述在需求获取中使用原型方法的主要步骤。

在需求获取中使用原型方法的主要步骤包括：

①确定原型需求。

搞清楚为什么要开发原型，拥有的起始点是什么，期望的结束标准是什么。

②原型开发。

依据原型的需求特点和开发目的，选择原型的开发方法和构建技术，建立初始原型。

③原型评估。

对上一阶段产生的原型进行评估，根据评估者的反馈判断原型是否满足结束标准。

评估者一般是用户和开发者。

④原型修正。

如果已经建立的原型