需求元数据属性—第1部分


最近,我被要求为一位客户提供一份需求管理属性(也称为元数据)的建议列表。我立即打开相对较新的笔记本电脑,搜索我在过去几年中建立的列表。但我找不到它,所以我转到选项2-搜索引擎。我使用谷歌、雅虎和必应搜索“需求属性”、“需求元数据”和其他几个相关短语。我从美国交通部的一个项目中得到了一个相关的匹配(http://www.itsdocs.fhwa.dot.gov/JPODOCS/REPTS_TE/14424_files/appendix_b.htm)。所有的睡觉要么都在解决需求的好坏(例如,原子的、可验证的、唯一的,等等)。或者是太模糊而没有用。“所以从记忆中重新生成列表是不可能的。”然后我决定发布这些列表,希望下次有人搜索需求属性或需求元数据,甚至是需求表征时,他们能找到这个列表,这有助于他们解决需求管理问题。

我将列表分为三个部分。第一部分是基本需求属性。这些是我发现我需要的需求属性,无论是域还是项目。

基本属性:

需求ID

-每个需求的唯一标识符,以便可以明确引用。我建议这是用户控制下的标识符,而不是由需求管理工具自动分配的标识符。能够控制ID有助于需求模块的重用和合并。

源ID

-交叉引用涉众需求文档以便于跟踪。这一基本需求属性不必是需求管理工具中的一个字段。事实上,我认为它最好是一个自动链接,例如可以在需求管理工具或SysML建模工具中实现的链接。

需求文本

-要求的文本声明应该是格式良好的声明。-Karl Weigers有一篇关于撰写高质量要求的好文章,请访问http://www.processimpact.com/articles/qualreqs.html

日期

-在项目生命周期中,并非所有需求都是同时接收、分解或派生的。“该字段允许系统工程师进行基于时间的分析。

有效性/发布

-发布或迭代的特定于计划的指定,在该指定中将交付需求的满足。

验证

-验证方法应该定义为单独的属性。因为很多需求都是使用多种技术进行验证的,所以每种验证类型的布尔值都可以捕捉到这种关系。传统的验证方法是,

分析

检查

示范

测试

从这些属性开始。一旦您有了这些属性,您就应该有了一个基础设施,以便在您准备好时添加更多的需求属性。

我想知道你对这份最初的清单有什么看法。你还有什么其他你认为必不可少的需求属性吗?对下一份列表--那些非常令人向往的属性--你有什么建议吗?