需求的重要性首先需求要明确明确的需求确保用户驾驭系统的功能需求是对客户问题或项目问题的回答与分解明确的需求能够圈定系统的范围是解决构建编程期间分歧的标准明确的需求能够减少编码后的需求变更情况。其次需求要详细详细的需求是架构、设计、构建、测试的基础过分粗糙的需求不仅说明没有充分理解、分析客户问题同时也为可能为设计缺陷甚至是错误的产品埋下隐患。需求变动的必然性总有人期待需求一经确定就不会变更但有实际项目经验的人都知道客户不仅会变动老的需求同时也会产生新的需求作为软件从业人员首先要接受这个现状。客户需求之所以变动、新增究其原因是随着系统的迭代、客户的试用、彼此的沟通客户对正在进行的项目有越来越深的理解所以才产生了需求的变动接受这个大前提就不会当出现新的或者变动的客户需求时而产生厌烦、暴躁的对抗情绪。构建编码期需求变动的应对首先要评估需求的质量具体可以参考《代码大全》中列出的需求核对表。不要拿到一个需求就急于开发应该首先评估需求的质量这样不仅不会影响进度反而会提高进度因为方向错误的需求开发反而会拖累项目进度。除了需求的质量外也可以考察需求的商业价值即该需求是否提供了更多的商业价值如果只是一个无法增加商业价值的特色功能那么果断放弃。其次要让项目相关人明确知道需求变更的代价对于软件开发人员这可能是绩效、项目进度对于因为新的需求而热血上头的客户则可以告知新需求的成本包括时间和金钱成本让他们从必须完成这个需求转变成“如果有更好”。不仅如此项目组本身也需要有一套需求变更程序例如一个专门的需求变更控制委员会增加这一层缓冲不仅可以用来评估需求变更和更改方案的合理性同时也能让开发人员不必疲于跟踪不断变化的需求而只需要在固定的时间处理考察过的需求变更。同时为了更好地应对需求变更也可以采用更有效率的开发方式比如分阶段交付系统构造-试用-反馈-修改-继续建造。如果上述的应对方式都没有或者失效那么尝试着放弃项目也未必不是一个选择。需求核对表引用自《代码大全第二版》3.4节功能性需求是否详细定义了系统的全部输入包括其来源、精度、取值范围、出现频率等是否详细定义了系统的全部输出包括目的地、精度、取值范围、格式等是否详细定义了所有的输出格式web页面报表等等是否详细定义了所有硬件和软件的外部接口是否详细定义了全部外部通信接口包括握手协议、纠错协议、通信协议等是否列出了用户想要做的全部事情是否详细定义了每个任务要用的数据以及每个任务得到的数据非功能需求是否为全部必要的操作从用户的视角详细描述了期望响应时间是否详细描述了其他与计时相关的考虑如处理时间、数据传输率、系统吞吐量是否详细定义了安全级别是否详细定义了可靠性包括软件失灵的后果、发生故障时需要保护的至关重要的信息、错误检测与恢复的策略是否详细定义了机器内存和剩余磁盘空间的最小值是否详细定义了系统的可维护性包括适应特定功能的变更、操作环境的变更、与其他软件的接口的变更能力是否包含对成功的定义、失败的定义需求的质量需求是用“”用户的语言“”书写的吗用户也是这么认为的吗每条需求都不与其他需求冲突吗?是否详细定义了相互竞争的特性之间的权衡例如健壮性与正确性之间的权衡是否避免在需求中规定设计方案需求是否在详细程度上保持相当一致的水平有些需求应该更详细地描述吗有些需求应该更粗略地描述吗需求是否足够清晰即转交给一个独立的小组去构建他们也能理解吗开发组也这么想吗每个条款都与待解决的问题及其解决方案相关吗能从每个条款上溯到它在问题域中对应的根源吗是否每条需求都是可测试的是否可能进行独立的测试以检验满不满足各项需求是否详细描述了所有可能的对需求的改动包括各项改动的可能性需求的完备性对于在开始开发之前无法获取的信息是否详细描述了信息不完全的区域需求的完备度是否可以达到这个程度如果产品满足所有需求那它就是可接受的你对全部需求都感到很舒服吗你是否已经去掉了那些不可能实现的需求——那些只是为了安抚客户和老板的东西