在现代产品开发中,抽出和管理多个级别的需求和规范是重要的活动。此信息是当今产品整体 IP 的基本部分,并充当将来的工程师在当今设计上进行迭代所需的知识库。对某些人来说,经过验证的需求将充当一个证据,证明工程师实现了自己所承诺的工作,避免产品的用户受到伤害。
数学公式可以是物理现象的模型,同样,需求可看作是产品的模型。传统上,需求“模型”严格地以文本的形式被整理为一系列文档。详述和存储此信息的技术已从打字页面演变为文字处理器,再演变为单一用途需求软件存储库。需求管理点解决方案(如 IBM DOORS)已存活至今,因为它在长久以来是唯一的选择。
近年来,为了跨越旧需求管理工具的鸿沟,已经开发了很多技术标准。两个典型的例子是 OSLC(专注于关联数据)和 ReqIF(专注于同步数据)。这两个方法都只适用于部分使用案例,并会为另一些使用案例带来难题。例如,围绕应用程序定义了一组 RESTful 接口的 OSLC 在可以保持全时段活动 IT 连接的场合最好用。在典型的 OEM 供应商环境中,并非始终是这样的情况。ReqIF 使用 XML 架构来打包要传递给合作伙伴的文档集,但必须实施流程管理以确保所有相关方保持同步。
此领域(通常称为应用程序生命周期管理或 ALM)中的现代工程工具在功能的广度和成熟的深度上都已提升,但这种提升的速度对很多用户来说还不够快。用户一直强烈要求更长久且更大的价值;不会产生额外高成本的价值。
现代 ALM 软件的现实是,这些工具提供的很多基本功能已被商品化,并由任意数量的供应商解决方案提供支持:创建、关联、编辑等。Ovum 在其最新的 ALM 软件评论中写道:“组织开始认识到,基于单个 ALM 解决方案进行标准化可消除影响敏捷性的工具摩擦,并帮助他们更快地向市场交付成果。
当今的 ALM 解决方案的实际价值包括:
在当今的技术公司内,经常可以发现 IT 部和工程部之间存在很大压力。IT 部负责为工程部提供支持,但每个新工具的支持费用都很高,因为需要购买许可证、进行持续维护以及及时对管理员和用户进行培训。随着时间的过去,升级需求工具变成了一个正式 IT 项目,因为新版本仍然必须与工具链中的所有其他系统通信。另一方面,工程师需要“完成工作的最佳工具”,这通常就像是“跟已经了解的魔鬼打交道”,因为他们在上一个项目或上一个工作中使用了这个工具。他们可能不是特别喜欢它,但他们知道如何应对它的缺陷。
工程部和 IT 部都应该问“我们是否真的对当前的仅需求点解决方案满意?”“我们是否从当前工具和供应商获得了所需的一切?”“现在是否是考虑升级到可满足我们的需求的优质 ALM 解决方案的好时机?”