软件工程学习笔记(三):需求工程

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 需求管理

需求管理是一组用于帮助项目组在项目进展中的任什么时候候去标识,控制和跟踪需求的活动.在需求管理中,每一个需求被赋予惟一的标识符,一旦标示出需求,就能够为需求创建跟踪表,每一个跟踪表标示需求与其余需求或设计文档,代码,测试用例的不一样版本间的关系.这些跟踪表能够用于需求跟踪,在整个开发过程当中,进行需求跟踪的目的是为了创建和维护从用户需求开始到测试之间的一致性与完整性.确保全部的实现是以用户需求为基础,全部的输出符合用户需求,而且全面覆盖了用户需求.