需求工程最终会形成需求规格说明（系统外部行为的详细描述）。
> 如果采用需求规格说明书中架构作为软件架构，则会发生几种情况：
1. 需求分析阶段，不考虑优化设计，则不能最为最终设计；
2. 在需求分析阶段，组织负担不起做底层的设计，所以要进行分析及选优；
3. 不可能存在某一架构或方法对所有软件都理想（需求规格说明书中的“架构”作为软件架构）
Cherry, G., Software Construction by Object-Oriented Pictures, Canadaigua, New York: Thought Tools, 1990,p.39.
需求是复杂不稳定的。可以将需求保存在数据库、电子文档中，方便修改、排查、记录需求的细节属性。
> 需求的数据库中存储内容应包括（原书）：
* 需求的唯一标识（原则52）
* 需求的文本描述
* 需求关系
* 需求的重要性
* 预期的需求变更
* 需求的来源标识
* 需求应用的产品版本
> 现有的工具
* 百度 iCafe
* 腾讯 TAPD
* Atlassian 的 Jira
通常，需求规格说明书中不应包含 TBD （To Be Determined），但可以以此版本为基准版本更新。
* 创建 TBD 时，需要明确修改人、修改时间
* 保证 TBD 不会一直保留
IEEE, ANSI/IEEE Guide to Software Requirements Specifications, Standard 830-1994, Washington, D.C.: IEEE Computer Society Press, 1994.
需求规格说明通常会定义系统环境的特征，但当系统环境超出这些限制时，应当明确系统行为。
> 正确的解决方案：
* 当环境超出为其定义的任何约束时，在软件需求规格说明书中应明确声明预期的系统响应。
Davis, A., Software Requirements: Objects, Functions and stats, Englewood Cliffs, N.J.: Prentice Hall, 1993, Section 5.3.2.
不要含糊其词，软件的可靠性应当被准确说明。
> 应区分以下概念，用以编写可靠性需求：
* 需求失效 （Failure on Demand），系统正确响应的可能性（百分比）是多少。
* 失败率（Rate of Failure），这个概念和“需求失效”类似，但以单位时间内的数值来衡量。
* 可用性（Availability）系统可用的时间百分比是多少？
Sommerville, I., Software Engineering, Reading, Mass.: Addison-Wesley, 1992, Section 20.1
需求规格说明书应被大范围的个人或组织阅读和理解。包括不限于用户、客户、设计师、开发人员、测试人员、管理人员等。
> 有效方法：
* 保留自然语言（原则54）
* 结合更形式化的多视角（原则48、53）
Davis, A., Software Requirements: Objects, Functions, and Stats, Englewood Cliffs, N.J,: Prentice Hall, 1993, Section 3.4.5.
先用自然语言描述，再采用形式化模型描述。
> 最好的办法是
1. 写自然语言
2. 写形式化描述
3. 根据形式化模型中发现的问题去修改自然语言，以减少歧义
在试图减少歧义时，应当鼓励使用比自然语言更精准的符号，但会使规格说明变得更不好理解。
> 可以使用：
* 有限状态机、状态图等来减少歧义（原则53）
* 同时保留自然语言描述、形式化符号
Meyer, B., "On Formalism in Specifications", IEEE Software, 2, 1(Jan. 1985), pp. 6-26.
自然语言存在歧义，但可以通过评审、重写有歧义的文字。
> 减少歧义的三个方法：
1. 软件需求规格说明采用 范根检查法 Fagan Inspection
2. 尝试对需求构建更形式化的模型，并在发现问题后重写自然语言描述（原则28）
3. 排版，对开页包含自然语言描述、形式模型描述
· 注：范根检查法是从文档中发现缺陷的流程。
Davis, A., Software Requirements: Objects, Function and states, Englewood Cliffs, N.J.: Prentice Hall, 1993, Section 3.4.2.
需求规格说明书中的每条需求都容易被引用，对设计中追踪需求、测试中追踪需求。
> 书中给出的常用方法
* 给需求打上唯一标识符
* 每个段落编号
* 给需求包含限定词：应该、需要、一定 ……
> 书中给出的编号方法过时，但思路是对的。（编者按）
Gilb, T., Principles of Software Engineering Management, Reading, Mass.: Addson Wssley, 1988, Section 8.10.