人們常問：“需求、設計、編程、測試四者究竟哪個重要？” 這個問題不好回答。四者都是軟件開發過程中必不可少的環節，光做好其中一個環節并不能產生好的系統，但是做壞了其中任何一個環節，必定對系統產生壞的影響。若站在風險管理的角度講，也許需求開發與管理是最重要的環節。因為需求是產品的根源，對產品需求的認識是否徹底對產品的影響最大。就像一條河流，如果源頭被污染了，那么整條河流也就被污染了。慶幸的是我本人既是軟件的開發者又是這套系統的最終用戶，個人親身在造價管理部門、投標部門、項目法人結算部門工作過，對系統的大部分需求比較了解，這也給需求分析工作減輕了負擔。

    也許是對需求的理解過于自負，因此對水利設計單位的需求調查深度不夠，導致了目前系統針對設計單位用戶功能的提供存在一個缺陷，而且是不容易彌補的，這一點的需求與許多模塊相關聯，牽一發而動全軍。正如Frederick Brooks在他1987年的經典文章“No Silver Bullet”中闡述需求的重要性：“開發軟件系統最困難的部分就是準確說明開發什么。最困難的概念性工作是編寫出詳細的需求，包括所有面向用戶、面向機器和其他軟件系統的接口。此工作一旦有失誤，將會給系統帶來極大的損害，并且以后對他修改也極為困難。” 軟件需求是系統設計之源，詳細的需求分析完成后接下來的工作便要進入系統的設計階段。軟件系統設計核心內容包括：體系結構設計、用戶界面設計、數據庫設計、模塊設計、數據結構與算法設計等幾方面。根據這套軟件的具體開發情況，系統設計準備了兩套方案：一個是繼承市場上現有水利造價軟件的主流設計思路，對其不完善的部分改進并加入一些先進的設計思想。另一種方案是拋棄主流設計思路，另辟新徑開發一個面目一新的產品。

    我對兩種方案的優缺點進行了對比：第一種方案的優點： 1、 主流水利造價系統結構設計的可實現性具有先例，開發風險系數低。 2、 有大量的老用戶習慣了以前的軟件操作模式，主流的用戶界面和模塊畫分會給老用戶以熟悉感，用戶不用重新學習軟件的使用方法。 3、 可以吸收市場上較成熟的同類軟件的數據庫設計思想，縮短了開發時間。第二種方案的優點： 1、 全新模式設計，可以徹底拋棄現有同類軟件在需求、設計方面的不足。 2、 給用戶以全新的感覺，避免用戶產生新軟件是某一款老軟件升級版的錯覺。 3、 避免了因與某一同類軟件的部分結構相似而產生的版權糾紛問題。我對兩套方案進行了詳細分析對比，權衡利弊決定采用第一個方案。并運用以下方式對第一套設計方案中的不足進行彌補： 1、 徹底分析市場現有同類軟件的不足，從需求、設計方面入手，增強系統的功能與操作的人性化，讓軟件更體貼用戶需要。改進計算與導出模塊的數據結構算法，提高系統的整體性能。因水利造價管理的需求是隨時代發展而變化的，預留軟件接口，提高可擴展性。對部分模塊全新設計，提高系統的兼容性。 2、 只吸收設計思想，不抄襲整個軟件，盡量避免版權爭議。 3、 本人在天津水利造價管理領域有一些人脈，因此軟件設計主要吸收天津某單位開發的一套系統的優秀思想。即使將來產生版權爭議也容易擺平，再不行還可以合作嗎。根據《計算機軟件保護條例》第六條的規定，除計算機的程序和文檔外，著作權法不保護計算機軟件開發所用的思想、概念、發現、原理、算法、處理過程和運算方法。也就時說，利用以有的上述內容開發軟件，并不構成侵權。因為開發軟件時所采用的思想、概念等均屬計算機軟件基本理論的范圍，是設計開發軟件不克缺少的理論依據，屬于社會公有領域，不能為個人專有。所以市面上的同類型的軟件結構布局、使用方法都有幾分相似，這給用戶的使用也提供了很大的方便。但他們之間肯定是有差異的，各有長短，一些后者吸收前人的思想并發展繼承后異軍突起了。因為已經完成了系統需求詳細分析，對業務流程十分熟悉，而這種數據處理系統的技術含量不很高，所以對市場現有水利造價軟件的體系結構、用戶界面、模塊劃分的分析相對容易一些。軟件所依賴的數據結構與算法可結合程序實現時一同考慮。在對現有軟件的剖析過程中最讓人頭痛的是數據庫結構的分析過程。需要搞清每個庫的作用，每個庫之間的聯系；庫中每個表的作用，他們之間的聯系；表中的每個字段的作用，他們之間的聯系；之后他們所有互相之間的聯系。我耗時一個月對軟件的6個庫、120張表、3000多個字段進行了詳細的功能及關系描述，描述文檔約有10萬字。算起來比全新設計庫結構所要耗費的精力一點不少，這樣做只是為了增加軟件的成功系數。至此軟件的分析工作全部完成，接下來的工作就是要真刀真槍的編碼了。