软件需求的特性有:1、完整性,是指每一项需求都必须将所要实现的功能描述清楚,不能丢失一些信息;2、正确性,是指每一项需求都必须准确地陈述其要开发的功能;3、可行性,是指需求是否能被正常地实现,每一项目需求都必须是可以在已知系统和环境的权能和限制范围内实施的;4、必要性,是指每一项需求都应把客户真正所需要的和最终所需遵从的标准记录下来;5、划分优先级;6、无二义性;7、可验证性。
php入门到就业线上直播课:进入学习
Apipost = Postman + Swagger + Mock + Jmeter 超好用的API调试工具:点击使用
本教程操作环境:windows7系统、Dell G3电脑。
什么是软件需求
用户解决问题或达到目标所需的条件或者权能(capability)
系统或者系统部件要满足合同、标准、规范或者其它正式规定文档所需具有的条件或权能
一种能反映上面1或者2所描述的条件或者权能的文档说明
需求不仅仅包含通常意义上的产品功能,还包含行业规范中定义的标准,如银行的行业技术规范、电信的入网标准等。
软件需求的特性
在整个研发过程中,原始收集完成后,接下来进行的第一个步骤就是需求评审,那么如果要将需求评审好,就必须知道什么样的需求说明是好的说明,通常一个好的需求说明应该具备以下7个特性。
(1)完整性
完整性是指每一项需求都必须将所要实现的功能描述清楚,不能丢失一些信息,如果有丢失信息则说明需求不够完整,需求的完整性也是开发人员获得设计和实现这些功能所需的必要信息。
(2)正确性
正确性是指每一项需求都必须准确地陈述其要开发的功能,做出正确判断的参考是需求的来源,如用户或高层的系统需求规格说明,若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性,这就是一定要有用户积极参与的原因。没有用户参与的需求评审将会导致这种现象出现:“那些没有意义不是我们想要的”,因为没有用户参与的话,很多评审都可能是我们评审专家自己凭空想的。
(3)可行性
可行性是指需求是否能被正常地实现,每一项目需求都必须是可以在已知系统和环境的权能和限制范围内实施的。为避免不可行的需求,最好在获取需求过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作,由他检查技术可行性。
(4)必要性
必要性是指每一项需求都应把客户真正所需要的和最终所需遵从的标准记录下来,“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”,要使用每项需求都能回溯至某项客户的输入。
(5)划分优先级
划分优先级是对所有的需求进行分类,分成不同等级的需求,通常需求可以分为高、中、低三个级别。需求优先级高是指一个关键任务的需求,如果这个业务没有实现,那么这个产品就没有用户会购买。如手机的通话功能,如果手机没有通话功能,这个手机就没有人会买。
需求优先级中是指这个业务一定要实现,但质量特性可以做得是不是很完善,如手机的摄像头功能,现在的智能机都带摄像头,但像素不一定做得很高,如有的厂家做到3000 万像素,但我们可以做到1000 万像素,这样产品还是有人会买,但可能价格会受到影响。
需求优先级低是指这个业务可以实现也可以不实现,如月饼包装得很漂亮,如果我们是买给自己吃的,那么这个包装是否很漂亮并不是主要的,通常这类需求也叫镀金需求。
(6)无二义性
二义性是指一个描述的需求有两种或多种理解的方式,在描述需求的过程中由于自然语言很容易导致二义性,所以尽量使用简洁明了的用户性的语言表达每项需求。
(7)可验证性
可验证性是指每项需求都可以通过具体的用例或测试步骤来验证其是否正确,如果我们不能使用一套有效的方法进行验证,那么就无法客观地判断当前的需求是否被正确地实现。
上面是我们评审时需要注意的一些特性,只有符合这些特性的需求,我们才认为是一个好的需求,那么需求说明通常具备以下四个特点:
1)完整性
完整性上面我们介绍过,是指不能遗漏任何必要的需求信息,如果有遗漏的信息很难被查出来。
在描述需求时,如果我们尽量注重用户的任务,抛开系统的功能,可以更好地避免需求的不完整性。
2)一致性
一致性是指与其他软件需求或高层(系统、业务)需求不相矛盾,在开发前有必要解决所有需求之间不一致部分,只有进行详细的检查才能确定某一项需求是否正确。
3)可修改性
在必要的时候或为了维护每一个需求变更历史记录时需要修改需求,这样就要求每项需求要独立标识出来,并与其他需求区别开来,这样可以保证无二义性。并且每项需求只应在需求说明书中出现一次,这样更改需求时,可以保持需求的一致性。
4)可跟踪性
可跟踪性是指每项软件需求与其根源和设计元素、源代码、测试用例之间建立起链接,这样可以确保每项需求都被实现和验证,这也是我们工作中常说的需求跟踪矩阵。