软件需求工程 期末复习资料

一般定义：指应用工程化的方法、技术和规格来开发和管理软件的需求。 需求工程的目标： 获取高质量的软件需求。

与软件工程中传统的需求分析概念相比，需求工程突出了工程化的原则，强调以系统化、条理化、可重复化的方法和技术进行与软件需求相关的活动，从而有利于提高所有与软件需求相关的活动及其过程的可管理性，降低需求开发和管理的难度和成本。 其它定义：

Alan.Davis： 直到（但不包括）把软件分解为实际架构组建之前的所有活动，即软件设计之前的一切活动。该定义虽然没有详细说明需求工程是什么，但其给出了需求工程的范围。 Lan K. Bray：对问题域及需求做调查研究和描述，设计满足那些需求的解系统的特性，并用文档给予说明。这个定义明确指出了需求工程的任务就是获取、分析和表达软件的需求。 需求工程 = 需求的开发活动 + 需求的管理活动 2 各阶段主要任务

需求获取阶段：获取用户的需求信息。

需求分析阶段：分析和综合已经收集到的需求信息。

需求建模阶段：根据待开发软件系统的需求利用某种建模方法建立该系统的逻辑模型。 需求定义阶段：根据用户需求编写出需求规格说明。

需求的形式化描述阶段：用严格的数学知识和符号来构造系统的需求模型。 需求验证阶段：检验软件需求规格说明。 需求管理阶段：开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影响及可能的成本及费用，然后实施更改，一级有效的管理需求规格说明文档和跟踪更改需求的状态。

☆ 什么是软件需求？软件需求有哪些类型，并分别给出它们的定义。 p2 软件需求的定义:

A. Davis：软件需求是从软件外部能发现的，软件所具有的，满足于用户的特点、功能及属性等的集合。

I. Sommerville：需求是问题信息和系统行为、特性、设计和实现约束的描述的集合。 M. Jackson等：需求是客户希望在问题域内产生的效果 。 IEEE软件工程标准：

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

（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 通俗定义 ：软件需求是指软件系统必须满足的所有功能、性质和。 软件需求的类型: 目标需求：反映组织机构或客户对系统和产品提出的高层次的目标要求，其限定了项目的范围和项目应达到的目标。

业务需求：主要描述软件系统必须完成的任务、实际业务或工作流程等。软件开发人员通常可从业务需求进一步细化出具体的功能需求和非功能需求。

功能需求：指开发人员必须实现的软件功能或软件系统应具有的外部行为。

性能需求：指实现的软件系统功能应达到的技术指标，如：计算效率和精度，可靠性，可维护性和可扩展性等。

约束与：指软件开发人员在设计和实现软件系统时的，如：开发语言，使用的数据库等。

☆ 试述快速原型开发模型和面向对象开发模型的基本思想，然后说明快速原型开发模型中抛弃型模型和进化型模型的作用。 p9 快速原型模型基本思想：快速建立一个实现了若干功能的（不要求完全）可运行模型来启发、揭示和不断完善用户需求，直到满足用户的全部需求为止。其基本过程如下： 收集需求快速设计建立原型评价并细化需求设计与实现测试维护 面向对象开发模型基本思想：

应用对象、类、继承、封装、消息、对象或类之间的关系等面向对象的概念对问题进行分析和求解的软件开发技术，或者说，是以对象（类）为数据中心、对象之间的动态行为模式作为运行机制的一种问题求解方法。其基本过程如下： 面向对象分析面向对象设计面向对象实现和测试系统维护

抛弃型模型：指在原型达到预期目的后将其抛弃，而且在构建该原型时，可以忽略具体的软件构造技术，亦即应以最小的代价构造抛弃型原型。

进化型模型：在需求被清楚定义的情况下，以渐增式方式构建原型，并使原型最终能成为软件产品的一部分。

☆ 请指出下列陈述属于哪种类型的软件需求或不属于软件需求。 p26 （1）只有电梯停在某一楼层时，电梯才能改变方向。 非功能

（2）系统必须用三个主要模块来实现，即检测、记录和统计分析模块，每个模块各自实现一个主要功能。 功能性需求

（3）当用户输入他们的口令后，系统便自动从口令文件中检索他们的加密口令，并进行核对。 功能性需求

（4）通过对用户进行不到一个小时的培训后，用户能输入和打印某些数据，且输入/出的出错率低于1/20。 非功能

（5）所有报销单据必须经过财务部门某负责人审核后才能交由系统处理。 非功能 （6）系统必须用面向对象的方法和技术实现。 非功能

☆ 下列需求是否含糊，如果含糊的话，请在说明理由后给予修改： p84

（1）系统必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于60秒。 含糊。需求不完整，导致需求不可验证。改进如下：

后台任务管理器(BTM)应该在用户界面的指定区域显示状态消息。

a.在后台任务进程启动之后，消息必须每隔60(10)秒更新一次，并且保持连续的可见性。 b.如果正在正常处理后台任务进程，那么后台任务管理器(BTM)必须显示后台任务进程已完成的百分比。

c.当完成后台任务时，后台任务管理器(BTM)必须显示一个“已完成”的消息。 d.如果后台任务中止执行，那么后台任务管理器(BTM)必须显示一个出错信息。 （2）“产品必须在显示和隐藏非打印字符之间进行瞬间切换”。 在瞬间这一时间概念上，计算机不能完成任何工作，因此，这个需求是不可行的。该需求也是不完整的，因为它没有说清状态切换的原因。在特定的条件下，软件产品是否可以进行自动切换或者可否由用户采取某些措施来激发这样转变？还有，在文档中显示转变的范围是什么？是所选的文本、整个文档或其它内容？这个需求也存在一个不确定性问题。“非打

印”字符是否指隐藏文本、属性标记或者其它的控制字符？由于存在这些问题，该需求是不可验证的。用如下的语句描述这个需求可能会更好一些： “用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有 H T M L标记之间进行切换”。现在，指代关系就清楚了，非打印字符指的是H T M L标记。修改过的需求指明了是用户触发了显示状态的转换，但是它并没有对设计造成，因为它并没有精确定义所使用的机制。当设计人员选择好一种触发机制（例如热键、菜单命令或语音输入）时，你就可以编写详细的测试用例来验证这种转换操作是否正确。

（3）编译系统应该能生出出错报告，这样就可使初学者能迅速的排错。 应说明编译系统在什么情况下出什么出错报告，改为： 编译系统应该能标识出错误，并在错误所在的位置显示出出错报告，这样就可使初学者迅速的排错。

（4）软件系统应具有良好的反应时间和数据精度，且能由菜单方式驱动。 “良好的”应使用量化的语言叙述，改为：

软件系统的反应时间应小于1秒，数据精度为10^-6。 （5）“分析程序应该能生成 H T M L标记出错的报告，这样就可以使 H T M L的初学者使用它来迅速排错。”

“迅速”这个词具有模糊性。缺乏对出错报告内容的定义表明该需求是不完整的。我不知道你是如何验证这个需求的。找一些 H T M L的初学者，看他们利用这个报告是否可以迅速排错？还有一点不清楚的是： H T M L初学者使用的是分析程序还是出错报告。并且何时生成这样的报告？让我们使用另一种方式表述这个需求：

a. 在H T M L分析程序完全分析完一个文件后，该分析程序必须生成一个出错报告，这个报告中包含了在分析文件过程中所发现错误的 H T M L所在的行号以及文本内容，还包含了对每个错误的描述。

b. 如果在分析过程中未发现任何错误，就不必生成出错报告。现在我们知道了任何生成出错报告及其所包含的内容，但是我们已经把该需求提交给设计人员，让他们来决定报告的形式。我们还指明了一种例外情况：如果没有任何错误，就不生成出错报告。 （6）“如果可能的话，应当根据主货物编号列表在线确认所输入的货物编号。” 我在想：“如果可能的话”这句话意味着什么？该需求是否在技术上可行？是否可以在线访问主货物编号列表？如果你不能确信是否可以递交一个请求，那么就使用“待确定” ( T B D )来表示未解决的问题。这个需求是不完整的，因为它并没有指明如果确认通过或失败，将会发生什么情况。应该尽量避免使用不精确的词汇，例如“应当”。 客户可能需要这个功能或者不需要这个功能。一些需求规格说明利用关键字之间微妙的差别如“应当”，“必须”和“可能”来指明重要性。我更喜欢使用“必须”或“将要”来明确说明需求的目的并且明确指定其优先级。改进后的该需求描述如下： “系统必须根据在线的主货物编号列表确认所输入的货物编号。如果在主列表中查不到该货物的编号，系统必须显示一个出错消息并且拒绝订货。”第二种相关需求可能记录了一种异常情况：当进行货物编号确认时，主货物编号列表不可访问。 （7）“产品不应该提供将带来灾难性后果的查询和替换选择。” “灾难性后果”的含义是解释的中心词。在编辑文档时，毫无目的地作出全局性变化而用户又不能检测出错误或没有任何办法来纠正它，此时就可能带来灾难性后果。你也要合理地使用反面需求，因为这些需求描述了系统所不能做的事情。潜在的关注焦点在于当发生意外损坏时，能保护文件的内容。也许，真正的需求是针对多级撤销 ( u n d o )能力、全局变化或其它可导致数据丢失行为确定的。

☆ 为方便顾客，某航空公司拟开发一个机票预订系统。机票售票点把预订机票的顾客信息（姓名，性别，身份证号，出发时间和目的地，航班号等）输入该系统，系统为顾客查询航班，打印出取票通知单和账单。顾客在飞机起飞前一天凭取票通知单和账单缴款取票，系统核对无误后立即打印出机票给顾客。

请用数据流图画出该系统的需求模型（不需要给出数据词典） p42 系统数据流图

订票信息旅客机票机票预订系统取票通知和账单取通知和账单付费信息旅客

顶层数据流图只是粗略的给出整个系统的数据流情况。为了更好的把“航空机票预定系统”中各个模块的具体数据流处理细节表示出来，可以在顶层图的基础上自顶向下继续分解，得到1层和2层数据流图。

顶层数据流程图旅客信息订票通知、账单信息旅客旅客取票通知、账单信息1层流程图

旅客信息1.1安排航班订票信息1.2打印、通知账单通知、账单信息订票信息旅客D1订票信息旅客通知、账单信息机票2.3打印机票收费信息2.2收费订票信息核对正确2.1核对机票信息

2层流程图旅客信息1.11旅客基本信息及订票要求信息录入旅客基本信息及订票要求信息1.13航班安排航班信息订票信息D2通知和账单记录旅客基本信息1.14旅客管理1.12航班管理D3旅客基本信息表D4航班信息票订票细化流程图

旅客去票通知和账单信息2.3打印机票2.2收费正确2.1核对机票信息订票信息D1订票记录

另附数据字典： 旅客信息:

姓名：xxx 性别：男 描述：旅客订票时所填的资料(省份证号、所需机票的基本信息、乘机时间） 定义：订票申请表单(旅客姓名、旅客性别、起飞日期、飞行目的地、座位类型 ） 位置：位置：在客户端由旅客填写 航班信息：

航班名称：

航班类型：

描述：所有从本地起飞的航班信息（航班号、起飞时间、到达的目的地、空出的

座位数、票价）

定义：航班信息（航班号、起飞日期、飞行目的地、空出的座位数、票价）

位置：从服务器端查询后，发送到客户端

账单信息：

账单名称：

账单号：

描述：已定票的旅客信息资料（帐单号、旅客姓名、旅客性别、旅客身份证号）

定义：账单基本信息（订票旅客的姓名、性别、省份证号、航班号） 位置：在服务器端产生，发送回客户端

机票信息：

机票编号： 航班号： 描述：所有机票信息（已出售的机票、剩余机票、航班号、起飞时间） 定义：机票基本信息（旅客姓名、旅客性别、身份证号码、航班号、起飞时间、飞 行目的地、座位号） 位置：发送到客户端

另附系统流程图（功能需求）：

用户接受客户端安排航班数据库预定打印去票通知和帐单服务器终端用户出示去票通知和帐单核对客户端订票数据库打印机

另附面向对象的需求分析方法：