难度中 影响低
1. 维护需求变更的历史记录
记录需求规格说明变更的日期、变更的内容、变更的实施者和原因。
2. 跟踪投入需求工程的工作量
使用这些数据来评定计划的需求活动是否如期完成，利用这些数据还可以为将来的项目更好的计划所需的资源。有助于评估对需求工程的投资和回报。
难度低 影响高
1. 在应用领域培养开发者
帮助开发人员对应用领域有一个基本的理解。这样可以减少开发过程中的混淆、误解和返工。
2. 定义项目前景和范围
前景（vision）说明使所有涉众可以对产品的目标达成共识。
范围（scope）则定义了需求是否属于某个特定版本的界线。
3. 用户群分类
将产品的用户分成组，已避免出现某一用户群的需求被忽略的情况。
4. 绘制关联图
关联图是显示新系统如何适应环境的一个简单的分析模型。定义了正在开发的系统和系统的外部实体（如用户、硬件设备和其他信息系统）之间的界线和接口。
5. 确定需求来源
为保证所有涉众都明白SRS中为何包括这些需求，以及便于进一步阐明需求。可以通过使用跟踪链或定义需求属性来确定需求来源。
6. 建立需求基线和控制版本
基线是已经被提交到一个指定版本中的实现（implementation）的需求组成的，在需求被定为基线后，只能通过定义的变更控制过程来实现变更。使用合适的配置管理工具，将需求文档置于版本控制之下。
难度低 影响中
1. 分析可行性
在允许的成本和性能的要求下，分析在指定的运行环境下实现每项需求的可行性，明确与每项需求实现相关的风险，包括与其他需求之间的冲突、对外界因素的依赖以及技术上的障碍。
2. 创建术语表
定义应用领域专业名称的术语表可以减少误解。
3. 编写数据字典
数据字典中包括系统用到的所有数据项和结构的定义。使参与项目开发的每个人都使用统一的数据定义。方便客户和开发团队之间的交流。
4. 观察用户执行工作的过程
能够确定用户对新的应用程序可能有哪些应用。可以通过一张简单的工作流程图（最好用数据流程图）来描绘用户什么时候拥有什么数据，以及怎样使用这些数据。
5. 确定系统事件和响应
列出系统可能发生的外部事件以及对每个事件所期待的响应。
6. 为每项需求注上唯一的标号
这种规约（标号）应该很健全，经得起随时间推移发生的对需求的增加、删除和修改。为需求标号使得需求可以被跟踪，其变更可以被记录。
7. 测试需求
根据用户需求推导出测试用例，以便记录产品在特定条件下应有的行为。与客户一起对用例进行走查，已确保它们反映了所期望的系统行为。每项需求都应有其对应的测试用例。
8. 跟踪需求状态
建立一个数据库，为每一项功能的需求保存一条记录。保存每项需求的重要属性，包括需求的状态。
9. 从其他项目的需求工程中积累经验
难度低 影响低
1. 检查问题报告
客户的问题包括及补充为需求提供了很多建议，提出在新产品或新版本中应添加哪些功能。
