首页 理论教育GB/T9385-2008评价方法论的有效性和完备性

GB/T9385-2008评价方法论的有效性和完备性

【摘要】:正所谓“真金不怕火炼”,方法论在应用中的好坏,是否能够真正地解决业务建模的实际问题,是否真实有效地为需求调研提供一种解决方案,需要一套客观的评价机制做出判定。本节主要以GB/T9385-2008对需求的评价依据作为标准,读者经过全套方法论的学习后,可以依据此标准一一对应量化,核实方法论是否在工作中满足了以下要求,是否真实提高了需求建模的效率和满足了需求建模的完备性。

正所谓“真金不怕火炼”,方法论在应用中的好坏,是否能够真正地解决业务建模的实际问题,是否真实有效地为需求调研提供一种解决方案,需要一套客观的评价机制做出判定。本节主要以GB/T9385-2008对需求的评价依据作为标准,读者经过全套方法论的学习后,可以依据此标准一一对应量化,核实方法论是否在工作中满足了以下要求,是否真实提高了需求建模的效率和满足了需求建模的完备性。

1.正确性

对系统功能、行为、性能等的描述必须与用户的期望相吻合,代表了用户的真正需求。当且仅当用户的每一项需求都是软件应满足的需求,才表示需求建模是正确的,相关人员(客户和需求分析人员等)可以参考其他项目文件,其他适用的标准(公司流程、规章制度等)进行对比,以确保其相互一致,这里可以结合后面马上要提到的可追踪性进行相互的映射检查。

案例&知识:

叮铃铃……,程序员小赵的电话响了。小赵刚刚拿起电话就听到对面迫不及待的抱怨声音,“仓库管理员反映,入库的模块没有办法使用!你检查一下,尽快解决。”

小赵放下电话就开始Check out、Builder、Run、Debug等一系列的操作。经过一番测试之后,小赵没好脾气地拿起电话回复说:“这些客户真是笨!哪里有什么问题,肯定是操作上出现了问题!我用的时候怎么都是好的,你们客服应当加强对用户的培训,别什么事情都扔给我们!”

…………

但是问题依然没有得到有效地解决!开发人员到现场一看才知道这是一个基于B/S的仓库管理系统。在入库的时候仓库管理员首先要录入入库单,然后填入“验收情况”,点击 “入库”按钮。但是当仓库管理员录入完入库单,逐一验证入库货物之后再回到电脑面前时,等待他的却是一个令人不知所措的问题——Session超期。

憋了一肚子气的小赵一个电话就打到需求分析员小钱那里:“你们的需求是怎么填写的!这么重要的东西也不写明白,我们怎么知道填完入库单后要验货那么长时间,才填写验收情况呀。”

“哦,这也算是需求么?如果这也算是需求的话,我们岂不是成了业务人员了!”小钱很强势地回答。

上面的案例是每个需求分析人员日常的一个缩影,真实但又明确反映出了需求调研最基本的问题。这就体现了用户代表参与需求调研的重要性。因为,只有用户才能确定用户需求的正确性。所以,方法论提出了业务场景建模,如果缺乏对场景的了解,又如何能够真正理解需求呢?如果断了“业务场景”之章,就必将导致取出的“需求”之义有所偏差。

2.无二义性

当且仅当每项需求都有且只有一种解释,才表明需求说明是无歧义的,所以,要求最终对需求的描述尽量采用统一、唯一、明确的术语来描述。

对于二义性需要说明:(1)由于自然语言极易导致二义性,所以尽量把每项需求用简洁明了的用户业务性语言表达出来;(2)可以采用某种固定的需求表达语言,该语言可以有固定的语法、语义表达,但又不至于过多影响非技术方面用户的理解;(3)加强对需求文档的正规审查,编写测试用例,开发原型以及设计特定的方案脚本;(4)当在特定背景中使用的某个术语存在多种含义时,应将此术语收纳于术语表中,以便更加具体地解释其含义;(5)需求文档宜由独立的一方进行评审,以便识别语言的模糊用法并予以纠正。

3.完整性

需求工程应该包括软件要完成的全部任务,不能遗漏任何必要的需求信息,要注重用户的任务而不是系统的功能,才能避免不完整性。

关于完备性需要说明:(1)所有重要的需求,不论是否与功能、性能、设计约束、属性或者外部接口有关,尤其是由系统规格说明所施加的任何外部需求都应当得到确认和处理;(2)软件响应的定义,以说明软件对所有可实现的输入数据类型的响应,应当注意,对于有效和无效输入数值两种情况,规定软件响应都是重要的;(3)需求工程中所有图表的全面标记和索引,以及所有术语和度量单位都应有明确的定义;(4)对于待定问题必须进行说明(为什么答案未知),以便条件成熟时问题能得到解决,描述排除“待定”应采取的措施,由谁负责排除以及何时必须排除。

4.一致性

需求工程对各种需求的描述不能存在矛盾,如上下层文档、术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等。

关于一致性需要说明:当且仅当在需求描述中的任何单个需求的子集之间相互不矛盾,才表明需求是一致的。在实际的需求建模过程中可能存在以下三种类型的矛盾:(1)现实世界对象的规定特征可能相互矛盾。如:报告的输出格式在一个文档中是表格形式,而同时在另一个文档中则是文本形式;一个文档指出所有的灯都是红色的,而另一个文档则指出所有的灯都应该是绿色的。(2)在两个规定的行为之间可能存在逻辑上或时间上的冲突。如:一个文档规定程序将两个输入相加,而另一个文档则说将两个输入相乘;一个文档指出“A”必须总是在“B”之后,而另一个文档则要求“A”和“B”同时发生。(3)可能两个或更多的需求描述现实世界的相同对象,但使用不同的术语。如:在一个需求中程序,用户输入请求称为“提示符”,而在另一个需求中称为“提示”。使用统一标准术语和定义可以改善一致性。

5.重要性和/或稳定性分级

如果需求工程中每条需求都标明其重要性或稳定性的标识,那么需求工程便按照重要性和/或稳定性进行了分级。

这是因为通常与软件产品有关的所有需求并不具有相同的重要性。某些需求可能是基本的,特别是与人身生命有关的关键应用,而其他的可能是所期望的需求。在需求工程中每个需求都宜予以标识,使需求在这方面的差异清晰和明确。在实际的需求建模过程中,读者进行重要性分级标识需求,有助于:(1)使客户更仔细地考虑每个需求,这样常常会澄清客户可能引入的任何隐蔽的假设;(2)正确且准确评估工作量,使设计人员做出正确的设计决定,并针对软件产品的开发任务能够做出不同的投入和关注,选择合适的人员或安排合适的时间来完成任务。

其中,可以用需求期望的版本更新迭代次数来标识需求的稳定程度。另外,可以采取需求分级的方式区分基本的、有条件的和可选的需求类别:(1)基本的:除非表示同意并满足了这类需求,否则软件将不被接受;(2)有条件的:表示这类需求会增强软件产品,但是,如果缺少这类需求,也不会导致软件产品被拒收;(3)可选的:表示该功能需求可有可无,这赋予需求分析人员提出超出客户需求期望的建议机会和余地。(www.chuimin.cn)

6.可验证性

描述的需求都可以运用一些可行的手段对其进行验证和确认。当且仅当存在某个有限的成本、有效的过程,人或机器依照该过程能够检查软件产品满足某个需求,这样的需求才是可验证的。一般说来,任何有歧义的需求都是不可验证的。

不可验证的需求包括诸如“界面友好”“响应及时”“提供好的人机交互方式”“服务器工作稳定”之类的陈述。因为谁都无法准确定义“友好”“及时”“好的”“稳定”,因此,这些需求都是不可验证的。再例如,提出“程序应杜绝出现无限循环”,这也是不可验证的,因为理论上该特性是不可测试的。

案例&知识:

好的易于验证的陈述示例:

报表数据应在事件触发开始的0.2 s内达到60%,在0.5 s内生成。

上述案例的陈述方式就是可验证的,因为使用了具体的术语和可测量的数值。如果不能设计出一种有效的方法,以确定软件是否满足某个具体的需求,那么该需求就应该被删除或修改。

7.可修改性

当且仅当需求工程的结构和形式能够对任何需求进行、全面、便利且一致的修改,同时保持其结构和形式,才能表明需求工程的结构是可修改的。

在实际操作中可以从以下三个方面来检验需求工程是否具备可修改性:(1)具有连贯、方便使用的结构,包括目录、索引及清晰的相互引用关系;(2)没有冗余,即相同的需求只出现一次;(3)分别表达每个需求,而尽量不与其他需求混淆。

8.可跟踪性

如果每个需求的来源都是清楚的,并在之后的设计和开发的文档中能够方便地索引到每个需求,则表明该需求为可追溯的。

关于需求的可追溯性主要包括以下两种情况:(1)逆向可追溯性(直到之前的开发阶段),这依赖于每个需求可以清晰地指向其早期文件中的来源;(2)正向可追溯性(直到由需求文档产生的所有文件),这依赖于需求文档中的每个需求具有唯一的名称或索引号。

特别指出,当软件进入运行及维护阶段时,需求文档的正向可追溯性尤其重要。随着代码和设计文档的修改,最要紧的就是能够确定这些修改可能影响的全部需求的集合。

关于需求的评价部分,这里我们再通过下面的综合案例来认识一下前文提及的评价指标的含义,以便大家在实际的需求建模过程中能够真正地理解和应用上述指标来指导工作顺利有效开展。

案例&知识:

改进前:产品必须在固定的时间间隔内提供状态消息,并且每次时间间隔不得小于60 s。

存在问题:这个需求描述不完整、不准确也不具备可验证性。

改进后:后台任务管理器(BTM)应该在用户界面的指定区域显示状态消息。

(1)在后台任务进程启动之后,消息必须每隔60(±10) s更新一次,并且保持连续的可见性。

(2)如果后台任务进程正在正常处理,那么后台任务管理器(BTM)必须显示后台任务进程已完成的百分比。

(3)当后台任务完成时,后台任务管理器(BTM)必须显示一个“已完成”的消息。

(4)如果后台任务中止执行,那么后台任务管理器(BTM)必须显示一个出错信息。