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、需求的变化有哪些?
①问题发生了改变
②环境发生了改变
③需求基线存在缺陷
④用户变动
⑤用户对软件的认识变化
⑥相关产品的出现