书写要简洁

> 一组对比

* 1: “目标跟踪功能应提供显示所有活动目标的当前跟踪坐标的能力” （偏书面定义）

* 2: “在跟踪时，系统应显示所有活动目标的当前位置” （便于理解）

并非所有的需求都是同样重要的

> 一种定义优先级的方法
* 需求规格说明书中每个需求加上后缀 M、D、O 
    * M：必须 Mandatory
  * D：期望 Desirable
  * O：可选 Optional

* 给需求按照重要性打分：0～10

Davis, A., Software Requirements: Objects, Functions and States, Englewood Cliffs, N.J.: Prentice Hall, 1993, Section 3.4.11.

有层次地组织需求

> 组织需求的优点
* 易于读者理解系统功能

* 易于需求编写者在需求变更时定为章节


> 不同类别的需求说明
* 用户角度

* 激励角度

* 反馈角度

* 对象角度

* 功能角度

* 系统模式角度

Davis, A., Software Requirements: Objects, Functions and States, Englewood Cliffs, N.J.: Prentice Hall, 1993, Section 3.4.11.

任何单一的需求视角，不足以理解或描述一个复杂系统的预期外部行为

> 有效需求视图组合
* 复杂系统，需要面向对象分析来评估那些与软件相关的重要实体，面向对象（OOA）可以帮助确定实体，理解他们之间的关系和相关属性

* 使用有限状态机来描述用户操作界面的预期行为

* 可以使用决策树来描述在相应外部条件的复杂组合时系统的预期行为

Yeh, R., P Zave, A. Conn, and G. Cole, Jr, "Software Requirements: New Directions and Perspectives," in Handbook of Software Engineering, C.Vick and C. Ramamoorthy, eds., New York: Van Nostrand Reinhold, 1984, pp. 519-543.

没有一种需求分析方法适用于所有软件

> 一些建议
* 数据密集型软件，应使用实体关系图(Entity-Relation Diagram)

* 对于反应式（实时）系统，应使用有限状态机或者状态图

* 对于决策密集型的软件，应使用决策表

Davis, A.,"A Comparison of Techniques for the Specification of External System Behavior," Communication of the ACM, 31, 9 (Sep. 1988), pp. 1098-1115.

需求阶段的目标是明确系统的外部行为

> 需求的明确
* 系统的外部行为需要足够明确，以保证所有设计人员能够对系统的目标行为做出同样的理解

* 需求阶段不应该去明确软件架构与算法（设计人员的范畴），设计人员可以设计出最满足需求的架构和算法

* 如果撰写需求文档时，需要一定的系统设计情况下，应该提供以下类似的信息：
    * Warn: 这里包含的设计，仅用于辅助理解产品的外部行为，在系统外部行为相同的情况下，设计人员可以选择任何设计方案。

Davis, A., Software Requirements: Objects, Function and Stats, Englewood Cliffs, N.J.: Prentice Hall, 1993, Section 3.1.

在进行设计或编码前，应该对需求规格说明进行正式的评审

> 规格说明书
* 规格说明书一般是自然语言编写的，但也有部分用更正式的语言编写的（原则28、54、55）

* 某些部分的说明可以进行手工评审

* 可执行的需求可以用适当的工具进行演示，相关人员可以看到系统功能，而不只是通过“阅读”了解系统如何运行

Boehm,B., "Verifying and Validating Software Requirements and Design Specifications," IEEE Software, 1, 1(Jan. 1984), pp. 75-88.

编写需求规格说明书时，要清晰识别有用的最小子集、识别使最小子集越来越实用的最小增量

> 这种识别可以：
* 更容易地使每个组件只包含一个功能

* 选择更具内聚性和可扩展性的架构

* 了解如何在日程或预算紧缩的情况下减少功能

> 技巧
* 在每个需求旁加上几列，每列对应不同的版本

* 每个版本对应不同的客户或场景 / 产品随时间提升level的层级

* 用 x / ✅ 提示哪些版本将具有哪些功能

Parnas, D., "Designing Software for Ease of Extension and Contraction", IEEE Transactions on Software Engineering, 5, 2(Mar. 1979) pp.128-138.

当作出需求决策时，记录一个指向其来源的标识。

* 创建需求规格时，需要完成很多工作：
    > 调研
    > 讨论
    > 架构设计
    > 工作机制
    > JAD(Joint Application Development)/RAD(Rapid Application Development) 
    > 系统的需求规格说明
    > 早期系统层面需求分析


* 作出需求变更（添加 / 修改），需要知道原始需求背景：为了解决什么问题，是否可以安全地变更，修改是否能匹配系统


* 作出需求决策时，需要记录需求时间、参与者、所参考的文字 / 录音等，基于这样的记录
    > 拓展需求
    > 在已完成的系统不能满足需求时及时做出响应

Gilb, T., Principles of Software Engineering Management, Reading, Mass.: Addision Wesley, 1988, Section 9.11.

* 原型更高效，以低风险、高回报的方式；

* 提供给用户一个真实系统的印象，有助于确认需求，赢得客户和用户的心。

Andriole, S., "Storyboard Prototyping for Requirements Verification" Large Scale Systems, 12(1987), pp. 231-247.