軟體需求的概念
（1）寬泛地講，需求來源于使用者的一些"需要"，這些"需要"被分析、确認後形成完整的文檔，該文檔詳細地說明了産品"必須或應當"做什麼。
（2）是使用者對目标軟體系統在功能、行為、性能、設計限制等方面的期望。
（3）期望？！ 一種心理活動、籠統、不細緻、不懂過程
需求的重要性
（1）Frederick Brooks在他1987年經典文章"No Silver Bullet"中闡述了需求的重要性：
開發軟體系統最困難的部分就是準确說明開發什麼。最困難的概念性工作是編寫出詳細的需求，包括所有面向使用者、面向機器和其它軟體系統的接口。此工作一旦做錯，将會給系統帶來極大的損害，并且以後對它修改也極為困難。
（2）需求是産品的根源，需求工作的優劣對産品影響最大。
（3）國内軟體業的痼疾：人們并不清楚究竟該做什麼，但卻一直忙碌不停地開發。
了解客戶、最終使用者、間接使用者的概念
（1）基本概念
"使用者"（user）是一種泛稱，它可細分為"客戶"（customer）、"最終使用者"（the end user）和"間接使用者"（或稱為關系人）。
掏錢買軟體的使用者稱為客戶，而真正操作軟體的使用者叫最終使用者。客戶與最終使用者可能是同一個人也可能不是同一個人。
（2）客戶是掏錢買軟體的人，是以他是"上帝"
（a）某飯店經理在解釋"先有雞還是先有蛋"這個哲學問題時，精辟地闡述了客戶的地位：
如果顧客先點雞，那麼就先有雞；如果顧客先點蛋，那麼就先有蛋。
（b）"現代營銷學之父"菲利普o科特勒所著的《市場營銷導論》是這樣描述客戶的：
客戶永遠是本公司的座上客。客戶并不依賴我們，而我們卻依賴客戶。客戶不是我們工作的障礙，而是我們工作的目标。我們并不因為服務于他而對他有恩，他卻因為給予我們服務于他的機會而有恩于我們。客戶不是我們要與之争辯和鬥智的人。從未有人曾在與客戶的争辯中獲勝。客戶是把他的欲望帶給我們的人，是以我們的工作就是滿足這些欲望，進而使客戶和我們共同獲益。
（c）與客戶打交道的主要目的是：一是擷取需求，二是簽合同。
軟體需求的層次
（1）原始問題描述：對要解決問題的叙述，它是軟體需求的基礎
（2）使用者需求：用自然語言和圖表給出的關于系統需要提供的服務及操作的限制
（3）系統需求：是使用者需求的映射。此時可開發一個簡單原型以便給使用者一個直覺印象。
（4）軟體設計描述：在系統需求的基礎上加入更詳細的内容，它是軟體詳細設計和實作的基礎
需求工程的組成
把所有與需求直接相關的活動通稱為需求工程。
需求工程的一些感悟
（1）不論是合同項目還是自主研發的産品，都必須開展需求開發和需求管理活動。
（2）開發者對待需求工程的态度可分"被動型"、"主動型"和"領先型"三種，隻有後兩種才有可能開發出成功的産品。
"被動型"是指開發者被動地對待需求工程中的各項活動，能少幹則少幹，能偷懶則偷懶。他們認為需求是使用者的事情而不是自己的事情。開發過程中經常發生需求變更，導緻産品迷失方向，不是半途而廢就是陷入半死不活的狀态。
"主動型"是指開發者積極地開展需求工程中的各項活動。他們把擷取準确的需求當作自己的職責，會想盡一切辦法克服需求開發和需求管理過程中的困難，而不是找借口推卸責任。俗話說"良好的開端是成功的一半"，"主動型"需求工程是開發成功産品的必備條件。
"領先型"是需求工程的最高境界。開發者發掘了連使用者自己都沒有意識到的需求，導緻使用者跟着新産品跑而不是新産品圍着使用者轉，這叫引導消費。需求工程做到這個份上，才能使産品立于不敗之地，長盛不衰。
需求開發的主要困難與對策
···知識技能問題
（1）應用域的知識是無邊無際的，任何人都不可能是"萬事通"。
（2）當需求分析員缺乏應用域知識時，他該怎麼辦？
（a）首先他要有勇氣做事，否則連實踐的機會都沒有。
（b）其次他應當趕緊補習應用域知識。
···态度問題
（1）相當多的開發人員習慣于被動地對待需求開發。每當遇到麻煩、挫折時，他們會發牢騷，找出一堆使用者的毛病。很多開發人員錯誤地以為：
需求是使用者的事情，不是我們的事情。我們為使用者開發軟體，難道使用者不該告訴我們應當開發什麼嗎？如果使用者說不清楚需求，或者經常變更需求，這類問題是使用者産生的，應當由他們自己負責。
（2）使用者說不清楚需求或者需求發生變更，這些都是常見的問題，并不是絕症，是人們可以設法解決的。可悲的是開發人員把這些問題當成了借口，不願主動攻克問題，導緻需求問題擴散到整個軟體開發過程，産生太多的後患。
（3）軟體企業的上司應當給具有錯誤觀念的開發人員們洗腦：需求分析員的天職就是在有限的時間内擷取準确而細緻的使用者需求，如果做不到就是失職，不要找借口。
需求擷取
需求擷取時期的主要工作：
（1）歸納和整理使用者提出的各種問題和要求；
（2）弄清使用者企圖通過軟體達到的目的；
（3） 借助各種工具和方法，陳述使用者提出的實際需求，并标定軟體的作用範圍。
最終目的弄明白要"做什麼"。
擷取需求應采用的步驟
（1）确定産品的不同使用者類型
（2）确定使用者需求的來源
（3）挑選出每一類使用者和其他涉衆的代表并與他們一起工作
（4）商定誰是項目需求的決策者
擷取需求的方法
（1）明确最終使用者，與使用者交談，向使用者提問題。向使用者群體發調查問卷。透過客戶所提出的表面需求了解他們的真正需求。
（2）參觀使用者的工作流程，觀察使用者的操作。
（3）與同行、專家交談，聽取他們的意見。
（4）界面原型法，是指開發方根據自己所了解的使用者需求，描畫出應用系統的功能界面後與使用者進行交流和溝通。
（5）可運作的原型系統法
（6）分析已經存在的同類軟體産品，提取需求。
（7）從行業标準、規則中提取需求。
（8）從Internet上搜查相關資料。
切記：
設定使用者代言人
如果個别客戶不能在需求方面達成一緻意見，那麼必須由使用者代言人作出決策。
需求分析
（1）需求分析是指在需求開發過程中，對所擷取的需求資訊進行分析，及時排除錯誤和彌補不足，確定需求文檔正确地反映使用者的真實意圖。
（2）分析方法大體有兩類："問答分析法"和"模組化分析法"。後者技術性比較強，寫出來有學術味，故大多數軟體工程書籍都有論述。前者就是一些常識而已，雖然寫不成文章，但是簡單易用（保你一學就會），很有實用價值。
（3）采用方法：繪制關聯圖、建立使用者接口原型、分析可行性、确定需求優先級、編寫資料字典等。
編寫需求文檔
（1）需求文檔包括使用者需求和詳細的系統需求描述。
（2）要求
正确：正确地反映使用者的真實意圖；
清楚：易讀易懂；
無二義性
一緻
完備：沒有遺漏一些必要的需求；
可實作： "可實作"意味着在技術上是可行的，并且滿足時間、費用、品質等限制；
可驗證
确定優先級：确定高中低三個級别，将風險降到最低。
闡述"做什麼"而不是"怎麼做"
需求驗證
（1）需求驗證是為了確定需求規格說明準确、完整地表達了必要的品質特點。
（2）審查需求文檔、依據需求文檔編寫測試用例、确定産品驗收合格的标準。
（3）驗證内容：有效性、一緻性、完備性、現實性等。
需求管理的重要性
如果對已經建成的大樓不滿意，要求設計師把大樓的結構調整一下，别人一定會認為這很荒唐。但在軟體項目中，這樣的事情很常見。
軟體缺陷，發現和修複的越早則成本越低。不幸的是，需求階段出現的錯誤往往很難發現，是以需求管理也需要講究科學。
原則：需求必須分優先級、必須文檔化、需求一旦變化就必須對需求變更的影響進行評估。
需求變更存在的必然
大師說："沒有不變的需求，世上的軟體都改動過3次以上，唯一一個隻改動過兩次的軟體的擁有者已經死了，死在去修改需求的路上。"
變更管理
進行變更管理，首先要建立變更控制委員會，變更管理過程包括變更描述、變更分析和變更實作三個階段：
變更描述：始于一個被識别的需求問題或一份明确的變更提議
變更分析：評估被提議的變更産生的影響
變更實作：執行變更，需求文檔、系統設計和實作都要修改
變更描述階段，産生需求變更請求表
變更影響分析
需求變更影響分析模闆中包括的内容：
變更請求号
标題
描述
分析者
分析日期
優先級評定
相關代價、收益與風險
預計對進度、成本、品質的影響
被影響的其他需求及任務
要更新的計劃及文檔
變更控制流程
需求狀态
定義：某時間點需求的情況反映。
客戶需求的四種情況：
客戶可以明确且清楚地提出的需求
客戶知道需要做什麼，但卻不能确定的需求
客戶提出需求，但需求的業務不明确
客戶自己也說不清楚的需求
需求狀态：
已建議 已準許 已拒絕
已設計 已實作 已驗證
已傳遞 已删除
需求文檔版本控制
對于開發人員來說，最為沮喪的事情莫過于當軟體功能實作後，卻發現該項功能已被項目經理取消了。原因在于需求文檔版本混亂，開發人員沒有得到最新的軟體需求。
需求跟蹤
目的：建立和維護從使用者需求到測試的一緻性與完整性，確定實作都以客戶需求為基礎，實作的需求覆寫了預期的需求，并確定輸出與使用者需求的符合性。
需求跟蹤的作用
（1）在需求驗證中，便于確定所有需求被應用
（2）有助于變更影響分析
（3）便于需求的維護
（4）便于測試時找出問題所在
（5）便于項目跟蹤和減少項目風險
（6）簡化了系統再設計，易于軟體重用
案例分析：一個項目需求分析和處理的案例
1、 案例背景
當地一家銷售電動工具公司的董事會成員正在舉行二月份的董事會會議，這家公司是一家專門制造和銷售用于木工用的"黑客"牌電動工具的一家小型公司。會議室裡在座的，有董事會主席貝斯·史密斯（Beth Smith）和兩個董事會成員羅斯瑪麗·奧爾森（Rosemary Olsen）和史蒂夫·安德魯（Steve Andrews）。貝斯首先發言："我們今年以來的銷售非常好，打來的訂貨電話，已經要把我們的電話都要打爆了，但是，我們沒有辦法能繼續招募到熟悉我們的電動工具、同時還了解我們銷售過程的小姐。而與我們競争的其他公司，都已經上了自動客戶服務系統（Call Center）。是以，我們也要上這個系統，才能保住我們的市場。"
"我們必須建立一個計算機自動客戶服務系統。"羅斯瑪麗響應道。
史蒂夫建議："難道我們不能把售後服務轉給麥肯羅公司（公司下屬的一家子公司，以服務為主）做嗎？向他們要求一下，看他們是否能把電動工具的服務也接過去？"
"他們也緊張，聽說明年他們甚至可能會削減一些服務項目。"貝斯回答。
"我們需要多少錢才能搞這麼一個系統？"羅斯瑪麗問道。
"大約10萬美元，"貝斯回答，"如果我們不能在兩個月後就開始啟用這個系統，估計我們的定單可能會減少20%。"
"我們除了錢還需要很多東西。我們需要了解是否有更好的方案、開發這個系統需要多少時間，以及，這個系統是不是真的适合我們！"史蒂夫說。
"哦，我想我們完全可以自己來做這個項目，這将是很有趣的！"羅斯瑪麗興奮地說。
"這個項目不是我們的專長，我們不可能及時完成。"貝斯說道。
羅斯瑪麗回答說："我們有幾個技術人員，雖然不夠，但隻要再招聘一二個高手，就可以解決它，并且做好。"
"項目是我們真正需要的嗎？我們上了這個項目以後，公司的銷售任務就能完成了嗎？"史蒂夫問道，"此外，我們正在經曆一個困難時期，我們的資金并不寬餘。或許我們應當考慮一下，我們怎樣能用較少的資金來運作一切。例如，我們用這個系統隻處理定單，而并不包括服務，。這樣系統是不是就會小一點，也省一點、快一點？"
羅斯瑪麗插話說："多妙的主意，我們可以先完成銷售定單的處理，等這部分完成投入使用後，再開發服務部分。公司可以在改進銷售功能的同時，繼續開發服務功能。這樣，我們就可以做得更好。"
"好了，"貝斯說，"這些都是好主意，但是我們隻有有限的資金和技術人員，并且有一個增長的需求。我們現在需要做的是，確定我們在兩個月後不必擔心丢失定單。我想，我們都同意必須采取行動，但是不能确定我們的目标是否一緻。"
2、案例習題
（1） 項目目标是什麼？
（2）已識别的需求是什麼？
（3）如果有的話，準備開發的項目應具備什麼樣的假定條件？
（4）項目牽涉到的風險是什麼？
3、案例分析
根據本案例的背景，我們的分析簡單描述如下。由于本案例比較簡單，而且是自主開發，是以，有些内容可以簡略。至少必須描述的内容，用下劃線表示：
（1）業務需求
1、背景：一家小型的木工電動工具公司，今年以來的銷售形勢很好，接受定單的電話很多，已經忙不過來了。是以，需要開發自動客戶服務系統。
2、項目機遇：通過自動客戶服務系統的開發和投入使用，使公司的銷售獲得增長。
3、項目目标：開發一套為本公司銷售和售後服務使用的計算機自動客戶服務系統（Call Center）。
4、市場需求：
5、客戶價值：滿足公司自身發展的需要。
6、項目風險：項目目标、方案、時間、資金、開發人員等。
（2）方案描述：
1、功能視圖：自動接聽電話，對客戶的定單和售後服務要求做出響應。
2、主要特征：自動處理一些原來由人工完成的工作，有可能增加新的服務功能。
3、假設和依賴：二個月時間内完成，總投資為10萬美元，自主開發，自己使用。
（3）範圍局限
1、首次發行範圍：
2、随後發行範圍：
3、局限和專用性：隻為自己公司使用。
（4）系統環境：
1、使用者概貌：
2、項目優先級：可以先完成定單響應，再完成售後服務功能。
（5）成功因素：
我們現在完成的，實在需求擷取階段中介紹的"項目視圖"中的内容。在項目視圖中，我們對項目做了初步的描述。在背景和目标分析階段，我們回答本案例問題的答案是：
1、項目目标是什麼？
答：開發一套為本公司銷售和售後服務使用的計算機自動客戶服務系統（Call Center）。
2、已識别的需求是什麼？
答：自動接聽電話，對客戶的定單和售後服務要求做出響應。
3、如果有的話，準備開發的項目應具備什麼樣的假定條件？
答：二個月時間内完成，總投資為10萬美元，自主開發，自己使用。
4、項目牽涉到的風險是什麼？
答：項目目标、方案、時間、資金、開發人員等。
系統的功能包括：
1、從公司的客戶方面看，新系統可以自動支援電話、FAX，E_mail、Web等多重通信方式所提供的服務，最大限度的滿足客戶的需要，最有效地為客戶提供快捷友善的服務。
2、從公司方面看，新系統要可以支援接入公司的交換機中繼線路（24條中繼），自動或智能話務配置設定、坐席畫面與電話同步、自動錄音等功能。
3、從提供服務的内容看，可以有：公司産品查詢、合同和定單查詢、自動處理定單、産品售後服務資訊查詢、供貨資訊查詢、方案介紹、産品推介、産品報修、故障咨詢、投訴等。進一步的購買洽談，可以轉人工處理。
4、整個系統可以與目前公司已經有的客戶資訊系統、産品資訊系統等建立聯系，形成綜合的服務系統。