需求分析的方法用戶用例

1. 需求分析怎麼做

10月22日 10:37 盡量把客戶所持的假設解釋清楚，特別是那些發生沖突的部分。從字里行間去理解以明確客戶沒有表達清楚但又想加入的特性或特徵。Gause 和Weinberg（1989）提出使用「上下文無關問題」—這是一個高層次的問題，它可以獲取業務問題和可能的解決方案的全部信息。客戶對這些問題的回答諸如「產品要求怎樣的精確度」或「你能幫我解釋一下你為什麼不同意某人的回答嗎？」這些回答可以更直接地認識問題，而這是封閉（close-end）問題所不能做到的。

需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟體解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間採用了更多的交流方式（Kiel and Carmel 1995）。與單個客戶或潛在的用戶組一起座談，對於業務軟體包或信息管理系統（MIS）的應用來說是一種傳統的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入（buy-in）的一種方式。

盡量理解用戶用於表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，並提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。

在需求獲取的過程中，你可能會發現對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業務和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那麼客戶將會提出很重要的但又在當前產品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的范圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。

正如經常所說的，需求主要是關於系統做什麼，而解決方案如何實現是屬於設計的范圍。這樣說雖然很簡潔，但似乎過於簡單化。需求的獲取應該把重點放在「做什麼」上，但在分析和設計之間還是存在一定的距離。你可以使用假設「怎麼做」來分類並改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然後提供一個尋找錯誤和遺漏的辦法。把你在需求開發階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。

需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。相反地，從極少的代表那裡收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最好的權衡在於選擇一些授權為他們的用戶類發言的產品代表者，他們也被同組用戶類的其它代表所支持。

沒有一個簡單、清楚的信號暗示你什麼時候已完成需求獲取。當客戶和開發者與他們的同事聊天、閱讀工業和商業上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。

1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。

2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。

3. 如果用戶開始重復原先討論過的問題，此時，也許你就完成了收集需求的工作。

4. 如果所提出的新需求比你已確定的需求的優先順序都低時，也許你就完成了收集需求的工作。

5. 如果用戶提出對將來產品的要求，而不是現在我們討論的特定產品，也許你就完成了收集需求的工作。

以上知識大致上討論需求分析應該如何做，實際上對於需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的應用主要還是要靠個人。所以，大家在實際應用的時候，不妨結合自己的實際，有選擇性的採用一些方法，那你就是成功的。
用例在需求分析中的使用

多年來，分析者總是利用情節或經歷來描述用戶和軟體系統的交互方式，從而獲取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源於面向對象的開發環境，但是它也能應用在具有許多開發方法的項目中，因為用戶並不關心你是怎樣開發你的軟體。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什麼遠遠強於詢問用戶希望系統為他們做什麼這一傳統方法。

用例的重要功能是用畫用例圖的功能來鑒別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬體或者甚至是其它軟體系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分並接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應採取的補救措施。

這樣說可能會非常復雜，其實一個用例描述了系統和一個角色（actor）的交互順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:

· 用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。

· 用例由角色激活，並提供確切的值給角色。

· 用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。在UML中，用例表示為一個橢圓。

角色是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例（例如有很多個銷售員），但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，一個高級營銷人員既可以是貿易經理，也可以是普通的營銷人員；一個營銷人員也可以是售貨員。在處理角色時，應考慮其作用，而不是人或工作名稱，這一點是很重要的。

我們使用不帶箭頭的線段將角色與用例連接到一起，表示兩者之間交換信息，稱之為通信聯系。角色觸發用例，並與用例進行信息交換。單個角色可與多個用例聯系；反過來，一個用例可與多個角色聯系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡管執行的，但角色未必是人。例如，角色也可以是一個外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進行交互。

一個用例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個用例是相關的用法說明的集合，並且一個說明（scenario）是用例的實例。這種關系就像是類和對象的關系。在用例中，一個說明被視為事件的普通過程(normal course)，也叫作主過程，基本過程，普通流，或「滿意之路」 (happy path)。在描述普通過程時列出執行者和系統之間相互交互或對話的順序。當這種交互結束時，執行者也達到了預期的目的。

在用例中的其它說明可以描述為可選過程(alternative coruse)。可選過程也可促進成功地完成任務，但它們代表了任務的細節或用於完成任務的途徑的變化部分。在交互序列中，普通過程可以在一些決策點上分解成可選過程，然後再重新匯成一個普通過程。

角色類和角色實例

軟體產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟體目標組織中所處的地位不同，地理位置不同，業務熟練程度不同。

不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率。考慮到用戶的差異性，將用戶分類並研究用戶類的行為特徵是非常有必要的。所以在做具體的需求之前，先將用戶分局行為和特點進行分類，對於研究、收集用戶的需求是非常有幫助的。

可以利用一個簡單的表格列出一些原始的分類，然後不斷的完善這個表格。確認你的分類之間沒有交集。並充分描述用戶分類的行為，目的，要求等。在企業分析中，比較常見的分類可能包括，供應商，客戶，部門等。

就像C++中的類和對象一樣，我們把分析出的用戶分類稱為「角色類」，把實際的用戶稱為「角色實例」。在得到用戶分類之後，最重要的就是要選出用戶代表，用戶代表不僅僅是在需求階段中參與項目，還必須對項目的全過程負責。用戶代表能夠代表用戶分類的需求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規模的調查的，只是要把重點放在用戶代表上。

確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向後傳，到最後，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。

對於和用戶直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟體，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：

做大規模的市場調查，針對你的目標市場做市場調查，並根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些游戲公司會發布一些Demo版的游戲。可是對於一般的企業來說，這項工作費時費力，高昂的成本往往使大家知難而退。我的意見是，方法是非常好的，但是可以採用折衷的辦法，例如選取有代表性的企業，為特定企業製作一個較小的版本並收集反饋意見等。這涉及到很多市場營銷的內容，並不是我的專業所長，這里就不多弄斧了。
聘請行業專家，一個行業專家往往可以在項目需求方面發揮極為重要的作用。一個行業專家往往都有大量的行業經驗和行業的人際關系網路。在產品的設計方面，這個行業專家提供很多寶貴的意見。在目前很多的軟體的開發過程中都採用了這種方式。行業專家有兩種：一種是在這個行業中有很深的資歷，但是對軟體技術並不熟悉；第二種是開發過同類軟體的軟體專家，這種人在開發同類軟體過程中已經積累了大量的項目經驗，並且具有軟體開發的知識。這種方式是獲取需求的最好的方式。 分析對比同類軟體，微軟在開發Office、Visual Studio的時候，也是參照了Lotus和Borland的成熟產品。這種方式的特點在於成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。

需求的沖突

有的時候，雖然已經將用戶分類並選出了用戶代表。但是需求的來源眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來後，人們難以解決沖突，澄清模糊之處以及協調不一致之處。某些人還要對不可避免要發生的范圍問題單獨作出決定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權並且有責任來作出決策，或者授權的個人不願意或不能作出決策，那麼決策者的角色將自然而然地落在開發者身上。這是一個非常糟糕的選擇，因為開發者通常沒有足夠多的信息和觀點來作出業務上的決策。

在軟體項目中，誰將對需求作出決策的問題並沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處於公司底層的人作出決策，因為他們與問題密切相關，並能得到關於這些問題的廣泛信息。

如果不同的用戶類有不一致的需求，那麼必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助於你決定哪一個用戶類所佔份額最大。

當開發者想像中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到「客戶總是對的」的陷阱中去，對他們百依百順。現實中，客戶並不總是對的。客戶總是持有自己的觀點，開發者必須理解並尊重這一觀點。

用例

在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由於用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。

為什麼要採用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上採集信息，然後由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。

用例圖適於表達交互，之所以上面使用了電信系統，是因為用例最早來自於Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，並於1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的用於對功能進行描述。每個用例代表了系統與外部ACTOR的交互。可以採取順序圖來表達用例的具體操作程序。ACTOR用於確定系統的邊界。

ACTOR、用例可以從不同的層次來描述信息。採用該原則的原因有：

1. 需求並不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。

2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。採用不同的層次來描述，適於認知的過程。

使用用例開發系統的一般過程

在開發過程的初始階段，可以根據具體的項目特點，制訂開發各個視圖之間的關聯原則，指導規范。在開發的過程中，視圖的組織原則應不斷進行維護、更新。

識別ACTOR來識別系統與外界交互的實體。ACTOR具有特定領域的特徵，例如：交換機（採集系統）、97信息系統等。在系統層次的ACTOR確定了系統的邊界。

識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。註：系統開發需要一定的規則來確定，如何來分解用例；可能基於原有系統的經驗，或是參考現有資料。

當用例細化到可以被理解的層次。需要基於用例進行下一步的開發。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節。交互的實體採用類圖來描述；而交互的細節，採用順序圖來描述。

當系統復雜到一定層次時，類圖和順序圖可能不能足以描述其復雜程度。在該情況下，需要使用狀態圖來輔助闡述。狀態圖和順序圖之間使用事件聯結在一起。它們之間的一致性問題，目前UML和ROSE沒有提供解決方案。相對折衷的方法是使用事件的命名規范強制一致性。

可以說，之前說的所有的東西都是為了能夠導出用例在需求中的作用。用例是從用戶的角度看待系統，而不是基於程序員的角度。這樣的話，用例驅動的系統能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統開發鏈中完整的體現。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。 從前，系統開發者總是通過情節來獲取需求，是問用戶希望系統為他做什麼。在Jacobson發明了用例的概念之後，需求獲取就變成問用戶要利用系統做什麼。這是立場不同導致的結果。用戶通常並不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源於用戶，服務於用戶，但是它同樣可以用於開發的流程。當系統的開發過程都是基於用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。 用例和用例文檔

《軟體需求》一書中提到了幾種方法來確定用例：

· 首先明確執行者和他們的角色，然後確定業務過程，在這一過程中每一個參與者都在為確定用例而努力。

· 確定系統所能反映的外部事件，然後把這些事件與參與的執行者和特定的用例聯系起來。

· 以特定的說明形式表達業務過程或日常行為，從這些說明中獲得用例，並確定參與到用例中的執行者，有可能從現在的功能需求說明中獲得用例。如果有些需求與用例不一致，就應考慮是否真的需要它們。

用例代表了用戶的需求，在你的系統中，應該直接從不同用戶類的代表或至少應從代理那裡收集需求。用例為表達用戶需求提供了一種方法，而這一方法必須與系統的業務需求相一致。分析者和用戶必須檢查每一個用例，在把它們納入需求之前決定其是否在項目所定義的范圍內。基於「用例」方法進行需求獲取的目的在於：描述用戶需要使用系統完成的所有任務。在理論上，用例的結果集將包括所有合理的系統功能。在現實中，你不可能獲得完全包容，但是比起我所知道的其它獲取方法，基於用例的方法可以為你帶來更好的效果。

當使用用例進行需求獲取時，應避免受不成熟的細節的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節都作為需求記錄下來，他們會給隨後的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發過程中，將會詳盡闡述他們的需求。在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，並作為用例。然後，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和用戶對質量的期望。雖然最初的屏幕構思有助於描述你對需求的理解，但是你必須細化用戶界面設計。

建立用例文檔。在每一次的需求獲取之後，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術能夠提高你的速度和需求的復用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標識號、用例名稱、父用例標志號、創建者、創建時間、審核者、修訂記錄、角色、說明、先決條件、請求結果、優先順序、普通過程、可選過程、例外、非功能需求、假設、注釋和問題。

雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟體系統，並不是一大堆的用例說明。

2. 如何進行用戶需求分析

1.概念
需求的定義包括從用戶角度(系統的外部行為),以及從開發者角度(一些內部特性)來闡述需求.
關鍵的問題是一定要編寫需求文檔.我曾經目睹過一個項目中途更換了所有的開發者,客戶被迫與新的需求分析者坐到一起.系統的分析人員說:"我們想與你談談你的需求."客戶的第一反應便是:"我已經將我的要求都告訴你們前任了,現在我要的就是給我編一個系統".
百事通
而實際上,UGGs,需求並未編寫成文檔,因此新的分析人員不得不從頭做起.所以如果只有一堆郵件、會談記錄或一些零碎的未整理的對話,你就確信你已明白用戶的需求,那完全是自欺欺人.
需求的另外一種定義認為需求是"用戶所需要的並能觸發一個程序或系統開發工作的說明".有些需求分析專家拓展了這個概念:"從系統外部能發現系統所具有的滿足於用戶的特點、功能及屬性等".這些定義強調的是產品是什麼樣的,而並非產品是怎樣設計、構造的.而下面的定義則從用戶需要進一步轉移到了系統特性:
需求是指明必須實現什麼的規格說明.它描述了系統的行為、特性或屬性,是在開發過程中對系統的約束.
從上面這些不同形式的定義不難發現:並沒有一個清晰、毫無二義性的"需求"術語存在,真正的"需求"實際上在人們的腦海中,這個人們主要是指客戶,但一般情況下,用戶並不能描述自己的需要,只就需要系統分析人員根據用戶的自己語言的描述整理出相關的需要再進一步和客戶核對.系統分析員和客戶需要確保所有項目風險承擔者在描述需求的那些名詞的理解上務必達成共識.
任何文檔形式的需求(例如如下將要描述的需求規格說明書)僅是一個模型,一種描述.
2.需求分析的任務
開發軟體系統最為困難的部分就是准確說明開發什麼.最為困難的概念性工作便是編寫出詳細技術需求,這包括所有面向用戶、面向機器和其它軟體系統的介面.同時這也是一旦做錯,將最終會給系統帶來極大損害的部分,並且以後再對它進行修改也極為困難.
目前,國內產品的龐雜,一家企業可能有幾個系統並立運行,它們之間介面是系統開發人員最頭痛的問題.
對於商業最終用戶應用程序,企業信息系統和軟體作為一個大系統的一部分的產品是顯而易見的.但是對於我們開發人員來說,並沒有編寫出客戶認可的需求文檔,我們如何知道項目於何時結束?而如果我們不知道什麼對客戶來說是重要的,那我們又如何能使客戶感到滿意呢?
然而,即便並非出於商業目的的軟體需求也是必須的.例如庫、組件和工具這些供開發小組內部使用的軟體.當然你可能偶爾勿需文檔說明就能與其他人意見較為一致,但更常見的是出現重復返工這種不可避免的後果,而重新編制代碼的代價遠遠超過重寫一份需求文檔的代價,這些血的教訓正在國內的軟體開發者身上發生.
近來,我遇到一個開發小組開發包括代碼編輯器在內的一套內部使用的計算機輔助軟體.不幸的是,當他們開發完這個工具後,發現這個工具不能列印出源代碼文件,使用者當然希望有這個功能.結果這個小組只好手工抄寫源代碼文檔以供代碼檢查.這說明那怕需求明確無誤並構思准確,如果我們沒有編寫文檔,軟體達不到期望目標也只能是咎由自取了.
相反的情況,我曾見一個要集成到"錯誤跟蹤系統"中的簡單界面寫了一頁需求說明.而操作系統系統管理員在為處理腳本時發現簡單的一張需求清單竟是如此有用.他們依據需求對系統進行測試時,此系統不僅非常清晰地實現了所有必需功能,而且未發現任何錯誤.
事實上,需求文檔在開發過程中一直起指導作用.
3.需求分析過程
可把整個軟體需求工程研究領域劃分為需求開發和需求管理兩部分更合適,如圖4-1所示:
圖4-1 需求工程域的層次分解示意圖
需求開發可進一步分為:問題獲取、分析、編寫規格說明和驗證四個階段.這些子項包括軟體類產品中需求收集、評價、編寫文檔等所有活動.需求開發活動包括以下幾個方面:
確定產品所期望的用戶類別.
獲取每個用戶類的需求.
了解實際用戶任務和目標以及這些任務所支持的業務需求.
分析源於用戶的信息以區別用戶任務需求、功能需求、業務規則、質量屬性、建議解決方法和附加信息.
將系統級的需求分為幾個子系統,並將需求中的一部份分配給軟體組件.
了解相關質量屬性的重要性.
商討實施優先順序的劃分.
將所收集的用戶需求編寫成文檔和模型.
評審需求規格說明,確保對用戶需求達到共同的理解與認識,並在整個開發小組接受說明之前將問題都弄清楚.
需求管理需要"建立並維護在軟體工程中同客戶達成的合同" .這種合同都包含在編寫的需求文檔與模型中.客戶的接受僅是需求成功的一半,開發人員也必須能夠接受他們,並真正把需求應用到產品中.通常的需求管理活動包括:
定義需求基線(迅速制定需求文檔的主體).
評審提出的需求變更、評估每項變更的可能影響從而決定是否實施它.
以一種可控制的方式將需求變更融入到項目中.
使當前的項目計劃與需求一致.
估計變更需求所產生影響並在此基礎上協商新的承諾,這種承諾具體體現在項目解決方案上.
讓每項需求都能與其對應的設計、源代碼和測試用例聯系起來以實現跟蹤.
在整個項目過程中跟蹤需求狀態及其變更情況.
以上幾點說明是我總結了成功實施項目後系統分析人員的經驗,同時也根據國內外的其他系統實施的相關成功經驗,進行了總結.
4.需求的類型
下面這些定義是需求工程領域中常見術語的定義.
軟體需求包括三個不同的層次:業務需求、用戶需求和功能需求(也包括非功能需求).
1.業務需求(business requirement)反映了組織機構或客戶對系統、產品高層次的目標要求,它們在項目視圖與范圍文檔中予以說明.
2.用戶需求(user requirement) 文檔描述了用戶使用產品必須要完成的任務,這在使用實例(use case)文檔或方案腳本說明中予以說明.
3.功能需求(functional requirement)定義了開發人員必須實現的軟體功能,使得用戶能完成他們的任務,從而滿足了業務需求.
在軟體需求規格說明書 (SRS)中說明的功能需求充分描述了軟體系統所應具有的外部行為.軟體需求規格說明在開發、測試、質量保證、項目管理以及相關項目功能中都起了重要的作用.對一個大型系統來說,軟體功能需求也許只是系統需求的一個子集,因為另外一些可能屬於子系統(或軟體部件).
作為功能需求的補充,軟體需求規格說明還應包括非功能需求,它描述了系統展現給用戶的行為和執行的操作等.它包括產品必須遵從的標准、規范和合約;外部界面的具體細節;性能要求;設計或實現的約束條件及質量屬性.所謂約束是指對開發人員在軟體產品設計和構造上的限制.質量屬性是通過多種角度對產品的特點進行描述,從而反映產品功能.多角度描述產品對用戶和開發人員都極為重要.
下面以一個字處理程序為例來說明需求的不同種類.業務需求可能是:"用戶能有效地糾正文檔中的拼寫錯誤",該產品的包裝盒封面上可能會標明這是個滿足業務需求的拼寫檢查器.而對應的用戶需求可能是"找出文檔中的拼寫錯誤並通過一個提供的替換項列表來供選擇替換拼錯的詞".同時,該拼寫檢查器還有許多功能需求,如找到並高亮度提示錯詞的操作;顯示提供替換詞的對話框以及實現整個文檔范圍的替換.
從以上定義可以發現,需求並未包括設計細節、實現細節、項目計劃信息或測試信息.需求與這些沒有關系,它關注的是充分說明你究竟想開發什麼.項目也有其它方面的需求,如開發環境需求或發布產品及移植到支撐環境的需求.盡管這些需求對項目成功也至關重要,但它們並非本書所要討論的.
5.需求分析的原則
不重視需求過程的項目隊伍將自食其果.需求工程中的缺陷將給項目成功帶來極大風險,這里的"成功"是指推出的產品能以合理的價格、及時地在功能、質量上完全滿足用戶的期望.下面將討論一些需求風險.
不適當的需求過程所引起的一些風險:
1. 無足夠用戶參與
客戶經常不明白為什麼收集需求和確保需求質量需花費那麼多功夫,開發人員可能也不重視用戶的參與.究其原因:一是因為開發人員感覺與用戶合作不如編寫代碼有意思;二是因為開發人員覺得已經明白用戶的需求了.在某些情況下,與實際使用產品的用戶直接接觸很困難,而客戶也不太明白自己的真正需求.但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中,並一同經歷整個開發過程.
系統人員在實踐過程中,也有些感覺,在實施一家公司的項目時,若無足夠的用戶參與,系統人員獲得的需求是片面的,不完整的,這樣系統在需求之初就埋下風險.
2. 用戶需求的不斷增加
在開發中若不斷地補充需求,項目就越變越龐大以致超過其計劃及預算范圍.計劃並不總是與項目需求規模與復雜性、風險、開發生產率及需求變更實際情況相一致,這使得問題更難解決.實際上,問題根源在於用戶需求的改變和開發者對新需求所作的修改.
要想把需求變更范圍控制到最小,必須一開始就對項目視圖、范圍、目標、約束限制和成功標准給予明確說明,並將此說明作為評價需求變更和新特性的參照框架.說明中包括了對每種變更進行變更影響因素分析的變更控制過程,有助於所有風險承擔者明白業務決策的合理性,即為何進行某些變更,相應消耗的時間、資源或特性上的折中.
產品開發中不斷延續的變更會使其整體結構日漸紊亂,補丁代碼也使得整個程序難以理解和維護.插入補丁代碼使模塊違背強內聚、松耦合的設計原則,特別是如果項目配置管理工作不完善的話,收回變更和刪除特性會帶來問題.如果你盡早地區別這些可能帶來變更的特性,你就能開發一個更為健壯的結構,並能更好地適應它.這樣設計階段需求變更不會直接導致補丁代碼,同時也有利於減少因變更導致質量的下降.
3. 模稜兩可的需求
模稜兩可是需求規格說明中最為可怕的問題.它的一層含義是指諸多讀者對需求說明產生了不同的理解;另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明.
模稜兩可的需求會使不同的風險承擔者產生不同的期望,它會使開發人員為錯誤問題而浪費時間,並且使測試者與開發者所期望的不一致.一位系統測試人員曾告訴我,她所在的測試組經常對需求理解有誤,以致不得不重寫許多測試用例並重做許多測試.
處理模稜兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍.僅僅簡單瀏覽一下需求文檔是不能解決模稜兩可問題的.如果不同的評審者從不同的角度對需求說明給予解釋,但每個評審人員都真正了解需求文檔,這樣二義性就不會直到項目後期才被發現,那時再發現的話會使得更正代價很大.
4. 不必要的特性
"畫蛇添足"是指開發人員力圖增加一些"用戶欣賞"但需求規格說明中並未涉及的新功能.經常發生的情況是用戶並不認為這些功能性很有用,以致在其上耗費的努力"白搭"了.開發人員應當為客戶構思方案並為他們提供一些具有創新意識的思路,具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡,開發人員應努力使功能簡單易用,而不要未經客戶同意,擅自脫離客戶要求,自作主張.
同樣,客戶有時也可能要求一些看上去很"酷",但缺乏實用價值的功能,而實現這些功能只能徒耗時間和成本.為了將"畫蛇添足"的危害盡量減小,應確信:你明白為什麼要包括這些功能,以及這些功能的"來龍去脈",這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能.
5. 過於精簡的規格說明
有時,客戶並不明白需求分析有如此重要,於是只作一份簡略之至的規格說明,僅涉及了產品概念上的內容,然後讓開發人員在項目進展中去完善,結果很可能出現的是開發人員先建立產品的結構之後再完成需求說明.這種方法可能適合於尖端研究性的產品或需求本身就十分靈活的情況.但在大多數情況下,這會給開發人員帶來挫折(使他們在不正確的假設前提和極其有限的指導下工作),也會給客戶帶來煩惱(他們無法得到他們所設想的產品).
6. 忽略了用戶分類
大多數產品是由不同的人使用其不同的特性,使用頻繁程度也有所差異,使用者受教育程度和經驗水平也不盡相同.如果你不能在項目早期就針對所有這些主要用戶進行分類的話,必然導致有的用戶對產品感到失望.例如,菜單驅動操作對高級用戶太低效了,但含義不清的命令和快捷鍵又會使不熟練的用戶感到困難.
7. 不準確的計劃
據統計,導致需求過程中軟體成本估計極不準確的原因主要有以下五點:頻繁的需求變更、遺漏的需求、與用戶交流不夠、質量低下的需求規格說明和不完善的需求分析.
對不準確的要求所提問題的正確響應是"等我真正明白你的需求時,我就會來告訴你".基於不充分信息和未經深思的對需求不成熟的估計很容易為一些因素左右.要作出估計時,最好還是給出一個范圍.未經准備的估計通常是作為一種猜測給出的,聽者卻認為是一種承諾.因此我們要盡力給出可達到的目標並堅持完成它.
6.需求分析人員和用戶的合作關系
優秀的軟體產品是建立在優秀的需求基礎之上的.而高質量的需求來源於客戶與開發人員之間有效的交流與合作.通常,開發人員與客戶或客戶代理人,如市場人員間的關系反而會成為一種對立關系.雙方的管理者都只想自己的利益而擱置用戶提供的需求從而產生摩擦,在這種情況下,不會給雙方帶來一點益處.
只有當雙方參與者都明白要成功自己需要什麼,同時也應知道要成功合作方需要什麼時,才能建立起一種合作關系.由於項目壓力與日漸增,所有風險承擔者有著一個共同的目標這一點容易被遺忘.其實大家都想開發出一個既能實現商業價值,又能滿足用戶需要,還能使開發者感到滿足的優秀軟體產品.
軟體客戶需求權利書列出了十條關於客戶在項目需求工程實施中與分析人員、開發人員交流時的合法要求.每一項權利都對應著軟體開發人員、分析人員的義務.而軟體客戶需求義務書也列出了十條關於客戶在需求過程中應承擔的義務.如果願意,可以將其作為開發人員的權利書.
客戶有如下權利:
1:要求分析人員使用符合客戶語言習慣的表達
需求討論應集中於業務需要和任務,故要使用業務術語,你應將其教給分析人員,而你 不一定要懂得計算機的行業術語.
2:要求分析人員了解客戶的業務及目標
通過與用戶交流來獲取用戶需求、分析人員才能更好地了解你的業務任務和怎樣才能使產品更好地滿足你的需要.這將有助於開發人員設計出真正滿足你的需要並達到你期望的優秀軟體.為幫助開發人員和分析人員,可以考慮邀請他們觀察你或你的同事是怎樣工作的.如果新開發系統是用來替代已有的系統,那麼開發人員應使用一下目前的系統,這將有利於他們明白目前系統是怎樣工作的,其工作流程的情況,以及可供改進之處.
3:要求分析人員編寫軟體需求規格說明
分析人員要把從你和其他客戶那裡獲得的所有信息進行整理,以區分開業務需求及規范、功能需求、質量目標、解決方法和其它信息.通過這些分析就能得到一份軟體需求規格說明.而這份軟體需求規格說明便在開發人員和客戶之間針對要開發的產品內容達成了協議.軟體需求規格說明書可以用一種你認為易於翻閱和理解的方式組織編寫.要評審編寫出的規格說明以確保它們准確而完整地表達了你的需求.一份高質量的軟體需求規格說明能有助於開發人員開發出真正需要的產品.
4:要求得到需求工作結果的解釋說明
分析人員可能採用了多種圖表作為文字性軟體需求規格說明的補充.因為如工作流程圖那樣的圖表能很清楚地描述出系統行為的某些方面.所以需求說明中的各種圖表有著極高的價值.雖然它們不太難於理解,但是你很可能對此並不熟悉.因此可以要求分析人員解釋說明每張圖表的作用或其它的需求開發工作結果和符號的意義,及怎樣檢查圖表有無錯誤及不一致等.
5:要求開發人員尊重你的意見
如果用戶與開發人員之間不能相互理解,那關於需求的討論將會有障礙,共同合作能使大家"兼聽則明".參與需求開發過程的客戶有權要求開發人員尊重他們並珍惜他們為項目成功所付出的時間.同樣,客戶也應對開發人員為項目成功這一共同目標所作出的努力表示尊重與感激.
6:要求開發人員對需求及產品實施提供建議,拿出主意
通常,客戶所說的"需求"已是一種實際可能的實施解決方案,分析人員將盡力從這些解決方法中了解真正的業務及其需求,同時還應找出已有系統不適合當前業務之處,以確保產品不會無效或低效.在徹底弄清業務領域內的事情後,分析人員有時就能提出相當好的改進方法.有經驗且富有創造力的分析人員還能提出增加一些用戶並未發現的很有價值的系統特性.
7:描述產品易使用的特性
你可以要求分析人員在實現功能需求的同時還要注重軟體的易用性.因為這些易用特性或質量屬性能使你更准確、高效地完成任務.例如,客戶有時要求產品要"用戶友好"或"健壯"或"高效率",但這對於開發人員來說,太主觀了並無實用價值.正確的應是:分析人員通過詢問和調查了解客戶所要的友好、健壯、高效所包含的具體特性.
8:調整需求,允許重用已有的軟體組件
需求通常要有一定的靈活性.分析人員可能發現已有的某個軟體組件與你描述的需求很相符.在這種情況下,分析人員應提供一些修改需求的選擇以便開發人員能夠在新系統開發中重用一些已有的軟體.如果有可重用的機會出現,同時你又能調整你的需求說明,那就能降低成本和節省時間,而不必嚴格按原有的需求說明開發.所以說,如果想在產品中使用一些已有的商業常用組件,而它們並不完全適合你所需的特性,這時一定程度上的需求靈活性就顯得極為重要了.
9:獲得滿足客戶功能和質量要求的系統
每個人都希望項目獲得成功.但這不僅要求你要清晰地告知開發人員關於系統"做什麼"所需的所有信息,而且還要求開發人員能通過交流了解清楚取捨與限制.一定要明確說明你的假設和潛在的期望.否則,開發人員開發出的產品很可能無法讓你滿意.
客戶有下列義務:
1:給分析人員講解你的業務
分析人員要依靠你給他們講解的業務概念及術語.但你不能指望分析人員會成為該領域的專家,而只能讓他們真正明白你的問題和目標.不要期望分析人員能把握你們業務的細微與潛在之處,他們很可能並不知道那些對於你和你的同事來說理所當然的"常識".
2:抽出時間清楚地說明並完善需求
客戶很忙,經常在最忙的時候還得參與需求開發.但無論如何,你有義務抽出時間參與"頭腦風暴"會議的討論,接受采訪或其它獲取需求的活動.有時分析人員可能先以為明白了你的觀點,而過後發現還需要你的講解.這時,請耐心一些對待需求和需求的精化工作過程中的反復,因為它是人們交流中的很自然的現象,何況這對軟體產品的成功極為重要.
3:准確而詳細地說明需求
編寫一份清晰、准確的需求文檔是很困難的.由於處理細節問題不但煩人而且又耗時,故很容易留下模糊不清的需求.但是,在開發過程中,必須得解決這種模糊性和不準確性.而你恰是為解決這些問題作出決定的最佳人選.不然的話,你就只好靠開發人員去正確猜測了.在需求規格說明中暫時加上待定(to be determined, TBD也可採用漢語拼音略寫"DQD:待確定")的標志是個不錯的辦法.用該標志可指明了哪些需要進一步探討、分析或增加信息的地方.不過,有時也可能因為某個特殊需求難以解決或沒有人願意處理它而註上TBD標志.盡量將每項需求的內容都闡述清楚,以便分析人員能准確的將其寫進軟體需求規格說明中.如果你一時不能准確表述,那就得允許獲取必要的准確信息這樣一個過程.通常使用所謂的原型技術.通過開發的原型,你可以同開發人員一起反復修改,不斷完善需求定義.
4:及時地作出決定
正如一位建築師為你修建房屋,分析人員將要求你做出一些選擇和決定.這些決定包括來自多個用戶提出的處理方法或在質量特性沖突和信息准確度中選擇折衷方案等.有權做出決定的客戶必須積極地對待這一切,盡快做處理、做決定.因為開發人員通常只有等你做出了決定才能行動,而這種等待會延誤項目的進展.
5:尊重開發人員的需求可行性及成本評估
所有的軟體功能都有其成本價格,開發人員最適合預算這些成本(盡管許多開發人員並不擅長評估預測).你所希望的某些產品特性可能在技術上行不通,或者實現它要付出極為高昂的代價.而某些需求試圖在操作環境中要求不可能達到的性能或試圖得到一些根本得不到的數據,開發人員會對此作出負面的評價意見,你應該尊重他們的意見.有時,你可以重新給出一個在技術上可行、實現上便宜的需求,例如,要求某個行為在"瞬間"發生是不可行的,但換種更具體的時間需求說法("在50ms以內",但若沒有準確的技術分析不能輕易下結論),這就可以實現了.
6: 劃分需求優先順序別
大多數項目沒有足夠的時間或資源來實現功能性的每個細節.決定哪些特性是必要的,哪些是重要的,哪些是好的,是需求開發的主要部分.只能由你來負責設定需求優先順序,因為開發者並不可能按你的觀點決定需求優先順序.開發者將為你確定優先順序提供有關每個需求的花費和風險的信息.當你設定優先順序時,你幫助開發者確保在適當的時間內用最小的開支取得最好的效果.在時間和資源限制下,關於所需特性能否完成或完成多少應該尊重開發人員的意見.盡管沒有人願意看到自己所希望的需求在項目中未被實現,但畢竟是要面對這種現實的.業務決策有時不得不依據優先順序來縮小項目范圍或延長工期,或增加資源,或在質量上尋找折衷.
7:評審需求文檔和原型
正如我們將在第1 4章討論的,無論是正式的還是非正式的方式,對需求文檔進行評審都會對軟體質量提高有所幫助.讓客戶參與評審才能真正鑒別需求文檔是否的確完整、正確說明了期望的必要特性.評審也給客戶代表提供一個機會,給需求分析人員帶來反饋信息以改進他們的工作.如果你認為編寫的需求文檔不夠准確,就有義務盡早告訴分析人員並為改進提供建議.通過閱讀需求規格說明,很難想像實際的軟體是什麼樣子的.更好的方法是先為產品開發一個原型.這樣你就能提供更有價值的反饋信息給開發人員,幫助他們更好地理解你的需求.必須認識到:原型並非是一個實際產品,但開發人員能將其轉變、擴充成功能齊全的系統.
8:需求出現變更要馬上聯系
不斷的需求變更會給在預定計劃內完成高質量產品帶來嚴重的負面影響.變更是不可避免的,但在開發周期中變更越在晚期出現,其影響越大.變更不僅會導致代價極高的返工,而且工期也會被迫延誤,特別是在大體結構已完成後又需要增加新特性時.所以一旦你發現需要變更需求時,請一定立即通知分析人員.
9:應遵照開發組織處理需求變更的過程
為了將變更帶來的負面影響減少到最低限度,所有的參與者必須遵照項目的變更控制過程.這要求不放棄所有提出的變更,對每項要求的變更進行分析、綜合考慮,最後作出合適的決策以確定將某些變更引入項目中.
10:尊重開發人員採用的需求工程過程
軟體開發中最具挑戰性的莫過於收集需求並確定其正確性.分析人員採用的方法有其合理性.也許你認為需求過程不太劃算,但請相信花在需求開發上的時間是"很有價值"的.如果你理解並支持分析人員為收集、編寫需求文檔和確保其質量所採用的技術,那麼整個過程將會更為順利.盡管去詢問分析人員為什麼他們要收集某些信息,或參與與需求有關的活動.
系統分析人員在開發過程中可能會遇到以下問題,一些很忙的客戶可能不願意積極參與需求過程,而缺少客戶參與將很可能導致不理想的產品.故一定要確保需求開發中的主要參與者都了解並接受他們的義務.如果遇到分歧,通過協商以達成對各自義務的相互理解,這樣能減少今後的摩擦.
7.需求文檔
需求開發的最終成果是:客戶和開發小組對將要開發的產品達成一致協議.協議綜合了業務需求、用戶需求和軟體功能需求.就像我們早先所看到的,項目視圖和范圍文檔包含了業務需求,而使用實例文檔則包含了用戶需求.你必須編寫從使用實例派生出的功能需求文檔,還要編寫產品的非功能需求文檔,包括質量屬性和外部介面需求.只有以結構化和可讀性方式編寫這些文檔,並由項目的風險承擔者評審通過後,各方面人員才能確信他們所贊同的需求是可靠的.
你可以使用以下三種方法編寫軟體需求規格說明:
用好的結構化和自然語言編寫文本型文檔.
建立圖形化模型,這些模型可以描繪轉換過程、系統狀態和它們之間的變化、數據關系、邏輯流或對象類和它們的關系.
編寫形式化規格說明,這可以通過使用數學上精確的形式化邏輯語言來定義需求.
由於形式化規格說明具有很強的嚴密性和精確度,因此,所使用的形式化語言只有極少數軟體開發人員才熟悉,更不用說客戶了.雖然結構化的自然語言具有許多缺點,但在大多數軟體工程中,它仍是編寫需求文檔最現實的方法.包含了功能和非功能需求的基於文本的軟體需求規格說明已經為大多數項目所接受.圖形化分析模型通過提供另一種需求視圖,增強了軟體需求規格說明.

3. 需求分析實例

回答：海底行
神
10月22日 10:37 盡量把客戶所持的假設解釋清楚，特別是那些發生沖突的部分。從字里行間去理解以明確客戶沒有表達清楚但又想加入的特性或特徵。Gause 和Weinberg（1989）提出使用「上下文無關問題」—這是一個高層次的問題，它可以獲取業務問題和可能的解決方案的全部信息。客戶對這些問題的回答諸如「產品要求怎樣的精確度」或「你能幫我解釋一下你為什麼不同意某人的回答嗎？」這些回答可以更直接地認識問題，而這是封閉（close-end）問題所不能做到的。

需求獲取利用了所有可用的信息來源，這些信息描述了問題域或在軟體解決方案中合理的特性。一個研究表明：比起不成功的項目，一個成功的項目在開發者和客戶之間採用了更多的交流方式（Kiel and Carmel 1995）。與單個客戶或潛在的用戶組一起座談，對於業務軟體包或信息管理系統（MIS）的應用來說是一種傳統的需求來源。直接聘請用戶進行獲取需求的過程是為項目獲得支持和買入（buy-in）的一種方式。

盡量理解用戶用於表述他們需求的思維過程。充分研究用戶執行任務時作出決策的過程，並提取出潛在的邏輯關系。流程圖和決策樹是描述這些邏輯決策途徑的好方法。

在需求獲取的過程中，你可能會發現對項目范圍的定義存在誤差，不是太大就是太小。如果范圍太大，你將要收集比真正需要更多的需求，以傳遞足夠的業務和客戶的值，此時獲取過程將會拖延。如果項目范圍太小，那麼客戶將會提出很重要的但又在當前產品范圍之外的需求。當前的范圍太小，以致不能提供一個令人滿意的產品。需求的獲取將導致修改項目的范圍和任務，但作出這樣具有深遠影響的改變，一定要小心謹慎。

正如經常所說的，需求主要是關於系統做什麼，而解決方案如何實現是屬於設計的范圍。這樣說雖然很簡潔，但似乎過於簡單化。需求的獲取應該把重點放在「做什麼」上，但在分析和設計之間還是存在一定的距離。你可以使用假設「怎麼做」來分類並改善你對用戶需求的理解。在需求的獲取過程中，分析模型、屏幕圖形和原型可以使概念表達得更加清楚，然後提供一個尋找錯誤和遺漏的辦法。把你在需求開發階段所形成的模型和屏幕效果看成是方便高效交流的概念性建議，而不應該看成是對設計者選擇的一種限制。

需求獲取討論會中如果參與者過多，就會減慢進度。人數大致控制在5到7人是最好的。這些人包括客戶、系統設計者、開發者和可視化設計者等主要工程角色。相反地，從極少的代表那裡收集信息或者只聽到呼聲最高、最有輿論影響的用戶的聲音，也會造成問題。這將導致忽視特定用戶類的重要的需求，或者其需求不能代表絕大多數用戶的需要。最好的權衡在於選擇一些授權為他們的用戶類發言的產品代表者，他們也被同組用戶類的其它代表所支持。

沒有一個簡單、清楚的信號暗示你什麼時候已完成需求獲取。當客戶和開發者與他們的同事聊天、閱讀工業和商業上的文獻及在早上沐浴時思考時，他們都將對潛在產品產生新的構思。你不可能全面收集需求，但是下列的提示將會暗示你在需求獲取的過程中的返回點。

1. 如果用戶不能想出更多的使用實例，也許你就完成了收集需求的工作。用戶總是按其重要性的順序來確定使用實例的。

2. 如果用戶提出新的使用實例，但你可以從其它使用實例的相關功能需求中獲得這些新的使用實例，這時也許你就完成了收集需求的工作。這些新的使用實例可能是你已獲取的其它使用實例的可選過程。

3. 如果用戶開始重復原先討論過的問題，此時，也許你就完成了收集需求的工作。

4. 如果所提出的新需求比你已確定的需求的優先順序都低時，也許你就完成了收集需求的工作。

5. 如果用戶提出對將來產品的要求，而不是現在我們討論的特定產品，也許你就完成了收集需求的工作。

以上知識大致上討論需求分析應該如何做，實際上對於需求分析的方法有很多很多，已經形成了一定的理論，當然這種理論比較偏向與方法學，而方法學的應用主要還是要靠個人。所以，大家在實際應用的時候，不妨結合自己的實際，有選擇性的採用一些方法，那你就是成功的。
用例在需求分析中的使用

多年來，分析者總是利用情節或經歷來描述用戶和軟體系統的交互方式，從而獲取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把這種看法系統地闡述成用例（用例）的方法進行需求獲取和建模。雖然用例來源於面向對象的開發環境，但是它也能應用在具有許多開發方法的項目中，因為用戶並不關心你是怎樣開發你的軟體。而最重要的，用例的觀點和思維過程帶給需求開發的改變比起是否畫正式的用例圖顯得更為重要。注意用戶要利用系統做什麼遠遠強於詢問用戶希望系統為他們做什麼這一傳統方法。

用例的重要功能是用畫用例圖的功能來鑒別和劃分系統功能。它把系統分成角色（actor）和用例（用例）。角色(actor)表示系統用戶能扮演的角色（role）。這些用戶可能是人，可能是其他的計算機一些硬體或者甚至是其它軟體系統，唯一的標準是它們必須要在被劃分進用例的系統部分以外。它們必須能刺激系統部分並接收返回。用例描述了當角色給系統特定的刺激時系統的活動。這些活動被文本描述。它描述了觸發用例的刺激的本質，輸入和輸出到其他活動者，和轉換輸入到輸出的活動。用例文本通常也描述每一個活動在特殊的活動線時可能的錯誤和系統應採取的補救措施。

這樣說可能會非常復雜，其實一個用例描述了系統和一個角色（actor）的交互順序。用例被定義成系統執行的一系列動作，動作執行的結果能被指定角色察覺到。用例可以:

· 用例捕獲某些用戶可見的需求，實現一個具體的用戶目標。

· 用例由角色激活，並提供確切的值給角色。

· 用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。在UML中，用例表示為一個橢圓。

角色是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。在某些組織中很可能有許多角色實例（例如有很多個銷售員），但就該系統而言，他們均起著同一種作用，扮演著相同的角色，所以用一個角色表示。一個用戶也可以扮演多種角色。例如，一個高級營銷人員既可以是貿易經理，也可以是普通的營銷人員；一個營銷人員也可以是售貨員。在處理角色時，應考慮其作用，而不是人或工作名稱，這一點是很重要的。

我們使用不帶箭頭的線段將角色與用例連接到一起，表示兩者之間交換信息，稱之為通信聯系。角色觸發用例，並與用例進行信息交換。單個角色可與多個用例聯系；反過來，一個用例可與多個角色聯系。對同一個用例而言，不同角色有著不同的作用：他們可以從用例中取值，也可以參與到用例中。需要注意的是角色在用例圖中是用類似人的圖形來表示，盡管執行的，但角色未必是人。例如，角色也可以是一個外界系統，該外界系統可能需要從當前系統中獲取信息，與當前系統有進行交互。

一個用例可能包括完成某項任務的許多邏輯相關任務和交互順序。因此，一個用例是相關的用法說明的集合，並且一個說明（scenario）是用例的實例。這種關系就像是類和對象的關系。在用例中，一個說明被視為事件的普通過程(normal course)，也叫作主過程，基本過程，普通流，或「滿意之路」 (happy path)。在描述普通過程時列出執行者和系統之間相互交互或對話的順序。當這種交互結束時，執行者也達到了預期的目的。

在用例中的其它說明可以描述為可選過程(alternative coruse)。可選過程也可促進成功地完成任務，但它們代表了任務的細節或用於完成任務的途徑的變化部分。在交互序列中，普通過程可以在一些決策點上分解成可選過程，然後再重新匯成一個普通過程。

角色類和角色實例

軟體產品最終是給一些用戶來使用的，而用戶之間的差異是非常大的。造成差異的原因包括了對計算機的認知程度的不同，使用習慣的不同，在軟體目標組織中所處的地位不同，地理位置不同，業務熟練程度不同。

不同的用戶都有自己一系列的功能需求和非功能需求。對電腦熟練程度不同的人可能就會有不同的要求，熟練程度低的用戶可能希望有一個友好的界面，熟練程度高的用戶可能更希望有快捷鍵或宏的操作以提高工作效率。考慮到用戶的差異性，將用戶分類並研究用戶類的行為特徵是非常有必要的。所以在做具體的需求之前，先將用戶分局行為和特點進行分類，對於研究、收集用戶的需求是非常有幫助的。

可以利用一個簡單的表格列出一些原始的分類，然後不斷的完善這個表格。確認你的分類之間沒有交集。並充分描述用戶分類的行為，目的，要求等。在企業分析中，比較常見的分類可能包括，供應商，客戶，部門等。

就像C++中的類和對象一樣，我們把分析出的用戶分類稱為「角色類」，把實際的用戶稱為「角色實例」。在得到用戶分類之後，最重要的就是要選出用戶代表，用戶代表不僅僅是在需求階段中參與項目，還必須對項目的全過程負責。用戶代表能夠代表用戶分類的需求。抓住用戶代表的需求就大致把握住了用戶類的需求。當然，需求分析還是需要在用戶中做大規模的調查的，只是要把重點放在用戶代表上。

確保和用戶直接進行溝通！大家有沒有玩過傳話的游戲，可能看過。一群人排成一列，一句話從排頭挨個向後傳，到最後，那句話已經是面目全非了。所以，一定要保證項目組能夠直接和用戶接觸。

對於和用戶直接溝通這一點，一般的針對特定企業的應用系統當然是不成問題，可是如果是開發行業軟體，和用戶直接溝通就成為一件幾乎是不可能的事情。在這種情況下，一般有幾種解決的辦法：

做大規模的市場調查，針對你的目標市場做市場調查，並根據統計學的理論建立你的數學模型。這部分的工作效果最好，其性質有些象一些游戲公司會發布一些Demo版的游戲。可是對於一般的企業來說，這項工作費時費力，高昂的成本往往使大家知難而退。我的意見是，方法是非常好的，但是可以採用折衷的辦法，例如選取有代表性的企業，為特定企業製作一個較小的版本並收集反饋意見等。這涉及到很多市場營銷的內容，並不是我的專業所長，這里就不多弄斧了。
聘請行業專家，一個行業專家往往可以在項目需求方面發揮極為重要的作用。一個行業專家往往都有大量的行業經驗和行業的人際關系網路。在產品的設計方面，這個行業專家提供很多寶貴的意見。在目前很多的軟體的開發過程中都採用了這種方式。行業專家有兩種：一種是在這個行業中有很深的資歷，但是對軟體技術並不熟悉；第二種是開發過同類軟體的軟體專家，這種人在開發同類軟體過程中已經積累了大量的項目經驗，並且具有軟體開發的知識。這種方式是獲取需求的最好的方式。 分析對比同類軟體，微軟在開發Office、Visual Studio的時候，也是參照了Lotus和Borland的成熟產品。這種方式的特點在於成本很低，比較適合和其他的方式配合使用。但是，要注意自己有沒有觸犯專利法。

需求的沖突

有的時候，雖然已經將用戶分類並選出了用戶代表。但是需求的來源眾多，往往會發生需求之間自相矛盾的事情。需求從四面八方收集來後，人們難以解決沖突，澄清模糊之處以及協調不一致之處。某些人還要對不可避免要發生的范圍問題單獨作出決定。在項目的早期階段，你必須決定誰是需求問題的決策者。如果不清楚誰有權並且有責任來作出決策，或者授權的個人不願意或不能作出決策，那麼決策者的角色將自然而然地落在開發者身上。這是一個非常糟糕的選擇，因為開發者通常沒有足夠多的信息和觀點來作出業務上的決策。

在軟體項目中，誰將對需求作出決策的問題並沒有統一的正確答案。分析員有時聽從呼聲高的或來自最高層人物的最大的需求。即便使用用戶代表這一手段，必須解決來自不同用戶類的相沖突的需求。通常，應盡可能由處於公司底層的人作出決策，因為他們與問題密切相關，並能得到關於這些問題的廣泛信息。

如果不同的用戶類有不一致的需求，那麼必須決策出滿足哪一類用戶的需求更為重要。了解可能使用產品的客戶種類的信息和他們的用法與產品的業務目標的關系如何，將有助於你決定哪一個用戶類所佔份額最大。

當開發者想像中的產品與客戶需求沖突時，通常應該由客戶作出決策。然而，不要陷到「客戶總是對的」的陷阱中去，對他們百依百順。現實中，客戶並不總是對的。客戶總是持有自己的觀點，開發者必須理解並尊重這一觀點。

用例

在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由於用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和用例。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。

為什麼要採用這種分析方法呢？計算機系統除了在與外界系統、人員有一系列的交互，在系統內部也往往存在著復雜的交互。因此，在系統建模時，除了描述系統與外界的交互，同時還要描述系統內部的交互。傳統的MIS系統中，系統與外界的交互較多。典型的，如ATM取款機：存在著大量的用戶與ATM，ATM與其它系統的交互。而電信領域的系統，與外界的交互較少。例如，系統的輸入可能僅僅是從交換機上採集信息，然後由系統進行處理。系統的復雜邏輯包含在系統內部處理的流程上，而非與外部系統的交互。建模主要任務是表達系統內部的交互。

用例圖適於表達交互，之所以上面使用了電信系統，是因為用例最早來自於Ericsson的交換機系統。當時，還是Ericsson雇員的Jacobson初步建立了用例圖的概念，並於1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，比較適合支持商業工程和需求分析。隨著用例的發展，用例被大量的用於對功能進行描述。每個用例代表了系統與外部ACTOR的交互。可以採取順序圖來表達用例的具體操作程序。ACTOR用於確定系統的邊界。

ACTOR、用例可以從不同的層次來描述信息。採用該原則的原因有：

1. 需求並不是在項目一開始就很明確，往往是隨著項目的推進，逐漸細化。

2. 人的認知往往具有層次的特性。從粗到細、從一般到特殊。採用不同的層次來描述，適於認知的過程。

使用用例開發系統的一般過程

在開發過程的初始階段，可以根據具體的項目特點，制訂開發各個視圖之間的關聯原則，指導規范。在開發的過程中，視圖的組織原則應不斷進行維護、更新。

識別ACTOR來識別系統與外界交互的實體。ACTOR具有特定領域的特徵，例如：交換機（採集系統）、97信息系統等。在系統層次的ACTOR確定了系統的邊界。

識別用例。同ACTOR一樣，用例具有不同層次。對較為概括的USECASE，需要細化。註：系統開發需要一定的規則來確定，如何來分解用例；可能基於原有系統的經驗，或是參考現有資料。

當用例細化到可以被理解的層次。需要基於用例進行下一步的開發。如前面提到的，用例主要用來描述交互。因此，存在交互的實體和交互的細節。交互的實體採用類圖來描述；而交互的細節，採用順序圖來描述。

當系統復雜到一定層次時，類圖和順序圖可能不能足以描述其復雜程度。在該情況下，需要使用狀態圖來輔助闡述。狀態圖和順序圖之間使用事件聯結在一起。它們之間的一致性問題，目前UML和ROSE沒有提供解決方案。相對折衷的方法是使用事件的命名規范強制一致性。

可以說，之前說的所有的東西都是為了能夠導出用例在需求中的作用。用例是從用戶的角度看待系統，而不是基於程序員的角度。這樣的話，用例驅動的系統能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統開發鏈中完整的體現。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。 從前，系統開發者總是通過情節來獲取需求，是問用戶希望系統為他做什麼。在Jacobson發明了用例的概念之後，需求獲取就變成問用戶要利用系統做什麼。這是立場不同導致的結果。用戶通常並不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源於用戶，服務於用戶，但是它同樣可以用於開發的流程。當系統的開發過程都是基於用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。 用例和用例文檔

《軟體需求》一書中提到了幾種方法來確定用例：

· 首先明確執行者和他們的角色，然後確定業務過程，在這一過程中每一個參與者都在為確定用例而努力。

· 確定系統所能反映的外部事件，然後把這些事件與參與的執行者和特定的用例聯系起來。

· 以特定的說明形式表達業務過程或日常行為，從這些說明中獲得用例，並確定參與到用例中的執行者，有可能從現在的功能需求說明中獲得用例。如果有些需求與用例不一致，就應考慮是否真的需要它們。

用例代表了用戶的需求，在你的系統中，應該直接從不同用戶類的代表或至少應從代理那裡收集需求。用例為表達用戶需求提供了一種方法，而這一方法必須與系統的業務需求相一致。分析者和用戶必須檢查每一個用例，在把它們納入需求之前決定其是否在項目所定義的范圍內。基於「用例」方法進行需求獲取的目的在於：描述用戶需要使用系統完成的所有任務。在理論上，用例的結果集將包括所有合理的系統功能。在現實中，你不可能獲得完全包容，但是比起我所知道的其它獲取方法，基於用例的方法可以為你帶來更好的效果。

當使用用例進行需求獲取時，應避免受不成熟的細節的影響。在對切合的客戶任務取得共識之前，用戶能很容易地在一個報表或對話框中列出每一項的精確設計。如果這些細節都作為需求記錄下來，他們會給隨後的設計過程帶來不必要的限制。你可能要周期性地檢查需求獲取，以確保用戶參與者將注意力集中在與今天所討論的話題適合的抽象層上。向他們保證在開發過程中，將會詳盡闡述他們的需求。在一個逐次詳細描述過程中，重復地詳述需求，以確定用戶目標和任務，並作為用例。然後，把任務描述成功能需求，這些功能需求可以使用戶完成其任務，也可以把它們描述成非功能需求，這些非功能需求描述了系統的限制和用戶對質量的期望。雖然最初的屏幕構思有助於描述你對需求的理解，但是你必須細化用戶界面設計。

建立用例文檔。在每一次的需求獲取之後，都會生成很多未整理的需求，你必須將它們組織成用例文檔。使用諸如模板的技術能夠提高你的速度和需求的復用性。一個用例文檔可以使用表格來組織，主要的要素包括了用例標識號、用例名稱、父用例標志號、創建者、創建時間、審核者、修訂記錄、角色、說明、先決條件、請求結果、優先順序、普通過程、可選過程、例外、非功能需求、假設、注釋和問題。

雖然列舉出了這么多的屬性，但是實際中使用的屬性這要看你的團體而定，看項目的大小而定。把大量的時間花在用例的描述上是沒有意義的。用戶需要的是一個軟體系統，並不是一大堆的用例說明。

4. 用戶需求分析方法

客戶的需求是我們銷售行為的關鍵，但是客戶不會每次都會毫無保留的告訴你，所以我們要通過行業分析，客戶需求分析，了解客戶需求，解決問題。


一、分析競爭對手

想要了解客戶需求，就要先了解市場發展及我們的競爭對手。中國自古就有一句古話：知己知彼百戰百勝，銷售更應牢記這句話，因為只有你足夠了解你的競爭對手，才能做出應對。了解競爭對手，不僅要了解競爭對手的價格、特徵，還要了解有哪些長處、不足、銷量及銷售形式等，我們只有足夠透徹的了解競爭對手，才能在市場掌握主動權，同時也能從另一方面了解到市場需求。


二、客戶特點及習慣

一方面要了解客戶的興趣愛好，消費習慣等，另一方面要從銷售本身出發，了解客戶的內心，一般客戶都比較重視產品質量和售後服務，我們只需要把握好這兩點往往銷售會比較容易成功。

三、客戶的真實需求

要想了解客戶的真實需求需要尋找客戶需求、仔細發現、等待客戶需求呈現、確認客戶需求、最後成交。了解客戶需求是成交的必要條件。


四、滿足客戶

要學會維護客戶自尊，溝通過程中多用：有什麼我可以幫您的嗎？您的事我一直放在心上，會盡快給您處理的；您好有眼光等等。可以讓對方感覺到受到了尊重和重視，同時客戶也會感覺有良好的消費體驗。

細心聆聽客戶心聲，溝通過程中多用：您的意思是......對嗎？原來是這樣；我知道您的感受或心情等。要認真聽客戶講的話，體會對方感受，並及時給予回應，說出自己的想法。

5. 需求分析的主要方法是

需求分析就是對客戶提出的「要求」或者「需求」進行深入細致地調研和分析，准確理解用戶和項目的功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼，為系統設計、系統完善和系統維護提供依據。

需求分析是項目計劃階段非常重要的環節，該環節決定了需要「實現什麼」，為下一步如何去「實現」提供了明確的方向。

進行需求分析需要做到以下幾點：

（一）需求獲取：在准備階段，我們首先要確定需求獲取的目標及范圍，根據你的目標來選擇對應的方式獲取需求。

（二）需求分類：一般情況下，我們會根據對象的不同，將需求分為業務需求、用戶需求、功能需求等。

（三）需求篩選：有些需求是偽需求，有些需求則不具備實現價值，我們可以通過真實性、價值性、可行性三個維度來篩選需求，過濾掉虛假的、不可行的、沒有價值、價值不大或投入產出比不理想的需求。

（四）需求提煉：對剩下的需求進行提煉，目的在於從獲取的表面需求中提煉出客戶的本質需求。找出「為什麼要做」比「做什麼」更重要。

（五）需求優先順序排序：挖掘到客戶的真實目的後，我們需要根據不同維度的需求歸類方法，如KANO模型分析法、投入產出比ROI等，對其進行歸納整理並排出優先順序，幫助產品有條理地安排開發秩序，避免盲目排序。

（六）產出需求文檔：通過以上的分析，我們需要將收集到的需求進行分析、匯總、歸類，輸出產出需求文檔，為接下來的工作做好鋪墊。

以上是對需求分析的一些理解和思路，做好需求分析工作之後，就可以對可實現的需求進行落地方案的跟進。

6. 需求分析的主要方法是什麼

1.1 需求的背景

需求的背景指的是動機，這一項實質上是換位思考，它能夠幫助我們從業務方的角度，從使用場景、用戶心理去理解需求。

在實際工作中，我們所接收到的「需求」常常是表述不清晰的、不完整的，甚至是具有欺騙性的。

一個問題會對應許多的解決方案，找到真正的需求，也正是我們的職責。

1.2 需求的受眾

需求的受眾需要注意的問題有兩點：

誰是真正的受眾；
受眾人群是否具有代表性。
需求的來源很多，可能是用戶、業務方等。我們需要分清楚誰才是真正的受眾。

在一個需求里不同的角色認知和訴求是不同的，當信息帶上了主觀判斷也就被污染了。

其次，則是覆蓋度的問題。對於頻次不夠高或者人群不夠有代表性的需求，投入產出比會是一個大大的問號。辨清受眾，在評估需求的優先順序和制定解決方案時，迷惑性會大大降低。

1.3 需求的目的

需求的目的指需要做什麼，很多時候我們接到的「需求」其實是業務方過濾後的「解決方案」。

以「口渴」為例，此時業務方提出的需求是要製作一台飲水機，然而飲水機並不能解決問題。如果我們挖掘到背後的動機是「口渴」，那麼我們可以從補充水分和減少水分的流失來著手提供解決方案。

1.4 需求的目標

在漢語辭典里的解釋，目的是期望，而目標是成果。

目標更為具象，並且能夠用數據指標來衡量，後續也能夠指導需求的改進。

需求的本質是為了創造價值，而創造價值最直白的則是開源和節流。具象到目標，可以用創造的收益，提升的效率以及節省的資源等方面進行量化。

2. 因果關系分析法
、需求優先順序的評定
最後一個環節是需求優先順序的評定，我常用的方法是選取影響優先順序的因素並設定比例，經過加權計算出優先順序，分數越高優先順序越高。

其公式如下：

優先順序=因素1比例*因素1分值+因素2比例*因素2分值+….

表1-需求評估加權表

這張表，影響的因素主要有兩項：投入產出比以及重要程度。

投入產出比個人認為是必選的，而重要程度中的維度可以根據實際情況去增加、減少。同理，加權中比例的設置也是如此。

7. 軟體工程中常用的需求分析的方法有哪些

一、過濾需求的方法
做後端系統，要學會的第一個技能就是砍需求。也就是過濾需求。

這不是一個貶義詞，反而是體現後端產品價值判斷的基礎。

過濾需求的方法，就是通過一定的手段判斷需求是否是偽需求，應該被過濾掉。

1. 用戶場景模擬法
後端產品的出發點就是幫助業務用戶，因此在調研需求的時候要模擬業務的場景，分析業務用戶提到的需求是否能解決他的問題。

如果不能幫助用戶，那麼這個需求就可能是偽需求。

以下面的案例說明：

背景：「貨到付款」類型的訂單會因為缺貨而無法發出，如果超過一定的時間，客服就會跟顧客溝通，幫顧客取消訂單。

需求：由於這種訂單的數量還是蠻多的，逐個取消太費時間，因此業務用戶要求在「缺貨訂單」列表頁增加「批量取消訂單」按鈕。

分析：調研到業務操作場景,是先找到該類缺貨訂單，然後和顧客溝通，顧客同意刪除，才進行刪除。也就是逐個溝通確認，再逐個取消訂單的，所以「批量取消訂單」無法被有效使用。

因此，該需求是個偽需求，應該被過濾掉。

2. 功能歸屬分析
專門的系統做專職功能，有助於合理的產品體系建設。

因此需求調研的時候，可以通過系統的定位，判斷需求是否應該在該系統完成。

如果不屬於該系統范疇，那麼直接說服需求方更換方案。以

下面的案例說明：

背景：CRM系統（顧客關系管理系統）有一個顧客標簽生成功能，就是根據顧客的消費行為數據，自動對應關聯上標簽，如優質顧客、高潛力顧客、欺詐顧客等。

需求：業務用戶提出需求，除了做上述的基礎標簽之外，還要做出英語版本的標簽（就是把標簽文案翻譯成英文），這樣歐美員工可以在英語版本的系統下使用。

分析：調研到翻譯之後的標簽不是在CRM系統使用的，而是給到SMS（客服系統）使用的。

所以應該由SMS根據CMS提供的基礎標簽數據，自己做二次的衍生。

之所以這樣，首先是為了避免未來更多語言版本的擴展需求或更多系統提出類似的需求；

其次，CRM系統已經完成了「接力賽」的第一棒，創造了基礎數據，那麼其他系統要特殊化使用，完全可以自行進行特殊化處理，無需耦合回CRM系統。

結論：案例的需求本身是真需求，並且實現上也沒難度，但是該功能的定位超出了本系統范疇，專門系統做專職功能，化衍生需求應該在下游執行。

否則，耦合性過高只會增加系統的復雜程度，難以維護和擴展。

二、拆分和聚合的方法
1. 拆分需求法
業務用戶提出一個需求，很可能只是短短的一段話。

但是不要高興太早，可能這一句話暗含了很多線索，因此要善於拆分：

先找他要解決的核心問題，再圍繞核心點，理清前、後、左、右、上、下的旁系需求點。

每個需求點再當做一個子需求進行調研，最後再聚合在一起。

以下面的案例說明：

背景：訂單業務的類型很多，訂單退貨之後需要創建售後單據，但是因為數量大，所以花費很多人力，且手動創建有出錯的風險。

需求：業務提出的需求是「增加退貨訂單自動創建售後單的功能」，這是個一句話需求。

該一句話需求，其實包含了多種具體的訂單類型和場景，那麼我們就要拆分調研，拆分的維度比如：

自營訂單、第三方訂單、貨到付款訂單、先款後貨訂單、部分退貨訂單、完全退貨訂單、服裝事業部訂單、電子事業部訂單等，其中每一個維度就相當於一個小需求。

這里不一一展開。

2. 聚合需求法
拆分法是對單個需求分解成若干小需求進行調研，聚合法相反，是找到許多個相互關聯的小需求的共性，然後統籌成一個大需求去完成。例如：

由於業務用戶分散在不同的部門，各自為政，於是張三、李四可能都對一個業務流程有相同的需求，或者對同一個功能有相同的優化期望，結果倆人分別提了需求過來。那麼產品經理就要找到二者背後的相關性和交叉區。

然後統籌規劃，聚合在一起當作一個需求來調研，最終輸出一個整體的需求調研結果。

三、利用輔助功能調研需求
調研產品現有功能，可以用來確認原有功能的邏輯，或者確定新需求方案是否可行。

比如業務用戶需要更新一個功能，為了避免更新出錯或遺漏，產品經理需要知道修改前和修改後是否會能正常運行。

最基礎的辦法就是自己設計一個測試用例，記錄操作方式、狀態變化、數據流向等。看看下面的例子：

背景：從銷售網站獲取到OMS系統（訂單管理系統）的訂單信息中帶著顧客的郵箱。顧客下完單，可能會在銷售網站修改郵箱，而此時已經獲取到OMS的歷史訂單中的郵箱是不變的。

需求：顧客若在銷售網站修改郵箱，要求已獲取到OMS的該顧客的訂單中的郵箱也要同步修改。

分析：需求是很明白的，也有它的意義，但有風險。

因為我們知道訂單信息貫穿於整個訂單流轉過程中，牽扯到訂單編輯、審核、取消、配貨、發貨等，而這些環節跳轉的觸發條件可能就是某個信息更新（這裡面就可能包括有郵箱更新）。

因此，更新郵箱是否會影響流程中的某些環節，一時間很難准確知道。

於是，我們可以採用預測試的方式，設計測試用例，在測試機運行一些訂單，觀察各個環節郵箱變更的影響，然後收集起來分析對策。

測試法就像是探雷一樣，主要用來解決未知風險點。這個方式的重點是記錄和分析操作前狀態、操作位點、操作後狀態、操作後觸發的連鎖反應、數據流向等。

四、「拔蘿卜帶出泥」的方式調研需求
調研需求時，產品經理要拔蘿卜帶出泥,挖掘用戶沒看到的需求點和價值。

舉例說明：

背景：公司入駐到銷售平台後，銷售平台會對入駐的店鋪的違規行為進行罰款。

需求：業務用戶提出需求，將銷售平台的罰款數據抓取到訂單系統，關聯訂單數據，以便進行人工分析。

分析：

第一步，先拆分需求，確定什麼是罰款數據，總共有哪些罰款種類，需要對接哪些罰款種類，罰款數據與訂單系統關聯方式是什麼，是否都能關聯到，關聯不到怎麼辦，銷售平台是否已經提供了公用的罰款介面，Token（請求許可權）如何獲取，抓取頻率怎麼樣，數據增長幅度多大，獲取之後做哪些展示和搜索，用戶許可權怎麼設置，需要和訂單系統做哪些交互，該需求的價值是什麼……

第二步，挖掘需求：是否需要作分析功能，分析功能的規則是什麼；是否需要做監控和預警，是否需要指派負責人；其他業務人員是否也有類似需求，其他平台是否也有類似需求……

通過「拔蘿卜帶出泥」的方式，連帶出更多需求點。將上述調研結果重新組裝起來，得到一個系統化的完整需求。

羅列出需求要點和對應的驗收目標，這樣使得需求具象化，同時又不會遺漏細節，內部充實，外部閉環，並且進行了價值挖掘，做成控制閾值、預警、責任人分派、趨勢分析、損失分析等高價值的功能，超出業務的預期。

8. 我們應當怎樣做需求分析：功能角色分析與用例圖

在我們進行一系列需求調研工作的同時，我們的需求分析工作也開始啟動了。需求調研與需求分析工作應當是相輔相伴共同進行的。每次參加完需求調研回到公司，我們就應當對需求調研的成果進行一次需求分析。當下一次開始進行需求調研時，我們應當首先將上次需求分析的結果與客戶進行確認，同時對需求分析中提出的疑問交給客戶予以解答。這就是一個需求捕獲->需求整理->需求驗證->再需求捕獲的過程。

但是，當我們經過一番忙碌，將需求中的第一手資料從調研現場捕獲回來以後，我們應當怎樣進行分析呢？不少團隊對此都比較迷茫，沒有一個統一和有效的方法，往往採用想到哪裡做到哪裡的方式。一些問題想到了就做了，沒有想到則忽略掉了。實際上，需求分析不應當是太公釣魚，而應當是拉網排查。任何一個疏忽都可能對項目研發帶來風險。因此，我們應當採用一套成熟而完整的分析方法，穩步而有序地完成這部分工作。不同類型的軟體項目其分析方法可能存在差異，但一般來說，信息化管理類軟體項目通常從這幾個方面著手分析：功能角色分析、業務流程分析與業務領域分析。

需求分析不是一項一蹴而就就可以完成的工作，它需要一個長期的過程，而這個過程是一個由粗到細的過程，它體現了人類認識事物的客觀規律。在需求分析的初期，我們對需求的認識往往是整體的、宏觀的，隨著分析工作的逐漸深入，一步步細化。按照這個思路，我們對需求的分析，首先應當從功能角色分析開始。所謂功能角色分析，就是從一個外部用戶的視角分析整個軟體系統能夠提供的功能，以及這些功能到底是提供給哪些角色使用。

對一個系統進行功能和角色方面的梳理和分析，可以採用的比較主流的方法之一就是繪制用例圖。用例圖是UML的4+1視圖中的一種，准確地說就是那個「+1」。用例圖是貫穿整個面向對象分析/設計（OOA/D）的核心視圖，它描述的是系統到底為用戶提供了哪些功能，以及到底是哪些用戶在使用這些功能，是溝通用戶與技術人員的橋梁。運用用例視圖對業務需求進行分析、抽象、整理、提煉，進而形成抽象模型的過程稱之為用例建模，而這個模型就是用例模型。

一般地，在一個用例圖中通常有三種元素：參與者（Actor）、用例（Use Case）與系統邊界（Boundary）。用例描述的是系統為用戶提供的功能，也就是系統能為用戶做什麼，通常被繪製成一個橢圓；參與者，我認為稱為角色更加合適，也就是系統為哪些類型的用戶提供服務，他們都各自承擔哪些不同的職責，通常被繪製成一個小人兒；最後是系統邊界，也就是系統是對現實世界哪個范圍的內容進行的模擬，它涉及到軟體設計的工作范圍與工作量，通常被繪製成一個方框。但是，通常情況下系統邊界只是一個概念而不用真正繪制出來，因為被繪製成用例的必然是系統內部的功能，被繪製成參與者的必然是系統外部事物。從這個意義上講，用例圖中的參與者不僅包括人，還包括那些外部系統和自動觸發器。根據這樣一個思路，我以往常常將外部系統和自動觸發器繪製成一個小人，這常常令客戶感到困惑。隨後我改變了思路，將外部系統和自動觸發器繪製成另一種表達形式——類元符號表示法，並在構造型上標注為Actor。

功能角色分析是對系統宏觀的、整體的需求分析，它用簡短的圖形繪制出了一個系統的整體輪廓。但僅僅進行功能角色分析是遠遠不夠的，我們還需要在它的基礎上做更加詳盡的分析。

9. 如何做需求分析

一、 我們應當如何做需求分析

需求分析不是一蹴而就的，它應當貫穿整個開發周期，不斷的分析確認的過程。這就是敏捷開發倡導的需求反饋。敏捷開發認為，需求分析階段不可能解決所有的需求問題，因此在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證項目的成功。

二、我們應當怎樣做需求調研

1.初識。

我們對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險。這毫無疑問會形成一個良性循環，但要做到這一點並不容易，毫無疑問，在與客戶接觸初期的表現起到了極其關鍵的作用。

(1)高層領導關心的是宏觀的目標，因此軟體研發目標、宏觀統計報表、決策支持功能，我們應該怎樣做需求分析,應當與高層領導談。

(2)中層領導關心的是具體的效益，即軟體給各個部門信息化管理方面帶來的效益，因此，中層領導是各項業務流程、功能模塊的需求決策者。他們關心功能的定義、業務流轉的銜接、查詢報表的設計，但不太關心一些具體的操作，以及一些具體業務流程的細節。

(3)基層人員是每一項業務流程的操作者，也是軟體今後真正的使用者。他們是真正了解你所要開發的軟體的業務需求的領域專家，是你進行需求調研的重點對象。但是，基層人員往往受到自身視野的局限，可能只清楚自己工作涉及的十分狹小的一個范圍，因此我們需要努力尋找那些業務涉及面廣，經驗豐富，又有一定大局觀的真正的專家。另外 ，他們就是軟體今後真正的使用者，讓他們參加，會讓他們成為今後軟體推行的忠實支持者，對其他操作人員的指導者，益處多多。而他們關心的則是每項操作的細節。

俗話說：萬事開頭難。如果你在項目開始的時候總感覺千頭萬緒不知如何著手，在這里我給大家的三點建議：

1）樹立良好的職業威信；

2）進行詳細角色分析，將與會各方代表對號入座；

3）從宏觀上制訂目標與方案。隨後的工作，就是與各方代碼建立聯系，逐一拜訪他們，將需求調研工作一步一步進行下去。

2.拜訪。

需求調研不是一蹴而就的事情，是一件持續數月甚至數年的工作（假如項目還有後期維護） 。在這漫長的時間里，我們需要依靠客戶這個群體的幫助，一步一步掌握真實可靠的業務需求 。不僅如此，技術這東西總有不如意甚至實現不了的地方，我們需要客戶的理解與包容，這都需要有良好的客戶關系。盡管如此，我們也不能總是期望客戶中的所有人都能與我們合作，很多項目都不可避免地存在阻礙項目開展的人。

3.研討會。

(1)由於業務人員自身的局限 ，不可能對所有業務領域的細節全面掌握，往往總是有自己熟悉的部分，也有自己不熟悉的部

分。劃分業務組，可以讓業務人員分別在自己最熟悉的業務范圍內參與討論，可以有效提高業務討論的質量；

(2)集中式的業務研討形式和分散式的業務研討形式；

(3)有效抑制個性化差異、分模塊組織專項研討會。

4.業務研討

在需求分析過程中，客戶存在的最大問題就是提不出正確的需求，這表現為幾種形式：

(1)由於對軟體不了解，客戶提不出需求，不知道軟體最終會做成什麼樣子。這類客戶在需求討論過程中，往往只能描述目前自己手工管理的方式是怎樣的，不知道計算機會怎樣管理。

(2)能提出一些業務需求，但當軟體做出來擺在自己面前時，需求就變了。這類客戶，他們能熟練使用電腦，對信息化管理是清楚的。他們提出的業務需求從整體上應當是八九不離十的 。但是，由於沒有實物，在軟體中的一些具體操作並沒有完全想清楚。

(3)能非常詳細地提出業務需求，甚至有時候該怎麼做的提出來了。這類客戶，參與過很多軟體信息化建設，甚至有些還是軟體開發的半專業人士。但是他們提出的業務需求過於具體 ，甚至怎樣實現都說出來了，但這些有時候不是最佳設計方案、可能在技術上難於實現，甚至有些就是過於理想化而不可實現。

解決辦法:

業務領域分析:客戶現有的業務流程是什麼樣的，都有些什麼操作？客戶在業務中都有些什麼事物，什麼專用名詞，都是怎樣定義的，相互之間的關系是什麼？客戶在每一項操作中的目的是什麼，為什麼要這樣做，他們製作的手工報表都說明了什麼問

題？

(1)我們做需求分析，眼界不能僅僅停留在軟體本身，應當更開闊一些，應當擴展到跟這個業務有關的那些領域知識中。

(2)在客戶提出的所有原始需求中那些與業務實現有關的需求都是無效的需求，它們僅僅只能作為我們的一個參考。

(3)還有一些是技術難於實現或者根本就無法實現的需求，我們應當耐心地說服和引導客戶，並給他提出一個更加合理的方案。

(4)需求分析不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟體研發，才能保證需求的正確與變更的可控。

5.迭代

在第一次的需求分析階段，我們在一段時期內需要與客戶進行反復地討論，這個過程往往是這樣一個反復循環的過程：需求捕獲->需求整理->需求驗證->再需求捕獲······

(1)需求捕獲:就是我們與客戶在一起開研討會，討論需求的活動,客戶可能會描述他們的業務流程，這時我們在紙上繪制簡單的流程草圖，及時地記錄下來；客戶在描述業務的同時，可能會反復提到一些業務名詞，詳細詢問這些名詞的含義，以及它們與其它名詞的關系，用類圖或者對象圖繪制簡單的草圖；客戶在描述業務的同時，還會提出今後的軟體希望實現的功能，如能夠展示某個報表、能夠導出文件，以需求列表的形式記錄下來。一個功能，在需求列表中會有多個需求，而每個需求應當能夠用 1、2 句話，在 20 個字以內就可以描述清楚 。需求列表是客戶提出的最最原始的需求，他不摻雜任何分析設計，是我們的每項功能必須實現的內容。

(2)需求整理:就是在需求研討會後，需求分析人員對研討內容的分析和整理的過程。首先，需求分析人員應當通過用例模型，劃分整個系統的功能模塊，以及各個模塊的業務流程。用例模型分析是一個由粗到細的過程，這樣一個過程也是符合人類認識世界的思維習慣的一個過程。最先，我們應當對整個系統繪制用例圖，設計用例場景，並依次對這些用例進行用例描述、流程分析、角色分析等分析過程。當然，在整體用例分析的同時，我們還應當進行一個整體的角色分析，繪制一個角色分析圖，進行一個流程分析，繪制一個流程分析圖（可以是傳統的流程圖、UML 中的行動圖，甚至一個簡單的示意圖，等等）,再在整體用例圖的基礎上，依次對每個用例繪制用例圖。每個用例圖中，會更細致地劃分出多個用例，並依次進行用例描述、流程分析、角色分析等分析工作。如此這般地不斷細化，直到我們認為需求已經描述清楚為止。

(3)領域模型 :是對用戶業務領域中相關事物、相互關系、相互行為操作的描述，它是以對象圖和類圖的形式表達的。需求人員對領域模型的分析，對業務理解的深度，對日後軟體的設計，以及軟體的功能擴展、升級演化，都起到了至關重要的作用。

(4)需求驗證:需求驗證工作應當貫穿整個研發周期，並且在不同時期表現出不同的形式。首先，在需求分析階段，需求驗證工作表現為對需求理解是否正確的信息反饋。需求分析人員與客戶再次坐在一起，一項一項描述我們對需求的整理和理解，客戶則時不時地對一些問題進行糾正，或者更加深入地加以描述。我們則認真地記錄，回來整理，並等待下一次的驗證。在需求分析後期，我們還可以製作一些簡單的原型，更加形象地描述我們對需求的理解，會使我們與客戶的溝通更加順暢。隨後的設計開發階段，我

們則應當以迭代開發的形式進行。每開發完一個迭代周期，將開發的成果與客戶反饋。這樣做的結果是，客戶可以及時地提出我們對需求理解的偏差，或者及時提出對我們設計不滿意的地方，使我們存在的問題得到及時地發現與解決。問題及時的解決，使我們修復問題的代價得以降至最小。

6.需求捕獲

經過深入分析我們會發現，從客戶嘴中說出來的需求，只是整個軟體需求中的冰山一角，還有兩類需求需要我們自己去挖掘：客戶嘴中沒有說出來的需求 ，和客戶壓根兒就沒有想到的需求

(1)什麼是客戶嘴中沒有說出來的需求：並不是客戶故意賣弄官子不願說出來，而是在客戶所在業務領域已經約定俗稱，在他們看來已經是天經地義，根本就不用說出來的業務規則。然而 ，作為剛剛涉足該領域的需求人員，他們是不了解這些規則的。如果採用被動的方式去僅僅記錄客戶說出來的需求，毫無疑問會遺失這部分需求，這就是為什麼直到項目後期，軟體被研發出來即將交付使用，客戶才提出說這不是我想要的軟體，並提出大量變更需求的原因。要求我們在需求分析的整個過程，不斷進行業務領域知識的學習。在我做需求訪談的初期，我往往不是跟客戶談需求，而是先跟客戶談業務。你們是怎樣操作的？都經過些什麼流程？誰來完成這些操作的？為什麼這樣操作？注意，在所有這些問題中，最後一個問題是最重要的。客戶業務領域中的所有操作、所有流程都是有它存在的意義的，它體現了其內部的原因與作用。多問為什麼，可以讓我們深入地理解這些領域知識 。站在客戶的視角去思考問題，進而深入地理解客戶為什麼要提出他們的那些業務需求

(2)另一種就是客戶壓根兒沒有想到的需求：在需求分析階段，雖然客戶壓根兒沒有想到，但需求分析人員是軟體研發領域的專業人員，他們應當在深入理解業務領域與需求的基礎上，通過分析提前發現這些需求。作為需求分析人員，他們應當站在客戶的角度去思考，我們的軟體應當設計成什麼樣子，每個需求的真實意圖是什麼。站在這個基礎上，再運用專業知識去整理、分析與設計。我前面談到，客戶描述的最原始的需求是編寫在需求列表中的，而經過需求分析人員的整理、分析與設計，經過用例分析、領域建模，最終形成產品需求說明書（或稱為產品規格說明書）。先在一些非正式的場合單獨跟客戶聊，產生第一手資料，最後將這些需求在比較正式的場合，如各部門參加的業務討論會、有用戶代表參加的

10. 需求分析的主要方法

1.訪談法

從字面意思大家都能了解，就是找人進行面對面交談，了解真實需求。訪談法注意事項：

(1)確定訪談的目標，明確「什麼信息是最有價值的、必須了解到的」。

(2)准備完備的訪談提綱。

(3)建立融洽的、相互信任的訪談氣氛。

3.關鍵事件法

考察工作過程和活動情況以發現潛在的培訓需求，一般考察對象是對組織目標起關鍵性積極作用或消極作用的事件。進行關鍵事件分析時應注意以下兩個方面：

(1)制定保存重大事件記錄的指導原則並建立記錄媒體(如工作日誌、主管筆記等)。

(2)對記錄進行定期分析，找出員工在知識和技能方面的缺陷，以確定培訓需求。