1、简述需求工程的主要任务
（1）需求工程需要同时说明软件需要“做什么”和“为什么”需要做。
（2）需求工程必须将目标、功能和约束反应到软件系统中，映射为可行的软件行为，并对其进行规格说明。
（3）需求工程需要妥善处理目标、功能和约束随着时间的演化情况
2、简述常见的需求定义错误
（1） 需求未反映用户的真实需要
（2）模糊和歧义的需求
（3）信息遗漏
（4） 不必要的需求
（5）不切实际的期望
3、简要说明需求获取活动的过程。
（1）收集背景资料
（2）获取问题与目标，定义项目前景和范围
（3）识别涉众，选择信息的来源
（4）选择获取方法，执行获取 ，获取功能与非功能需求
（5）记录获取结果
1、信息系统的四种类型
小型系统（部门级系统）、组织级系统（企业级系统）、组织间系统（企业间系统）、战略信息系统
2、涉众分析的任务
（1）涉众识别：寻找软件系统的涉众类别，发现关键涉众。
（2）涉众描述：描述不同涉众类别的简单、复杂特征
（3）涉众评估：划分优先级、 评估风险 、分析涉众冲突
（4）涉众代表选择：从每种涉众类别中选择代表
（5）涉众参与策略制定：制定涉众代表参与需求开发乃至软件系统开发的参与策略
3、识别涉众的方法
简单方法：先膨胀后收缩；经验方法：检查列表；经典方法：涉众网络
4、涉众识别的基本过程
（1）集中初始涉众进行头脑风暴、得出涉众类别列表
（2）分析涉众类别列表判断和软件系统的相关性，缩减为关键涉众类别列表
（3）为关键涉众类别列表选择代表，并集中头脑风暴，得出新涉众类别列表
（4）新涉众类别列表趋于稳定，则结束涉众识别；若有新发现，转向第（2）步
1、“用例/场景模型”在“需求获取活动”中有何作用？为什么？
有着主线索的作用
原因：用例/场景模型能够及时地将每次需求获取活动的进展 组织起来，展现、提供给分析活动，并在得到分析结果后进 一步指导后续获取活动
1、准备面谈需要做什么？
(1)阅读背景资料
(2)确定面谈主题和目标
(3)选择被会见者
(4)通知被被会见者做准备
(5)确定问题和类型
2、面谈的类别
（1）结构化面谈：安全按照事先的问题和结构来控制面谈
（2）半结构化面谈：在面谈过程中，据实际情况采取 一些灵活的策略
（3）非结构化面谈：没有事先预定的议程安排
3、试比较面谈问题组织的三种结构
（1）金字塔结构：以具体的问题开始，然后逐渐提高问题开放度。会见者需对话题进行预热、不情愿讨论某个话题、事先对事实的确认存在较大偏差时，采用金字塔结构。
（2）漏斗结构：以开放式的问题开始，然后用封闭式问题缩小可能的答复。被会见者对话题有情绪、事先对事实了解不多时，采用漏斗结构。
（3）菱形结构：以一种非常明确的方式开始，然后考察一般问题，最后得出一个非常明确的结论。菱形结构所花的时间比其他任何一个都长。
1、简述软件开发中为何使用原型工具
原型是在最终系统产生前的局部真实表现，可以让人们在系统的开发过程中，就对一些具体问题进行基于实物的有效沟通，帮助人们尽早解决软件开发过程中存在的各种不确定性。
2、原型法进行需求获取的基本过程
（1）确定原型需求：确定开发原型的原因、拥有的起终点、期望的结束标准
（2）原型开发：依据原型的需求特点和开发目 的，以最低的成本建立初始原型
（3）原型评估： 对上一阶段原型评估，根据评估反馈判断原型是否满足结束标准
（4）原型修正：根据反馈的不足进行原型调整，调整完成后再次评估。
3、比较原型开发方法的三种类型
（1）探索式：以缺陷需求开始继而不断调整和修正需求的 原型开发方式
（2）实验式：初始时就有清晰的用户需求，但是对需求的实现方法、效果、可行性没有太大的把握
（3）演化式：原型的开发并不是一个独立的活动，而是整个项目持续开发过程中的一部分
（4）探索式、实验式原型方法产生的原型产品被称为抛弃式原型。建立抛弃式原型时，代码要被抛弃，尽量花费最小的代价，争取最快的速度。为此，开发者会使用简易的开发工具和不成熟的构造技术，忽略简化一些和原型目标不相关的功能特征。
（5）建立演化式原型时，质量要一开始就达到最终系统要求，要易于进行扩展和频繁改进，用于处理清晰的需求、规格说明和技术方案
4、原型方法的主要风险
（1）成本失控（最大的风险）
（2）给涉众造成错误印象
（3）用户可能会被原型所表现出来的非功能特性遮蔽了眼睛
（4）是在澄清需求不 确定性的同时也可能会掩盖一些用户假设，这些假设将会无从发现
1、结构化分析方法的局限性
（1）数据需求和处理需求的联接不易
（2）结构化分析向结构化设计的过度不易
（3）结构化分析过于重视对已有系统的建模
2、为何要确定需求的优先级
（1）项目的资源有限，无法满足用户的所有需求
（2）项目采用分阶段的开发方式，应优先交付用户最重要最紧急的需求
（3）在项目的开始阶段，并不能明确所有的用户需求
3、需求分析人员需求协商三原则
（1）明确冲突因素，避免情绪冲突
（2）明确冲突解决空间
（3）确定最佳解决方案
1、为什么要编写需求规格说明文档
（1）它可以成为各方人员之间有关软件系统的协议基准
（2）它可以成为项目开发活动的重要依据
（3）在它的编写过程中，可以尽早的发现和减少可能的需求错误，从而减 少项目的返工，降低项目的工作量
（4）它可以成为有效的智力资产
2、说明文档所使用的三种语言
（1）非形式化语言：即自然语言。
（2) 半形式化语言：自然语言具有更丰富的语义和更严格的语法同时又没有严格到完 全基于数学方法的语言，例如 ERD、DFD、UML 等图形语言
（3）形式化语言：基于数学的语言，例如 VDM、Z 语言
1、简述评审的过程
规划阶段、总体部署阶段、准备阶段、审查会议阶段、返工阶段、跟踪阶段
2、简述需求验证的方法
需求评审、原型与模拟、测试用例开发、用户手册编制、利用跟踪关系、自动化分析
1、简述需求管理的重要任务
①交流涉众的需要。
②将需求应用、实施到解决方案。
③驱动设计和实现工作。
④控制变更。
⑤将需求分配到子系统。
⑥测试和验证 终产品。
⑦控制迭代式开发中的变化。
⑧辅助项目管理。
2、需求的变化有哪些？
①问题发生了改变
②环境发生了改变
③需求基线存在缺陷
④用户变动
⑤用户对软件的认识变化
⑥相关产品的出现