當時仍是「底標議價制」，「清官」堅持按照政府規定，只給 15% 利潤，根本活不下去。有先進告訴我，因應辦法很多，包括：估價單大灌水，或先拿到單、日後再找理由強迫追加預算，或「放長線釣大魚」，這一單認賠，但在過程中把這家納入為囊中之物。
前2項與我個性不符，做不來。「放長線」我要和董事長談，董事長說各事業全部「利潤中心化」，不會貼補，如果虧就收掉。當時資訊系統前景未明，各軟體公司都不大，我們也不過30來人，所以董事長不是絕情，而是企業成功者的霸氣。
我棄標後，該部部長與我原來並不認識，投標過程中他也沒出現，卻特地請我去一談，願意延期開標，期望我再回去按底價接標，我只能感謝與婉拒。
後來我只好經過「手套」去建立關係，董事長警告過我，這樣並不適當，必須自己去經營應酬。
1992年我一位老師由美國哥倫比亞大學回到臺大創辦研究所，師資開2個條件：第一、電腦輔助教學；第二、英語授課。現在感覺很平凡，當時卻找不到人，所以執意邀請我返校教書。雖然待遇有天壤差距，但工作的興趣與快樂感更重要，我也由資訊系統的承攬者，轉變為指導者、評審者了。
UML●解決需求規格的抽象預期
2003年「政府電子採購網」上線後，招標程序標準化，效率增加，流程簡化，更重要的是有了透明化的基礎，資訊系統招標累積20年經驗，也更合理化了。
當前資訊標案所見到的全是「有利標」，不致發生因能力強，反而必須棄標的情形。得標廠商、評審名單也都可以公開。
那北分署的吳員為何還被屢屢退件呢？因為我觀察到2類主管仍然以不同方式存在。一類只要把預算用出去就好，自己不管，其實也已發生另類缺失。第二類則是有獨特的想像，更糟的是有圖利的行為。
先不談主管的情緒管理部分，在資訊系統標案中最重要的是「需求規格書」，國內幾乎全部都是以文字表現。唯許多主管腦中想的，無法以文字精確說出，而部屬為主管聽寫的文字，又未能符合主管的想像。
這個問題在國際上早已發生，而以「圖形式需求規格書」來解決。當前最普遍的就是統一塑模語言（UML, Unified Modeling Language），為16個系統開發圖。對系統的預期，以圖形表現比以文字表達精確也簡明得多。
其中第一個「使用個案圖 Use Case Diagram」適合由招標者提出，定義需求，而其他由得標者製作，完成預期。
「使用個案圖」是英文的直譯，意譯就是「誰？做什麽」的需求圖。又分為2套，第一套是對常見需求的「系統使用個案圖設計」，第二套是對新創事業系統的「商業模式使用個案圖設計」。
