1 概述
需求工程是应用已证实有效的技术与方法开展需求分析,确定客户需求,帮助分析人员理解问题,评估可行性,协商合理的解决方案,无歧义地规约方案,确认规约以及将规约转换到可运行系统时的需求管理.需求工程是一个不断反复的需求定义,文档记录,需求演进的过程,并最终在验证的基础上冻结需求.需求工程可以分为六个阶段:需求获取,需求分析与协商,系统建模,需求规约,需求验证,需求管理.
2 需求获取
需求获取阶段分析人员通过与用户的交流,对现有系统的观察以及对任务进行分析,确定系统或产品范围的限制性描述,与系统或产品有关的人员及特征列表,系统的技术环境的描述,系统功能列表及应用于每个需求的领域限制,描述不同运行条件下系统或产品使用状况的应用场景等,为需求分析打下基础.
2.1 软件需求
软件需求是指用户对目标软件系统在功能,行为,性能,设计约束等方面的期望,包括:
2.1.1 功能需求
考虑系统要做什么,在何时做,在何时及如何修改或升级等.
2.1.2 性能需求
考虑软件开发的技术性指标,例如,存储容量限制,执行速度,响应时间以及吞吐量.
2.1.3 用户或人的因素
考虑用户的类型,例如用户对使用计算机的熟练程度,需要接受的训练,用户理解,使用系统的难度,用户错误操纵系统的可能性等.
2.1.4 环境需求
考虑未来软件应用的环境,包括硬件和软件,对硬件设备的需求包括机型,外设,接口,地点,分布,温度,湿度,磁场干扰等.对软件的需求包括操作系统,网络,数据库等.
2.1.5 界面需求
考虑来自其他系统的输入,到其他系统的输出,对数据格式的特殊规定,对数据存储介质的规定.
2.1.6 文档需求
考虑需要哪些文档,文档针对的读者.
2.1.7 数据需求
考虑输入,输出数据的格式,接受,发送数据的频率,数据的准确度与精度,数据流量,数据需保持的时间等.
2.1.8 资源使用需求
考虑软件运行时所需要的数据,其他软件,内存空间等资源.软件开发,维护所需的人力,支撑软件,开发设备等.
2.1.9 安全保密需求
考虑是否需要对访问系统或系统信息加以控制,隔离用户数据与方法,用户程序如何与其他程序和操作系统隔离以及系统备份要求等等.
2.1.10 可靠性需求
考虑系统的可靠性技术,系统是否必须监测和隔离错误,出错后重启系统允许的时间等.
2.1.11 软件成本消耗与开发进度需求
考虑开发是否有规定的时间表,软硬件投资有无限制等.
2.1.12 其他非功能性需求
如采用某种开发模式,确定质量控制标准,里程碑和评审,验收标准,各种质量要求的优先级等,以及可维护性方面的需求.
2.2 需求获取的方法即策略
2.2.1 建立顺畅的通信途径
在用户,系统分析人员,软件开发小组,管理人员之间建立良好的沟通方式,以保证能顺利地对问题进行分析.
2.2.2 访谈与调查
分析人员要从分析已经存在的同类的软件产品,或从行业标准,规则中提取初步需求,然后以个别访谈的形式或小组会议的形式开始与用户进行初步的沟通.除了进行面谈外,可以进行市场调查,了解市场对将开发的软件有什么样的要求,可以采取多种调查方式,指定调查提纲,向不同层次的用户发调查表,或访问用户和领域专家.
2.2.3 观察用户操作流程
到用户的实际工作环境中对用户的工作流程进行观察,了解用户的实际操作环境,操作过程与操作要求,对照用户提交的问题陈述,对用户需求可以有更全面细致的认识.
2.2.4 成立联合小组
采用一种叫FAST(facilitated application sepcification techniques)的技术用户与开发方成立一个联合小组,发挥各自的长处,共同负责项目的推进.FAST鼓励建立用户与开发者队伍之间的合作,共同工作来标识问题,提出解决方法的要素,商议不同的方法以及刻画初步的解决方案.
它已经成为信息系统使用的主流技术,该技术为改善各种应用中的相互通信提供了潜在的可能.FAST团队由来自市场,软件与硬件工程以及制造方的代表组成,并选择外来人员作为协调者.该方法有一下基本原则:
- 在中立的地点举行由开发者和用户出席的会议
- 建立准备和参与会议的规则
- 建立一个足够正式的议程以便可以进行自由的交流
- 由一个"协调者"(用户,开发者,或其他人)来控制会议
- 使用一种"定义机制"(工作表,图标等)
- 目标是标识问题,提出解决方案的要素,商议不同的方法以及在有利于完成目标的氛围中刻画出初步的需求
2.2.5 用况
用况常被称为用例,应该包含:
- 执行者完成的主要任务或功能
- 执行者将获取,生产或改变什么信息
- 执行者是否必须通知系统关于外部环境的变化
- 执行者希望从系统获得什么信息
- 执行者是否希望被通知未预期的变化
3 需求分析
3.1 原则
- 必须能够表示和理解问题的信息域
- 必须能够定义软件将完成的功能
- 必须能够表示软件的行为
- 必须划分描述的数据,功能和行为的模型
- 分析过程应该从要素信息移向细节信息
3.2 信息域
信息域包括信息内容,信息流以及信息结构.
3.2.1 信息内容
信息内容表示了单个数据和控制对象,目标软件所有处理的信息集合由它们构成.
3.2.2 信息流
信息流表示了数据和控制在系统中流动时的变化方式,输入对象被变换为中间信息,然后进一步被变换为输出.
3.2.3 信息结构
信息结构表示了各种数据和控制项的内部组织形式.
3.3 需求协商
需求很容易出现冲突,这就需要进行协商,讨论需求冲突,通常会议是解决冲突最快的方式.
3.4 需求建模
创建模型是需求分析的重要活动.模型以一种简洁,准确,结构清晰的方式系统地描述了软件需求,从而帮助分析员理解系统的信息,功能与行为,模型还将成为软件设计的基础,为设计者提供软件要素的表示视图.
4 需求规约
需求规约是分析任务的最终产物,通过建立完整的信息描述,详细的功能和行为描述,性能需求和设计约束的说明,合适的验收标准,给出对目标软件的各种需求.软件需求规约的框架主要分为5部分:
4.1 引言
引言陈述软件目标,在基于计算机的系统语境内进行描述,包括系统参考文献,整体描述,软件项目约束等.
4.2 信息描述
信息描述给出软件必须解决的问题的详细描述,记录信息内容,信息流,信息结构.
4.3 功能描述
功能描述用以描述解决问题所需要的每个功能,其中包括为每个功能说明一个处理过程,叙述设计约束,叙述性能特征,用一个或多个图形来形象地表示软件的整体结构和软件功能与其他元素间的相互影响.
4.4 行为描述
行为描述用以描述作为外部事件和内部产生的控制特征的软件操作.
4.5 检验标准
检验标准描述检验系统成功的标志,即对系统进行什么样的测试,得到什么样的结果,就表示系统已经成功实现了.检验标准是确认测试的基础.
4.6 参考书目
对所有和该软件相关文档的引用,包括其他的软件工程的文档,技术参考文献,厂商文献和标准.
4.7 附录
包含了规约的补充信息,表格数据,算法的详细描述,图表和其他材料.
5 需求验证
需求验证的目的是检验是否能够反映用户的意愿,需要对需求文档中定义的需求执行多种检查,评审团队应该检查需求的有效性,一致性和作为一个整体的完备性.包括系统定义的目标是否与用户的要求一致,系统需求分析阶段提供的文档资料是否齐全,被开发的数据流与数据结构是否确定且充足,主要功能是否已包括在规定的软件范围之内,是否都已充分说明,设计的约束条件或限制条件是否符合实际,开发的技术风险是什么,是否详细制定了检验标准,它们能否对系统定义进行确认.
6 需求管理
需求管理是一组用于帮助项目组在项目进展中的任何时候去标识,控制和跟踪需求的活动.在需求管理中,每个需求被赋予唯一的标识符,一旦标示出需求,就可以为需求建立跟踪表,每个跟踪表标示需求与其他需求或设计文档,代码,测试用例的不同版本间的关系.这些跟踪表可以用于需求跟踪,在整个开发过程中,进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性.确保所有的实现是以用户需求为基础,所有的输出符合用户需求,并且全面覆盖了用户需求.
来源：51CTO
作者：2578612215
链接：https://blog.51cto.com/13996197/2464536