軟件需求的概念
（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、整個系統可以與目前公司已經有的客戶信息系統、產品信息系統等建立聯系，形成綜合的服務系統。
