编写需求文档

　　（1）需求文档包括用户需求和详细的系统需求描述。

　　（2）要求

　　    正确：正确地反映用户的真实意图；

　　    清楚：易读易懂；

　　    无二义性

　　    一致

　　    完备：没有遗漏一些必要的需求；

　　    可实现： "可实现"意味着在技术上是可行的，并且满足时间、费用、质量等约束；

　　    可验证

　　    确定优先级：确定高中低三个级别，将风险降到最低。

　　    阐述"做什么"而不是"怎么做"

　　需求验证

　　（1）需求验证是为了确保需求规格说明准确、完整地表达了必要的质量特点。

　　（2）审查需求文档、依据需求文档编写测试用例、确定产品验收合格的标准。

　　（3）验证内容：有效性、一致性、完备性、现实性等。

　　需求管理的重要性

　　如果对已经建成的大楼不满意，要求设计师把大楼的结构调整一下，别人一定会认为这很荒唐。但在软件项目中，这样的事情很常见。

　　软件缺陷，发现和修复的越早则成本越低。不幸的是，需求阶段出现的错误往往很难发现，所以需求管理也需要讲究科学。

　　原则：需求必须分优先级、必须文档化、需求一旦变化就必须对需求变更的影响进行评估。

　　需求变更存在的必然

　　大师说："没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。"

　　变更管理

　　进行变更管理，首先要建立变更控制委员会，变更管理过程包括变更描述、变更分析和变更实现三个阶段：

　　变更描述：始于一个被识别的需求问题或一份明确的变更提议

　　变更分析：评估被提议的变更产生的影响

　　变更实现：执行变更，需求文档、系统设计和实现都要修改

　　变更描述阶段，产生需求变更请求表

　　变更影响分析

　　需求变更影响分析模板中包括的内容：

　　    变更请求号

　　    标题

　　    描述

　　    分析者

　　    分析日期

　　    优先级评定

　　    相关代价、收益与风险

　　    预计对进度、成本、质量的影响

　　    被影响的其他需求及任务

　　    要更新的计划及文档

　　变更控制流程

　　需求状态

　　定义：某时间点需求的情况反映。

　　客户需求的四种情况：

　　    客户可以明确且清楚地提出的需求

　　    客户知道需要做什么，但却不能确定的需求

　　    客户提出需求，但需求的业务不明确

　　    客户自己也说不清楚的需求

　　需求状态：

　　已建议   已批准  已拒绝

　　已设计   已实现  已验证

　　已交付   已删除