4.快速迭代，快速上线，持续完善
　　业务人员有时候提出的需求具有一定的前瞻实验性质，这时候我们需要将该需求快速上线并接受市场的检验，如果业务人员提出的需求满足市场需要，则可以推广实施。否则将该需求进行修改完善。
　　非功能性需求的管理
　　系统需求可以分为功能性需求和非功能性需求，业务人员或PD提出的需求一般称之为功能性需求，也是系统必须完成的行为或功能。非功能性需求是指依一些条件判断系统运作情形或其特性。包括安全性、可靠性、健壮性、灵活性、可扩展性等。
　　业务人员或PD对非功能性需求往往不太关注，这要求项目团队在进行系统架构设计时需要根据项目的具体背景如目标用户群、访问量等考虑如何实现非功能性需求。同时在制定项目计划时，也要考虑实现这些内容的工作量。非功能性需求的实现往往是考验项目团队系统架构设计能力的时候。
　　在我们的实际工作中，非功能性的需求往往需要和基础架构一起配合实现。比如基础架构帮我们实现了一部分的安全性、可靠性、健壮性、可扩展性等。但有一些是系统自己本身要考虑的。如产品评价列表用户访问量很大，我们在实现时可以考虑将其放入tair缓存。如果访问量进一步上升导致tair限流，这时候可以考虑加入本地缓存来做分级缓存。
　　再比如如果我们开发的是一个内部系统，对浏览器的兼容性要求没有那么高；如果是一个外部系统，在开发时需要考虑支持目前主流的浏览器，对浏览器兼容性做好测试。
　　在进行非功能性需求设计时，还需要注意的一点是不要过度设计。这里所说的更多的是技术上的过度设计。设计过度复杂的系统会限制扩展能力。简单的系统更容易维护和扩展，且成本更低。当然，不过度设计不代表轻视设计，而是演进式的设计。每一次的重构和迭代都映射和更新到新的设计中来，从而大限度的满足系统的功能性需求和非功能性需求。（扯远了）
　　总之，如果不在系统设计时充分考虑非功能性需求的实现，往往会在系统上线后带来严重后果。
　　日常维护中的小需求的管理
　　项目经过几轮迭代后，整体架构和需求趋于稳定，这时候项目更多的时间是对需求细节的完善。这时候提出需求的业务方，更多的是系统某一个功能的使用者，提出的需求往往具有片面性。这时候作为系统开发人员，要站在全局的角度去考虑问题，避免实现需求后却对系统的灵活性、扩展性等产生影响。