以下属性被认为有利于书写好的软件需求规约(Software Requirements Specification,SRS):
- 正确。每个需求都是对用户需要的精确解释。
- 完整。SRS包含了每个有意义的需求。另外，SRS需要定义系统对每个可能输人的响应，无论输人是正确的或错误的。最后，不应有任何的"待定"。
- 无二义。这意味着每个陈述的需求只有一个解释。模糊的陈述都必须被替换。
- 一致。这是指确保单个需求之间不冲突。可能会有冲突的术语，例如两个术语都意指同一个概念;可能会有冲突的需求，例如一个需求做出了一个关于其所依赖需求的错误假设;还可能在后续的阶段添加一个新需求时，会和已有的需求冲突。
- 可验证。需求规约实际上是开发者和客户机构之间的合同。软件验收标准是开发自需求规约的。因此，每个需求能被测试以确定系统满足需求是必要的。
- 非计算机专家能够理解。因为系统的用户很可能是非计算机专家，所以需求规约以易理解的叙述文字书写是很重要的。
- 可修改。因为需求规约很可能经过多次迭代，并且系统部署之后也需要演化，所以需求规约可修改是必要的。为了辅助该目标，需求规约需要有目录、索引以及交叉引用。每个需求应该只在一个地方陈述，否则，不一致性就可能蔓延到规约中。
- 可追踪。需求规约需要能反向追踪到系统级需求和用户需要，同时也需要能向前追踪到满足需求的设计部件和实现需求的代码部件。
在开发需求规约的过程中会频繁地产生困境，因为上述这些目标中有些是相互冲突的。例如，为了让需求规约更易理解可能会和让其一致和无二义的目标相冲突。在需求规约过程的所有阶段，用户参与是必需的，以确保用户的需要包含在需求规约中。理想情况下，用户也应当在需求规约的团队中。需要和用户一起举行多次评审。开发抛弃型原型对澄清用户需求是有帮助的(详见第3章)。对自动化一个手工系统而言，当用户可能不清楚自动化系统会是什么样子时，原型设计会非常有用。