隐形需求或者说伪需求，是指客户需要解决一个问题，需求分析人员或者程序设计人员并没有真正理解客户需要解决的问题实质，或者说没有站在客户角度去想问题解决问题。
比如在某某系统中，用户（使用该系统的人，不是后台管理人员）可以申请一个业务，申请的时候需要填写一个表单数据，这个表单数据对于客户（拥有该系统的人，或者该系统的管理员）来说，是要保密的，也就是说其他用户不允许看到任何别的用户的申请数据，但后台管理员是可以看的。
需求就是这样，其实很简单，但是解决的方法是有很多的，按照用户的说法，这个表单的数据要保密，那么我们就把表单数据加密后保存到数据库中，这样应该很保密了吧，这样做确实没有任何问题，也可以解决用户的需求。
那这样做到底有什么问题呢，好，我们先不看这个需求，先看看整体业务流，也就是这个表单相关的功能，大概有：后台管理员查看、表单填写的用户编辑，查看。既然后台是可以查看的，填写的用户是可以编辑的，那加密又有何用呢，还不是得解密，当然需求人员可以说，加密后数据库里面就是密文了，不可能随意看，我想说的是，数据库管理员是客户给的权限，这个可以从行政上解决。
其实对于这个问题，客户只是想A用户填写的信息不会被B用户看到，在进一步说，后台可以加一个权限，让有权限的人才可以看用户填写的数据，这样才是客户所要看到的，而不是去加密解密。
今天在园子里面也看到相似的例子，帖子就不说了，具体就是说，用户在填写数据的时候，点击按钮提交失败了，然后数据就没了，不能保存了，提示数据库连接问题，客户就抱怨为什么数据库连接不上不早告诉我，还要让我重新填写数据。
这个问题对于填写数据的人来说，确实不好，好端端的填了那么多数据，就因为数据库断开就了就要重新填写，是你肯定也会发狂，那个帖子的解决方法就是根据客户所说的，在数据库断开的时候给提示下，后面用了很复杂的技术才解决，至于解决的结果是怎么样，就不得而知了，但对于那个解决方法我有个疑问。
什么疑问呢，那就是用户说的数据库断开了就告诉他，这个是客户的真正问题吗，我觉得真正的问题是，不管失败还是成功，都不要我客户重新填写表单，我想这样做客户肯定会答应，如果是这样的那就好办多了，怎么实现大家自己想想吧。
其实这样的例子还有很多，大部分都没有理解客户的真正目的，解决的方法也是站着技术角度想的，所以最后用了很复杂的技术实现了一个对于客户来说是简单不过的问题。园子里面之前说的那个订餐系统就是一个特例，大概是这样的，某某公司开发了一个员工订餐系统，公司所有员工都可以通过这个系统进行点餐，后面那些外出的员工就说，外面不能访问网络，不可以点餐了，后面老板就说给这个系统增加一个功能，让外面的人也可以订餐，外面可爱的程序员就想到了手机订餐，哈哈，功能很超前啊，手机也可以订餐了，后面花了很大的功夫才吧手机订餐改搞定，真是费尽心思啊，老板后面也发狂了，不就是一个给增加一个功能吗，有那么难吗，你们还搞了那么就，程序员就会回到说，我们把系统移植到手机上，等于是重新做一个系统，所以嘛。。。
我靠，你不会叫外面的同事打电话给前台，叫前台委托订餐啊，一个不知名的同事说道。