去年在公司開發乙個專案時，根據剛開始我們了解的客戶的需求，我們在開發過程中發現如果按照剛開始的設計來實現客戶所需的功能的話，可能技術上會比較困難，而且效果也不會很好。具體要求是對工廠生產線上需要送檢的零部件進行編輯，分配到具體的工位上，然後儲存設定，剛開始我們採用選擇零部件後，在後面的工位項中給它提供乙個預設選擇項(客戶要求的)，後來我們按照這個完成後，客戶在使用的過程中，提出使用選擇專案比較麻煩，因為根據不同批次的產品，設定的預設值可能不一樣，需要能夠自動調配，減少手動操作的次數，於是我到工廠進行了進一步的調查，發現將需要中客戶使用的下拉框改為textbox更方便，而且在設定預設值上也方便實現，系統的效率和反應速度和使用者體驗上都會有很大提公升。所以我就同客戶方面進行了進一步的溝通，最終他們認可了我建議的方案，並讓我做出乙個demo供他們測試和了解。在隨後的2天，我做出了乙個測試版本供他們進行測試，結果客戶實際操作和使用後，對此方案非常的認同。系統實施後，客戶的評價也非常高。不僅提高了工作效率，而且操作也很方便。
通過這次專案的開發讓我認識到，了解客戶真正的需求，並將客戶的需求用最小的代價實現，並且能給客戶的良好的體驗是最為重要的。如果我當初在遇到客戶說要我將工位的選擇的操作次數減少。因為下拉框中下拉，選擇，切換這3步不可能減少。但是如果改用textbox後就可以直接修改為數字1，2，3，然後tab鍵切換，而且我們在當時的調查中了解到，產品全部的零部件有30多個，其中有絕大多數是設定在第2工位進行掃瞄的，1工位和3工位則很少會有零部件要掃瞄。因此我又給textbox設定了預設值2，表示預設分配在了第2工位，這樣乙個機型實際上要使用者手動去設定的工位的只有3個左右，相較以前需要設定30多個而且步驟會煩很多，效率當然高多了。
通過這次專案的開發，也讓我明白，雖然我們是程式設計師，但是我們的眼光不能只停留在技術層面，因為做軟體最終目的是滿足客戶的需求，提高客戶的工作效率，所以我們要學會發掘客戶的需求，並用最簡單的方式來實現它。
軟體專案的需求分析
需求分析 在具體的研究需求分析之前，我們先了解一下軟體工程這個概念。軟體工程分為三個層次，過程層 方法層 工具層。在最基礎的過程層，最重要的就是一組被稱為關鍵過程區域 kpas 的框架 kpa的概念在討論cmm的書中有詳細的概念說明 關鍵過程區域構成了軟體專案的管理控制的基礎，並且確立了上下文各區域...
專案的需求調查問卷
看了 系統分析與設計 機械工業出版社 之後，給了我很多啟發，它介紹了乙個軟體專案如何從無到有，並讓使用者使用方便的全過程。對於如何使我們的專案開發的軟體更貼近使用者，一直讓我十分頭痛，畢竟我們只是在校學生來做專案，資源較少。看了這本書，我想到用書上的乙個辦法 調查問卷。歷經三次改動，v1.3版的問卷...
從需求到專案的成功
我最近遇到乙個專案，在該專案中，乙個新的開發小組將針對早先的開發小組所開發的 求實現乙個應用程式。這個新的開發小組一看到由3英吋活頁紙訂成的軟體需求規格說明就 到十分恐懼，於是立刻編寫 在構造軟體的過程中，他們沒有參考軟體需求規格說明，而是根據他們對預期系統的不完整且不正確的理解，按他們自己的想像進...