现在让我们看一下完整、规范化的原子需求是怎样构成的。在我们处理构成一项需求的每个部分时，可考虑如何发现它，它如何适用于你的项目。
需求编号
每项需求必须有唯一的标识。原因很简单:需求在产品开发过程中必须是可追踪的，所以给每项需求一个唯一的编号是合理的。如何唯一地指定需求并不重要，只要用某种方式完成就行。
需求类型
以下几点说明了给需求附上类型是有用的。
可以根据其类型来分类。通过比较一个类型的所有需求，更容易发现互相冲突的需求。
理解了需求的类型，更容易写出适当的验收标准。
通过按类型对已知的需求分组，重复的需求或遗漏的需求就更明显了。
将需求按类型分组也有助于让利益相关者参与。例如，可以很容易地确定出所有的安全需求，将它们交给安全专家复查。
事件/用例编号
使用业务事件作为划分工具，工作上下文范围被分解为一些小块。工作对每个业务事件的响应就是业务用例(BUC)。如果你决定了业务用例的哪部分由产品来处理，那就是产品用例(PUC)。
为了方便引用，所有这些都有标识符，通常就是一个数字。你可以针对任何部分来编写原子需求，但通常业务分析师针对BUC编写需求。不论针对哪个层面来编写需求，你都应该提供标识符。事件/BUC/PUC#让你和所有人能从原子需求回溯到它的群组。
回溯是有用的，但能够针对一个BUC汇集整套需求更有用。这让你能验证这个BUC的所有需求是否已经编写。并且，假定你一次实现一个BUC，这让开发者更清楚地看到需要完成的任务。
描述
描述是该项需求的意图。它是一句英语(或你使用的自然语言)句子，用利益相关者的词汇说明他们想要的是什么。不必太关注它是否有二义性，但也不应太随意地使用自己的语言。验收标准将确定这项需求的准确含义，让它可测试。写下描述的目的是记录利益相关者的意愿。所以就目前来说，描述只要清楚到你和利益相关者能明白就行了。
理由
理由是需求存在的原因。它解释了为什么该需求是重要的，该需求对产品的目标作出了什么贡献。为需求加上理由有助于你和利益相关者理解需求真正的要求。理由指出了需求的重要性，告诉开发者和测试者要花多少工作来开发和测试它。
在用户故事(故事卡片)中，理由是故事的"以便能实现......"部分。我们强烈建议你总是包含理由，只有在最迟钝的人都很清楚需要这项需求时才省略理由。
来源
来源是首次提出该需求的人，或者要求该需求的人。你应该为需求附上提出者的姓名或首写字母，以防有问题或需要澄清，或者该需求与另一项需求发生冲突。如果它被质量关拒绝，这也有用。需求提出者必须拥有适合该类需求的知识和职权。