在《软件工程最佳实践》一书中,罗列了18种软件需求方法论,这里逐一介绍如下:
“用户代表”代表的是用户,决定的是需求。有了用户代表,需求的确认和变更,以及需求优先顺序的确定,都会便捷很多。这种方法完美契合敏捷的“交流胜于文档”的思想。唯一的问题是,这种方法论只能适用于小型软件的开发,对于大型软件来说,它就无能为力;甚至某些特定的嵌入式系统软件,如燃油喷射控制系统,它也会力不从心。
需求蔓延指的是软件开发完成后的功能点高于需求开发结束时的功能点。多出的功能点就是蔓延的需求。使用联合应用设计和原型模拟等方法,可以抑制甚至杜绝需求蔓延。
对于那些“古老”的软件,代码的变更常常会领先需求和设计文档的变更几条街。如果因为维护或者其他原因,需要从这些软件收集需求,是没有办法依靠这些落后的文档,我们只能从代码中来提取需求。这种需求提取,除了代码审查的手工操作之外,还可以借助一些自动化工具。
可执行语言是一些自动化工具产生的,用它来对需求进行描述,可以帮助我们分析需求。MSDN就是目前已知的提供关于可执行语言信息的最好的网站。而且,在理论上,可执行语言还可以利用静态分析工具进行解析,以去除可执行语言中存在的逻辑错误和遗漏。
焦点小组是一个用户集合,这些用户会参与软件的功能、性能的讨论。焦点小组可以对软件产品提供建议,甚至提供软件原型。焦点小组非常适合多用户需求的场景。
功能性需求会增加软件的规模,它可以用功能点估算方法来进行度量;非功能性需求是用户关心的一些限制和约束,如性能指标、可靠性知识,它可能需要一些工作量,但通常不会增加软件的规模。
联合应用设计是正式的需求审查会,参会人员包括用户和开发方的架构师和设计师,双方使用需求检查表进行逐项需求的审查。联合应用设计是收集大型软件需求最有效的方法。
模式匹配的前提是软件的功能都以一种标准的方式记录下来,并建立完整的分类系统,这样通过模式匹配就可以对软件需求进行重用。但是,只要需求还在使用30多种图表并混杂各种各样的语言来描述的话,模式匹配就只能通过人工,自动化的模式匹配不可能实现。
建立软件原型来展示软件的功能和逻辑结构,可以帮助我们进行需求确认。但是原型只会保留大约完整软件1/10的功能。所以,它只是适用少于1000个功能点的软件。因为规模太大,原型的建立会非常困难。原型有一次性和进化性两种。无论哪种原型,都可以成功的减少需求蔓延。
质量功能展开,又叫质量屋,是一种源于日本的质量需求分析方法。一些计算机公司如惠普和IBM,已经将其用于软件产品。但是,要熟练使用质量功能展开并且在软件项目中成功应用,还需要付出大量的训练和实践。
需求工程包括需求提取、需求分析、建立模型、需求检验等活动,它非常适用运行在复杂物理设备上对软件成功运行有着严格质量标准要求的系统软件或嵌入式软件,能够使用需求工程的组织,通常是已经通过了CMMI三级认证的组织。
需求审查是最有效的缺陷去除方法,并有着最高的缺陷去除效率。审查是一项团队合作的活动,参与者包括好的主持人、记录员、审查者及审查对象。
理论上如果为每个确定的需求分配一个唯一识别码或序列号,那么需求的双向追踪就是可以实现的。我们通常使用二维矩阵来进行需求追踪:矩阵的一轴列出所有的需求,另一轴列出包含该需求的文档或代码段,两轴交叉点可以表示该需求是否已分析、已设计和已实现。如果多个软件使用同一个可重用需求,那我们可能就需要使用三维矩阵来跟踪了。
可重用对于软件质量和生产率都是意义非凡。但是,可重用的应用仍然任重道远,因为扩大可重用的比率,需要我们建立起一个完善的可重用功能组件的系统。而要建立这个系统,需要记录以下分类信息:
时至今日,使用防火墙和杀毒软件已经不足以保护软件的安全。安全需求要求我们提高软件代码防外部攻击的能力。一些先进的方法,包括提高软件逻辑运算速度、严格限制权限、使用安全性较高的编程语言等,可以帮助实现软件的安全需求。另外,软件的安全性需求还需要进行安全审查(使用静态分析工具来查找安全漏洞)和安全测试。
统一建模语言是一套内容丰富的图表表示方法不仅包括软件需求的描述,也包括软件架构和数据库设计等描述。使用标准的审查方法,可以很容易地对uml图表进行有效性和一致性检查。
用例的目标是直接描述功能需求,它是用一种有趣的视觉方式来展现用户使用软件时的动作,包括提出请求、修改请求、控制行为和完成请求。用例不仅可以用于正式的需求审查和设计审查,还可以通过功能点分析来预测软件的规模。
用户故事是一种快速灵活的需求收集方式,它通常是和测试用例同时开发出来的。由于用户故事的简洁性,对其正式审查也很难发现其中的缺陷,但是我们可以通过审查测试用例来做一些弥补。 这正是: 武艺虽有十八种,项目适合才有用 需求开发不如意,不妨尝试换神通 |
|