遭遇维护（续）

上回发了些牢骚，这次该聊聊正事。从当前的项目流程看来，都少不了需求的环节，而且是发生在项目之初。

本文所谈项目，败点即在需求。一字改锥拧十字螺丝钉勉强凑活，若十字改锥拧一字螺丝钉如何下手。这里不讨论需求总在变化的复杂场面，不过，一个及格的产品至少能符合前半句。

工作流程中一项必需且重要的环节是写通知书，大体流程如下：

从图中可以清楚的看出，首先是一通，接着发中通，最后结案。除了中通之外，每一步只能执行一次。还需要补充的是，各通时间段是互斥的，就是说在某通未回案的时间内，不能发其他。

事实上，设计可以满足这项需求。

可问题来了。设计之初，某（些）人做了一个假设——使用者会按照既定程序（步骤）完成工作——也就是说用系统的人不会犯错。当然，实际情况不说也可想而知。

显然，问题出在上面的假设上。假设忽略了隐式的需求，而且实际上并不算很“隐”，人总是会犯错的，无意的、甚至是故意的。

所以，假设应该是：使用者一定不按既定程序操作。虽然走向另一个极端，但说明要考虑异常情况。不仅在需求中，而且在软件生命期的各个环节。

假设，仅仅是假设，假设当初假设了后者，我就不用每天听“我写了中通，为什么发不出去？”而说“您同时写了一通，删除就可以发中通。”之类的话，世界将多么美好。