标识方法，并阐明他们的好处和缺点。能选择最适合你的方法。
(1) 序列号最简单的方法是赋予每个需求一个唯一的序列号，例如SRS-13。当一个新的需求加入到商业需求管理工具的数据库之后，这些管理工具就会为其分配一个序列号(许多这样的工具也支持层次化编号)。序列号的前缀代表了需求类型，例如SRS代表“软件需求说明”。由于序列号不能重用，所以把需求从数据库中删除时，并不释放其所占据的序列号，而新的需求只能得到下一个可用的序列号。这种简单的编号方法并不能提供所有相关需求在逻辑上或层次上的差别，而且需求的标识不能提供所有有关每个需求内容的信息。
(2) 层次化编码这也许是最常用的方法。如果功能需求出目前软件需求规格说明中第3 . 2部分，那么他们将具有诸如3.2.4.3这样的标识号。标识号中的数字越多则表示该需求越周详，属于较低层次上的需求。即使在一个中型的软件需求规格说明中，这些标识号也会扩展到许多位数字，并且这些标识也不提供所有有关每个需求目的的信息。如果你要插入一个新的需求，那么该需求所在部分其后所有需求的序号将要增加。删除或移去一个需求，那么该需求所在部分其后所有需求的序号将要减少。但其他地方的引用将混乱，对于这种简单的层次化编号的一种改进方法是对需求中主要的部分进行层次化编号，然后对于每个部分中的单一功能需求用一个简短文字代码加上一个序列号来识别。例如，软件需求规格说明可能包含“第3.2.5部分?编辑功能”，并将此部分编写成子模块文件，然后设置管理。
有时，你觉得缺少特定需求的某些信息。在解决这个不确定性之前，可能必须和客户商议、检查和另一个系统的接口或定义另一个需求。使用“待确定”(to be determined, TBD或采用汉语拼音略写DQD)符号作为标准指示器来强调软件需求规格说明中这些需求的缺陷。通过这种方法，你能在软件需求规格说明中查找所要澄清需求的部分。记录谁将解决哪个问题、怎样解决及什么时候解决。把每个TBD编号并创建一个TBD列表，这有助于方便地跟踪每个项目。
在继续进行构造需求集合之前，必须解决所有的TBD问题，因为所有遗留下来的不确定问题将会增加出错的风险和需求返工。当研发人员遇见一个TBD问题或其他模糊之处时，他可能不会返回到原始需求来解决问题。多半研发者对他进行猜测，但并不总是正确的。如果有TBD问题尚未解决，而你又要继续进行研发工作，那么尽可能推迟实现这些需求，或解决这些需求的开放式问题，把产品的这部分设计得易于更改。
编写优秀的需求文件没有现成固定的方法，最佳是根据经验进行。从过去所遇见的问题中可使你受益匪浅。许多需求文件能通过使用有效的技术编写风格和使用用户术语而不是计算机专业术语的方式得以改进。
你在编写优秀的需求文件时，希望读者还需牢记以下几点建议：
保持语句和段落的简短。
采用主动语态的表达方式。
编写具有正确的语法、拼写和标点的完整句子。
使用的术语和词汇表中所定义的应该一致。
需求陈述应该具有一致的样式，例如“系统必须..”或“用户必须..”，并紧跟一个行为动作和可观察的结果。例如，“仓库管理子系统必须显示一张所请求的仓库中有存货的库存清单。”
为了减少不确定性，必须避免模糊的、主观的术语，例如，用户友好、简单、有效、、最新技术、优越的、可接受的等。当用客说“用户友好”或“快”时，你应该明确他们的真正含义并且在需求中阐明用户的意图。
避免使用比较性的词汇，定量地说明所需要提高的程度或说清一些参数可接受的最大值和最小值。当客户说明系统应该“