软件工程科学出版社郑逢斌主编第4章需求工程课后习题答案

最新推荐文章于 2022-12-21 01:33:18 发布

i_Umbre

最新推荐文章于 2022-12-21 01:33:18 发布

阅读量506

点赞数 1

文章标签：软件工程需求分析

本文链接：https://blog.csdn.net/m0_51658788/article/details/128364185

版权

软件工程科学出版社郑逢斌主编第4章需求工程课后习题答案

1. 什么是需求工程?需求工程包括哪些活动?

定义：建立并使用完善的工程化方法 , 以较经济的手段获得准确表达用户需求的软件需求规格说明的一个学科。
输出：软件系统的需求规格说明

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统，及其行为特征和相关约束，形成需求文档;并对用户不断变化的需求演进给予支持。
一个良好的需求开发过程应该包括需求获取、需求分析与建模、编写需求规格说明书和需求评审4个主要活动。

2.需求分为哪些层次?

业务需求
业务、客户、特性、优先级、价值
用户需求
从用户角度对系统功能需求和非功能需求进行的描述，通常只涉及系统的外部行为，而不涉及系统的内部特性。
它在使用实例(Use Case)文档或方案脚本(Scenario)说明中予以说明
功能需求
功能性需求
What：“系统做什么”
非功能性需求
How：“系统做的怎么样”

3.指出下列需求描述的不当之处，并进行改写，使之符合好需求特性。

(1)产品应在不少于60秒的正常周期内提供状态信息。

系统应该以误差上下部超过1秒的10秒间隔，在用户界面的指定位置显示状态信息
如果显示状态信息有错误，应提示错误信息“系统错误”
分析:
这个需求是不完整的:状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分?状态信息间隔真的假定为不少于60秒?，甚者每10年显示一条新的状态信息也可以?也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短?“每”这个词导致了不确定性。问题的后果，就是需求的不可证实弥补缺陷，重写需求的一种方法:后台任务管理器因以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息;
如果后台进程处理正常，那么应该显示任务已完成的百分数/比:任务完成时，应显示相关的信息;后台任务出错应该显示错误信息;
为了测试和追踪，将需求分解多个子需求。使在构造和测试时，被易于分别执行。

(2)HTML分析器可以产生 HTML标记错误报告，帮助HTML入门者快速解决问题

HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告

单词“快速”使其模糊，没有加进错误报告的定义也是不完整的。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误?
试试这个:
“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”
现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外: 如果没有发现错误，不产生错误报告

(3)产品应瞬间在文本中的显示和隐藏不可打印字符间切换。

计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己?或者用户为了模仿更改要做一些什么动作?而且，在文档中改变显示的范围是多大:选中的文本?整个的文档，或其他的?这也是个模糊的问题。不可打印字符和隐藏字符一样吗?或者是一些属性标志或一些控制字符?问题的后果，就是需求的不可证实。
像这样编写需求也许更好一些:
用户能够在一个由特定触发条件激活处于编辑的文档中在显示和
隐藏所有HTML标记间切换。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

4.对于一个小型图书馆管理系统，试给出非功能需求的描述。

软件的非功能性需求包括:可靠性、可用性、有效性、可维护性和可移植性.其中，在可靠性方面可以考虑平均无故障时间、平均修复时间 (Mean Time to Repair，MTTR)是多少，复制和故障转移的方案是什么，系统出现故障时是否需要手动干预，系统的安全性如何等。可用性方法可以考虑系统是否为用户带来不适当的负担(如需要特殊浏览器等)，系统是否每天24小时，每年365天不间断提供服务等。

5.需求工程过包括哪些主要活动?

需求开发过程应该包括
需求获取、
需求分析与建模、
编写需求规格说明书
需求评审
4 个主要活动。

6有哪两种主要的需求分析模型? 它们的主要思想是什么?

建模：应用模型来表达需求
分析：基于模型进行一致性、完整性等分析
两种常见的建模与分析方法：
结构化需求建模与分析
数据流图（Data Flow Diagram ，DFD）
数据字典(Data Dictionary，DD)
加工说明（Process SPECification，PSPEC）
状态变迁图（State Transition Diagram，STD）
实体-关系图（Entity Relationship Diagram，ERD）
面向对象需求建模与分析
功能模型：由用例图表示；
分析对象模型：由类图和对象图表示；
动态模型：由状态图和顺序图表示。

7.需求规格说明书的主要作用是什么?应该包括哪些主要内容?

作用:
(1) 作为用户方和开发方之间的合同，为双方相互了解提供基础。
(2)反映问题的结构，作为系统设计和编码的依据。
(3)作为测试和验收目标系统的依据
内容:
用户可以通过需求规格说明书检查需求描述是否满足原来的期望。设计人员根据软件需求规格说明书的描述了解所需开发软件的功能和性能，以及开发软件时必须满足的约束，将其作为软件设计的依据。测试人员根据软件需求规格说明书中对产品的描述，设计测试计划、测试用例和测试过程。产品发布人员根据软件需求规格说明和用户界面设计编写用户手册和帮助信息