行自动切换或者可否由用户采取某些措施来激发这样转变？还有，在文档中显示转变的范围
是什么？是所选的文本、整个文档或其它内容？这个需求也存在一个不确定性问题。“非打
精彩文档
实用标准文案
印”字符是否指隐藏文本、属性标记或者其它的控制字符？由于存在这些问题，该需求是不 可验证的。用如下的语句描述这个需求可能会更好一些：
成的百分比。
c.当完成后台任务时，后台任务管理器(BTM)必须显示一个“已完成”的消息。
d.如果后台任务中止执行，那么后台任务管理器(BTM)必须显示一个出错信息。
（2）“产品必须在显示和隐藏非打印字符之间进行瞬间切换”。
在瞬间这一时间概念上，计算机不能完成任何工作，因此，这个需求是不可行的。该需
求也是不完整的，因为它没有说清状态切换的原因。在特定的条件下，软件产品是否可以进
需求定义阶段：根据用户需求编写出需求规格说明。
需求的形式化描述阶段：用严格的数学知识和符号来构造系统的需求模型。
需求验证阶段：检验软件需求规格说明。
需求管理阶段：开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影
响及可能的成本及费用，然后实施更改，一级有效的管理需求规格说明文档和跟踪更改需求
☆ 请指出下列陈述属于哪种类型的软件需求或不属于软件需求。
p26
（1）只有电梯停在某一楼层时，电梯才能改变方向。 非功能
（2）系统必须用三个主要模块来实现，即检测、记录和统计分析模块，每个模块各自实现
精彩文档
实用标准文案
一个主要功能。
功能性需求
（3）当用户输入他们的口令后，系统便自动从口令文件中检索他们的加密口令，并进行核
护性和可扩展性等。
约束与限制：指软件开发人员在设计和实现软件系统时的限制，如：开发语言，使用的数据
库等。
精彩文档
实用标准文案
☆ 试述快速原型开发模型和面向对象开发模型的基本思想，然后说明快速原型开发模型中
抛弃型模型和进化型模型的作用。
p9
快速原型模型基本思想：快速建立一个实现了若干功能的（不要求完全）可运行模型来启发、
求信息录入
旅客基本信息及 订票要求信息
1.13 航班安
排
订票信息
旅客基本信息
航班信息
1.14 旅客管
理
1.12 航班管
理
D2通知和账单记录
D3旅客基本信息表
D4航班信息票
订票细化流程图
精彩文档
2.3 打印机
票
实用标准文案
2.2 收费
旅客去票通知和 账单信息
2.1 正确 核对机
票信息
订票信息
D1订票记录
对。
功能性需求
（4）通过对用户进行不到一个小时的培训后，用户能输入和打印某些数据，且输入/出的出
错率低于 1/20。
非功能
（5）所有报销单据必须经过财务部门某负责人审核后才能交由系统处理。
非功能
（6）系统必须用面向对象的方法和糊，如果含糊的话，请在说明理由后给予修改：
另附数据字典：
旅客信息:
姓名：xxx 性别：男 描述：旅客订票时所填的资料(省份证号、所需机票的基本信息、乘机时间） 定义：订票申请表单(旅客姓名、旅客性别、起飞日期、飞行目的地、座位类型 ） 位置：位置：在客户端由旅客填写
航班信息：
航班名称： 航班类型： 描述：所有从本地起飞的航班信息（航班号、起飞时间、到达的目的地、空出的 座位数、票价） 定义：航班信息（航班号、起飞日期、飞行目的地、空出的座位数、票价） 位置：从服务器端查询后，发送到客户端
围和项目应达到的目标。
业务需求：主要描述软件系统必须完成的任务、实际业务或工作流程等。软件开发人员通常
可从业务需求进一步细化出具体的功能需求和非功能需求。
功能需求：指开发人员必须实现的软件功能或软件系统应具有的外部行为。
性能需求：指实现的软件系统功能应达到的技术指标，如：计算效率和精度，可靠性，可维
揭示和不断完善用户需求，直到满足用户的全部需求为止。其基本过程如下：
收集需求 快速设计 建立原型 评价并细化需求 设计与实现 测试 维护
面向对象开发模型基本思想：
应用对象、类、继承、封装、消息、对象或类之间的关系等面向对象的概念对问题进行分析
和求解的软件开发技术，或者说，是以对象（类）为数据中心、对象之间的动态行为模式作
为运行机制的一种问题求解方法。其基本过程如下：
面向对象分析
面向对象设计
面向对象实现和测试
系统维护
抛弃型模型：指在原型达到预期目的后将其抛弃，而且在构建该原型时，可以忽略具体的软 件构造技术，亦即应以最小的代价构造抛弃型原型。 进化型模型：在需求被清楚定义的情况下，以渐增式方式构建原型，并使原型最终能成为软 件产品的一部分。
“系统必须根据在线的主货物编号列表确认所输入的货物编号。如果在主列表中查不到 该货物的编号，系统必须显示一个出错消息并且拒绝订货。”第二种相关需求可能记录了一 种异常情况：当进行货物编号确认时，主货物编号列表不可访问。 （7）“产品不应该提供将带来灾难性后果的查询和替换选择。”
“灾难性后果”的含义是解释的中心词。在编辑文档时，毫无目的地作出全局性变化而 用户又不能检测出错误或没有任何办法来纠正它，此时就可能带来灾难性后果。你也要合理 地使用反面需求，因为这些需求描述了系统所不能做的事情。潜在的关注焦点在于当发生意 外损坏时，能保护文件的内容。也许，真正的需求是针对多级撤销 ( u n d o )能力、全局 变化或其它可导致数据丢失行为确定的。
实用标准文案
☆ 什么是软件需求工程？请说明软件需求工程中各阶段的主要任务。
p5
1 定义
一般定义：指应用工程化的方法、技术和规格来开发和管理软件的需求。
需求工程的目标： 获取高质量的软件需求。
与软件工程中传统的需求分析概念相比，需求工程突出了工程化的原则，强调以系统化、条
理化、可重复化的方法和技术进行与软件需求相关的活动，从而有利于提高所有与软件需求
p42
系统数据流图
旅客
订票信息 机票
机票预订 系统
取票通知和账单
取通知和账单 付费信息
旅客
顶层数据流程图
顶层数据流图只是粗略的给出整个系统的数据流情况。为了更好的把“航空机票预定系 统”中各个模块的具体数据流处理细节表示出来，可以在顶层图的基础上自顶向下继续分解， 得到 1 层和 2 层数据流图。
旅客信息
p84
（1）系统必须在固定的时间间隔内提供状态信息，并且每次时间间隔不得小于 60 秒。
含糊。需求不完整，导致需求不可验证。改进如下：
后台任务管理器(BTM)应该在用户界面的指定区域显示状态消息。
a.在后台任务进程启动之后，消息必须每隔 60(10)秒更新一次，并且保持连续的可见性。
b.如果正在正常处理后台任务进程，那么后台任务管理器(BTM)必须显示后台任务进程已完
我在想：“如果可能的话”这句话意味着什么？该需求是否在技术上可行？是否可以在 线访问主货物编号列表？如果你不能确信是否可以递交一个请求，那么就使用“待确定” ( T B D )来表示未解决的问题。这个需求是不完整的，因为它并没有指明如果确认通过或失败， 将会发生什么情况。应该尽量避免使用不精确的词汇，例如“应当”。 客户可能需要这个功 能或者不需要这个功能。一些需求规格说明利用关键字之间微妙的差别如“应当”，“必须” 和“可能”来指明重要性。我更喜欢使用“必须”或“将要”来明确说明需求的目的并且明 确指定其优先级。改进后的该需求描述如下：
“用户在编辑文档时，通过激活特定的触发机制，可以在显示和隐藏所有 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 所在的行号以及文本内容，还包含
相关的活动及其过程的可管理性，降低需求开发和管理的难度和成本。
其它定义：
Alan.Davis： 直到（但不包括）把软件分解为实际架构组建之前的所有活动，即软件设计
之前的一切活动。该定义虽然没有详细说明需求工程是什么，但其给出了需求工程的范围。
Lan K. Bray：对问题域及需求做调查研究和描述，设计满足那些需求的解系统的特性，并
精彩文档
实用标准文案
☆ 为方便顾客，某航空公司拟开发一个机票预订系统。机票售票点把预订机票的顾客信息
（姓名，性别，身份证号，出发时间和目的地，航班号等）输入该系统，系统为顾客查询航