發布於:軟體開發網
1/8/2010 10:35:37 pm
專案需求分析，看了聽棠的「客戶需求何時休」，深有感觸，何曾自己不是被這個問題整天困擾：客戶需求，為什麼總在變阿？做專案真辛苦阿！這樣的感嘆整天都掛在口上。客戶需求變動確實是乙個軟體開發永遠不變的話題。為什麼小的軟體企業面對經常變動的需求是如此的狼狽？到底要怎麼做才能滿足客戶的需求？
聽棠的「客戶需求何時休」深刻的披露了這個問題存在的根源。
需求分析，不僅僅是拿到客戶的需求，更重要的是還需進行分析，了解細節，並就細節跟客戶諮詢，獲取最詳細的資料。客戶所能提供給你的只是他們想到的功能需求，很多問題並不在他們考慮的範圍之內，如果作為專案承擔方沒有去做分析，簡單的按照功能要求去設計、規劃，最終出來的系統是很難完全符合客戶的業務流程的，這時，自然需要更改，被看成了需求的更改。其實，都是缺乏分析所一手造成的。問題等到系統出來了才被發現，這樣的系統本身就是先天不足的了。
聽棠所說到的幾點，感受特別深：
「其實問題出在開頭，客戶需求只是軟體需求分析的一部分，雖然是比較重要的一部分，但也不要只是去記客戶的需求，而是要把客戶的需求進行分析」
「客戶本身是不怎麼懂技術的，客戶只知道自己的業務需求，而在軟體設計時，是在把業務需求抽象到系統中實現的，把業務轉變為邏輯時，一切都應該符合邏輯的，但客戶的業務思想有時候在軟體系統實現時會有問題的，這就需要分析時分析出來的。少了分析，問題也會在後面的開發中暴露出來，到時可就更麻煩了。」
還有客戶的需求本身會有矛盾（這矛盾是指在邏輯角度來講），客戶本身是意識不到的，只有在分析設計時，才會分析出這裡的矛盾，而這些問題，如果在期初時，軟體負責人不分析，而是純粹的「聽從」客戶要求去做，當暴露這些問題時，你怪客戶也沒用啊。
專案需求分析報告。在了解客戶需求時，不要不動腦子，不要一味的點頭說「i c」，其實在表面的業務裡面可能包含著n多的細節，這些細節是需要你反問客戶的，只有當你提的問題越多，最終獲取的需求最具體，才能讓專案越順利。而且有很多問題，都是在你的反問中，客戶也才開始思考本來沒思考過的問題，客戶也會找到一種合理的需求給你，有人會覺得這樣了解客戶需求未免太麻煩了。至於一些在技術上會遇到問題的地方，也要告訴客戶，別以為到時候再說，客戶是不關心你的技術細節的，但你如果給他解釋的話，他也會試著理解的。
客戶的需求本身是無休止，因為他們本身也在變，但當你期初的分析合理，後面的變動也將在邏輯上變動，相信代價已經不會那麼大了。這其實也體現了系統的擴充套件性。
需求分析，是乙個專案提出方和承擔方相互溝通的過程，一方是系統的使用者，一方是系統的製造者，在系統製造過程中，只有雙方相互配合，共同對系統進行設計才能最後達到使用的要求。客戶是業務上的熟悉者，對業務流程有非常清晰的了解，但是，對於軟體需求方面的描述是不了解的，他們所能提供的只是他們最終要達到的功能，但是，這其中包含的業務流程是非常複雜的。我們拿到客戶需求後，應該根據功能、流程進行初步的設計，構造出業務流程圖，再讓客戶進行評審，提出業務流程上不對的地方進行修改。這樣來回的交流，最終才能取得較全面的需求，並減少後期的修改。
謹記一點，需求是經常變動的，只有先做好需求的分析，了解業務以後的發展趨勢，做好具有拓展性的系統設計，才會給系統更大的擴充套件空間，從而在需求發生變化的時候可以更從容的修改。
怎麼做專案需求分析報告
專案需求分析，看了聽棠的 客戶需求何時休 深有感觸，何曾自己不是被這個問題整天困擾 客戶需求，為什麼總在變阿？做專案真辛苦阿！這樣的感嘆整天都掛在口上。客戶需求變動確實是乙個軟體開發永遠不變的話題。為什麼小的軟體企業面對經常變動的需求是如此的狼狽？到底要怎麼做才能滿足客戶的需求？聽棠的 客戶需求何時...
怎麼做需求分析
如果將需求分析階段的工作歸結為編寫需求規格說明書，這種簡化的做法往往是導致專案後期層出不窮問題的罪魁禍首。建議採用以下步驟形成軟體需求 獲取使用者需求 分析使用者需求 編寫需求文件 評審需求文件 管理需求。下面我們先來討論前兩個步驟 獲取使用者需求 分析使用者需求 的做法。獲取使用者需求 這是該階段...
怎麼做需求分析
乙個成功專案的關鍵在於需求做的怎麼樣！做專案需求可以是對涉及的各個部門人員分別做調查，相對來講，這樣做的需求分析，才更能體現實際，切實了解到客戶基層遇到哪些困難 需要解決哪些問題 以及操作的整個流程，但，並不是每個部門的每個人員都願意配合工作 專案成功可能會導致某些人丟職位 也可以是只對相關領導和關...