如何做需求分析并根据需求进行设计，如何应对需求变化
系统开发的第一步为确定客户需求，只有开发出满足客户需求的系统才算是完成了工作，才算是有功劳。所以，不管因为什么原因，最后开发出的系统满足不了需求的话，开发人员的努力就变成了只有苦劳，没有功劳。需求来自于客户，确定需求的方式通常为由客户描述需求 ，开发人员根据客户的需求描述撰写需求文档。
确定客户需求存在两个难点：
一、是客户并不一定能准确的描述其需求；
正如亨利·福特所言：如果我当年去问顾客他们想要什麼，他们肯定会告诉我：「一匹更快的马」。
二、是需求会经常变。
需求唯一不变的就是它是变化的，几乎所有的开发人员都吃过需求临时变动的亏。
客户是开发人的衣食父母，开发人员有责任挖掘出真实需求并应对未来的需求变化。
下图可以很好的说明为什么客户需求这么难确定及错误的需求所带来的后果：
那么怎样才能更好的确实和满足用户的需求呢？这个问题可以分解为两个问题：一是，如何分析和确实用户需求；二是，如何应对用户需求的变化。
如何分析和确定需求？
《程序员的修炼之道》提供下面两种方法：
Don't Gather Requirements - Dig for Them
不要搜集需求 -- 挖掘它们。
许多书籍和教程都把需求搜集当作项目的早期阶段。“搜集”一词似乎在暗示，一群快乐的分析师，随着背景播放温柔的《田园交响曲》 ，寻觅散布在四周地面上的智慧金块。“搜索”暗示需求已经在那里 -- 你只需要找到它们，把它们放进你的篮子里面，就可以愉快的上路了。
事情在很大程度上并非如此。需求很少存在于表面上。通常，它们深深地埋藏在层层假定、误解和政治手段下面。
挖掘需求
当你在尘土里四处挖掘时，你怎样才能识别出真实的需求？答案既简单又复杂。
简单的回答是，需求是对需要完成的某件事情的陈述。以下陈述是好需求：
只有指定人员才能查看员工档案。
汽缸盖的温度不能超过临界值，该值因引擎而异。
编辑器将突显关键词，这些关键词根据正在编辑的文件类型确定。
但是，极少有需求像这样明子，这也正是需求分析复杂的原因。
用户可能会这样陈述上面列出的第一条陈述：“只有员工的上级和人事部门才可以查看员工的档案。”这个陈述真的是需求吗？今天也许是，但它在绝对的陈述中嵌入了商业政策。政策会经经常改变，所以我们可能并不想把它们硬性地 写入我们的需求。使需求成为一般性的陈述，并把政策信息作为例子给开发者 -- 他们需要在实现中支持的事物类型的例子。最后，政策可以成为应用中的元数据。
这是一种相对微妙的区别，但对开发者却有着深远的影响。如果需求被陈述为“只有人事部门员工才能查看员工档案”，开发者最后就可能会编写代码，在每次应用访问这些文件时进行明确的检查。但是，如果陈述是“只有授权的用户可以访问员工档案”，开发者可能会设计并实现某种访问控制系统。当政策改变时（它会改变的），只有该系统的元数据需要更新。事实上，以这样的方式搜集需求会很自然地让你去开发为支持元数据而进行了良好分解的系统。
找出用户为何要做特定事情的原因，而不只是他们目前做这件事情的方式，这很重要。到最后，你的开发必须解决他们的商业问题，而不只是满足他们陈述的需求。用文档记载需求背后的原因将在每天进行实现决策时给你的团队带来无价的信息。
在实际工作中我也遇到过这样的需求描述：“客服具有提现初审权限，出纳岗具有提现审核权限，会计岗具有提现付款权限”。代码实现绑定了实际的岗位，结果权限无法赋给其它岗位。如果有某个岗位的人请假，需要将此项工作交接给其它人，就需要改动代码。此时变动的其实不是需求，而是实际的政策。实际需求应当为：不同岗位具有不同的提现审核权限。用户的描述是实际的政策，需要在程序开发好后进行配置。这样提现的审核权限就能够赋给其它岗位的人，从而应对因某岗位请假需要其它岗位人员操作此项功能的需求。
Work with a User to Think Like a User.
与用户一同工作，以像用户一样思考。
在这一点上我持保留意见，客户和开发看问题的视角几乎完全不同，很难做到换位思考，极有可能表错情、会错意。持续频繁的交付可用版本，持续沟通才是王道。
如何适应需求变化？
系统设计
- 前瞻性设计：考虑可能的需求变化。避免过度设计，只往前多考虑一步。
- 保持模块简单；
- 解藕；
- 拼装。
抽象：用户描述的需求通常都是具体的，需要抽象出一般的需求。
通过抽象能找出用户的真实的需求
比如：
需求：一匹更快的马
真实需求：更快的速度
所以福特造出了汽车。
抽象出真实需求使解决方案增多
比如：需要喝可乐
真实需求：口渴了
可以提供任何一种饮料。如果刚好有矿泉水的话，就能够满足需求。
抽象的实现更能应对需求的变化
需求：只有员工的上级和人事部门才可以查看员工的档案。
上述需求描述嵌入了商业政策，而政策会经常改变，所以我们不能把它们硬性地写入我们的需求。可抽象为：只有指定人员才能查看员工档案，使需求成为一般性陈述，并把政策作为例子发给开发者 ，政策可以成为应用中的元数据。
正如《程序员的修炼之道》之中所说：
Abstractions Live Longer than Details.
抽象比细节活得更久。
可配置（元数据）
现在的用户界面都具有换肤功能，可满足用户喜爱不同颜色的用户的需求
总结：
完全照着当前的需求做对开发人员来说是最简单的，却肯定不能适应未来的变化。如果我们不深入思考用户的需求陈述背后的意义，我们设计的系统会连政策的改变都无法支持。而政策的改变是极其频繁的，这让开发人员疲于应付。作为开发人员，无论是从自身利益还是用户利益考虑都要求我们必须进一步的思考。思考用户的需求陈述是不是真的需求，思考未来可能的需求变化，从而让我们的努力不会白费。
参考资料：
用Unix的设计思想来应对多变的需求 http://coolshell.cn/articles/7236.html
