無論是軟體公司興高采烈地拿到了專案，還是企事業內部電腦部（科技部）無奈地接收到了專案開發任務，兩者都會面臨「需求」問題。需求是定製軟體的起點，也是定製軟體的終點。在中國沒有需求就沒有軟體，沒有軟體也就沒有軟體設計師，沒有程式設計師了。但是，需求並不是乙個天上的餡餅，現實中誰吃誰倒霉，誰就被其折磨至瘋至死。越是大專案，需求就越多越複雜，越是大專案，需求就越會變化，這種對需求的掌控，對需求變化的應對就成了軟體設計師把握專案最重要的基礎。
作為軟體設計師，他首先要面對需求，只有在對需求了解和懂得的基礎上，才能對需求進行各種分析，分析透徹後，才能進行專案的總體設計；總體設計完成後，才能進入功能設計；功能設計後，才能進行功能的流程設計；流程設計後、才能對具體的功能實現技術演算法進行設計；等等。因此，需求是設計各個環節之首，需求做不好，其他全亂了。
在現實工作中，軟體設計師在需求方面往往會碰到以下問題：
1、入門艱難
入門艱難是軟體設計師，常遇到的問題，由於很多軟體設計師只關心程式設計、只關心技術。對使用者的業務基本上是不懂的，除非有專案了，他才會被迫地去學習需求中的相關業務。這種對業務先天的拒絕，說明軟體設計師還沒有進行很好的角色轉變，忘記了其了解使用者需求，進行需求分析是其首要的職能。究其個中原因是軟體設計師對使用者的業務和需求的恐懼，很多人對自己不懂的東西，往往抱有拒絕的態度，因為，自己怕不懂會給別人造成無能的形象。乾脆就離自己不懂的東西遠遠的。軟體設計師要想遠離需求是在內心深處的，但是，現實中他必須要接受需求，否則，專案無法進行。所以，很多軟體設計師在拿到使用者的需求的時候，尤其是初次進入這個行業的時候，進入乙個自己從未聽說過的業務的時候，自信心幾乎為
0，十分擔心專案最終能否進行下去。這種恐懼的折磨是非常明顯的。當然隨著對專案需求的逐步了解，這種恐懼心態才會逐步地平息下來。
我的建議是，軟體設計師平時就要養成重點放在需求上的習慣，根據公司和單位未來可能開發的軟體和方向，主動地去學習各種使用者的業務知識，作為今後專案設計的積累。例如，今後可能進行銀行業應用系統的開發，那就要早早學習各種銀行業務知識。有了這些知識積累後，軟體設計師的自信就不會為0了。
我特別反對現學現賣的工作作風。有的人等到專案落實了，一點準備都沒有，就來聽使用者的需求講解了。明明聽不懂還乙個勁地點頭，留了一大堆自己不明白也搞不明白的東西，浪費時間、浪費效率。對專案開發的時間影響很大。常言道「機會是留給有準備的人的」。這種人可恨有可憐。
2、溝通吃力
要了解和理解需求，就必須要和使用者進行溝通，要溝通就要有共同語言。現實中軟體設計師和使用者溝通並不融洽。主要的原因在於：
1） 使用者講述的需求的時侯，往往感覺需求非常簡單，所以講起來行雲流水，簡單中包含了無數的業務名詞和業務做法。而且內容大都是發散的，不經過嚴密推敲的。而軟體設計師往往準備不足，聽不懂，但是又不會中途打斷使用者的講話，即使是進行需求討論的時候，由於問題太多，而提不出問題來。
2） 有的軟體設計師更喜歡看需求書，喜歡通過自己精通的看書的方式了解需求，以避免和人打交道的尷尬。但是，很少需求書能把需求說清楚的，大多數需求書，往往比較簡單、漏洞百出。軟體設計師看這樣的需求書能懂得需求那才怪呢。另外，使用者需求書，往往需求更多的業務知識的支援，而這些業務知識一般是很難附在需求中的。從某種意義上來說，和人溝通是正道，和書溝通只能是乙個補充。
3） 在很多應用專案中，使用者的要開發的系統並不是自己企業自身的要求，而是外部監管的要求。例如，銀監會要求各商業銀行在規定時間內報送某種報表。銀行在開發這個報表的時候，對這個報表本身就不很理解，往往會把銀監會下發的檔案作為需求提供給開發者，自己卻說不出所以然來。
對於一些跨部門跨業務的應用系統開發來說，有的使用者只對自己熟悉的部門和業務比較懂，但是對其他的部門和業務並不太懂，這個時候軟體設計師就很難從他的口中得到自己想要的東西了。軟體設計師千萬不要認為使用者是什麼都懂的。有的使用者甚至說的都可能是錯的。
4） 在後期的交流之中，軟體設計師往往不自覺地會用計算機語言和使用者進行交流和解釋，這個時候，就輪到了使用者聽不懂了。例如：使用者發現查詢乙個交易，需求等待十分鐘，就問軟體設計師為啥這樣慢。軟體設計師經過檢查後，告訴使用者是因為資料庫中表索引忘記加了，所以慢了，現在已經改好。使用者根本聽不懂資料庫和索引這些詞義。但是只能認為軟體設計師講的都是高科技的。
3、交流不便
無論在需求階段還是在設計階段，還是在編碼階段、測試階段、投產階段、軟體設計師都要和使用者進行交流和溝通。只有交流軟體設計師才能知道專案要做什麼，只有交流才能知道專案做的對不對。在現實中，往往很難找到乙個完全脫產的使用者跟著軟體設計師跑完全程的，乙個設計師往往要和許多使用者打交道進行溝通。因此，軟體設計師往往會遇到找不到使用者的情況，或者使用者對他說工作太忙沒有時間和他交流的情況。「你急他不急。」到「你不急他急」各種情況都有。由於使用者是上帝，軟體設計師是上帝的臣民，所以只能再急也只能等了。
我要建議的時候，當要和使用者進行交流的時候：
1） 盡量在交流前，把所有的問題及在本子上，千萬不要遇到乙個問題，就去問乙個問題，這樣會大大增加交流次數，影響使用者的自身工作。
2） 要學會預約使用者，當使用者經常說沒有時間的時候，要先期進行交流確定交流時間。不要自己想要去問問題就去問。這樣被拒絕的概率會小一些。
3） 對待需要不同崗位進行交流的使用者，建議由其部門領導牽頭開乙個聯席會議，在會上進行集中交流。
4、變化頻繁
軟體設計師好不容易才把需求搞懂，進入了開發階段，常常會遇到需求需要變更的情況，有些變更比較小，比較早，影響不大，軟體設計師往往只好忍了。但有些情況，例如需求分析並不充分，到了開發階段，甚至到測試階段發現了功能重要遺漏、重要功能變更，發現資料庫設計要大的變化這些需求的變更，往往讓程式設計師想死的心都有了。更崩潰的是，這種情況決不是出現一次。當使用者信誓旦旦決不再變的時候，使用者還會找出各種理由進行第二次、第三次變更。當然最終的勝利是屬於甲方的（使用者的）。更更崩潰的是需求改動後，程式編好了，需求又改回來了。開發人員做了一會無用功呀。
面對不斷變化的需求，我們很難通過合同形式強制需求不變。因為變是硬道理。我建議：
1）在討論需求的時候，多向使用者提出可能變化的功能、流程、資訊、報表的可能在**。把可能的變化範圍控制在自己的手中。千萬不要要求使用者這個不能變那個不能變。恰恰相反，你要不停地問，那個要變，那個為啥不變。把「變」從暗處拉到明處。
2）需求變化的主要原因乙個是業務本身不成熟，所以會產生變化；另乙個原因是使用者本身的業務知識掌握程度有差異，產生了需求變化。所以，要多找幾個使用者交流，採眾家之言，不要認乙個使用者說話。這樣需求變化的可能性就會大大減少。要特別找那些業務知識強、表達能力強、邏輯性強的使用者作為需求提出的主要人員。多聽聽他們的意見和建議。就能減少需求的變化。
3）要從技術層面解決需求變化問題，例如，將整個專案的構架變成乙個可擴充套件性的構架，對資訊設計也採用擴充套件的設計，最大限度採用引數化，採用接**術。
我深知做專案的不易和艱難，我深知需求是軟體設計師永遠的痛。乙個軟體設計師只有在這個行業，這個型別系統不停地設計開發，才能積累這個行業的業務知識，積累這類系統的開發經驗，才能將這種痛逐步地減輕。當我們有一天比使用者更懂業務的時候，我們這種痛才會消失，我們才會把原來的痛轉化成享受。
軟體行業出現「需求驅動」開發模式，必然會造成軟體設計師的永遠的痛，無論怎麼醫治這種痛始終存在，無法只是大痛和小痛之分吧了。只有跳出現有思維的圈子，對這種開發模式的徹底反思，我們才能找到**這種疼痛的良方。
軟體設計師教程目錄
第1章 計算機系統知識 1.1計算機系統基礎知識1 1.2計算機體系結構1 1.3安全性 可靠性與系統效能評測基礎知識34 第2章 程式語言基礎知識51 2.1程式語言概述5 1 2.2語言處理程式基礎6l 第3章 作業系統知識94 3.1作業系統基礎知識94 3.2處理機管理98 3.3儲存管理 ...
軟體設計師複習（一）
1 常用的虛擬儲存器由 主存 輔存 兩級儲存器組成。2 中斷向量可提供 中斷服務程式的入口位址 3 為了便於實現多級中斷巢狀，使用 堆疊 來保護斷點和現場最有效。4 dma工作方式下，在 主存與外設 之間建立了直接的資料通路。5 利用報文摘要演算法生成報文主要的目的是 防止傳送的報文被篡改 6 防火...
軟體設計師考試總結
我們剛開始為了這次考試，自發結成乙個小組。自己卻因為時間安排上的問題與自己的組員嚴重脫節。經過一段時間的自己看書學習，覺得效果很差，就去找師哥師姐幫忙了。慶幸的是在師哥師姐的帶領下自己也算是跟上了隊伍的節奏！個人覺得在其中需要注意的幾點 備考階段 小組學習 在這個階段一定要跟小組一起學習討論，有疑問...