前言：本站為你精心整理了項目視圖建立管理范文，希望能為你的創作提供參考價值，我們的客服老師可以幫助你提供個性化的參考范文，歡迎咨詢。

同事karen已經在她的公司里成功地引入軟件需求文檔的正式評審。她已經注意到在評審會議上所提出的許多問題都與項目所設定的范圍有關。參與評審的的專家經常難以理解項目所設定的范圍，并且在項目的最終目標上所持的看法各不相同。因此，他們發現在哪一個功能需求應該列入軟件需求規格說明的問題上很難達成一致的意見。正如我們在第1章所敘述的那樣，業務需求代表了需求鏈中最高層的抽象：他們為軟件系統定義了項目視圖（vision）和范圍（scope）。軟件功能需求必須根據用戶的需求來考慮，且要與業務需求所設定的目標相一致。對不利于實現項目業務目標的需求應該排除在外。一個項目可能包括一些與軟件沒有直接關系的需求，例如：硬件的購買、產品的安裝、維護或廣告。但在此，我們只關心與軟件產品有關系的業務需求。

如果一個項目缺乏明確的規劃和良好的信息交流途徑，那將是十分糟糕的。如果項目的參與者持有不同的目標和優先權，那么他們只能各抒己見，無心工作。如果項目的風險承擔者在產品所能滿足的業務需要和產品所能提供的利益問題上不能達成一致的意見，那么需求決不會穩定。一個清晰的項目視圖和范圍過于分散在多個地方開發，在這樣的項目中，地理位置上的分離使項目開發組成員必須天天進行相互溝通才能保證他們之間能進行更有效的合作。業務需求中某些特性最初被列入規格說明，而后又被刪除，最后又加入，則說明此業務需求未完全定義好。在確定詳細的功能需求之前，必須很好地解決項目的視圖和范圍問題。對范圍和局限性的明確說明將在很大程度上有助于對所建議特性的探討和最終產品的發行。一個明確定義了項目視圖和范圍的文檔也可以為所建議的需求變更的決策提供參考。

通過業務需求確定項目視圖

項目視圖可以把項目參與者定位到一個共同和明確的方向上。項目視圖描述了產品所涉及的各個方面和在一個完美環境中最終所具有的功能。相反的，范圍描述了產品應包括的部分和不應包括的部分。范圍的說明在包括與不包括之間劃清了界線，當然，它還確定了項目的局限性。項目的業務需求在視圖上和范圍上形成文檔，這些必須在創建項目之前起草。開發商業軟件的公司經常編寫市場需求文檔，其實這種文檔也是為了類似的目的，但這種文檔較為詳細地涉及關于目標市場部分的內容，這是為適應商業的需要。視圖和范圍的文檔為項目的主辦者或具有同等地位的人所擁有。業務需求是從各個不同的人那里收集來的，這些人對于為什么要從事該項目和該項目最終能為業務和客戶提供哪些價值有較清楚的了解。它們包括主辦者(sponsor)、客戶、開發公司的高級管理人員及項目的幻想者(visionary)，例如產品的代表和市場部門人員。

來自各個渠道的業務需求可能會發生沖突。比如，考慮具有嵌入軟件的售貨亭管理系統，

它將賣給零售店并由零售客戶使用。售貨亭管理系統的開發者有如下的業務目標：

•向零售商發行并銷售售貨亭產品。

•通過售貨亭軟件向客戶銷售消費品。

•吸引客戶對商品的興趣。

•改變原有的開發者—客戶的關系。

零售亭業務對如下方面感興趣：

•通過客戶使用售貨亭軟件而獲利。

•吸引更多的客戶來商店購買。

•如果售貨亭軟件替代了人工操作，就可節省錢。

開發者可能要為客戶建立高科技系統，并且引導客戶緊跟新的發展方向。而零售商則需要一個簡易、方便使用的系統，客戶需要便利和良好的性能。這三者在目標、限制和費用因素上的不同將導致業務需求的沖突，這必須在售貨亭管理系統的軟件需求說明制訂之前予以解決。也可以利用業務需求對使用實例及與它們相關的功能需求設置實現優先級。例如，業務需求的確定可以從售貨亭軟件產生最大收益考慮，這意味著軟件性能的最初實現是與銷售更多的產品或對客戶服務有直接關系，而不是去強調只吸引少量客戶的軟件性能。業務需求不僅決定了應用程序所能實現的業務任務（使用實例）的設置（所謂的應用寬度），還決定了對使用實例所支持的等級和深度。支持的深度可以從一個很小的實現細節到具有許多輔助功能的完全自動化的操作。對于每個使用實例都必須決定其寬度和深度，并編寫出文檔。如果業務需求幫助你確定一個在應用范圍之外特殊的使用實例，那么此時，你正在確定產品的應用寬度。業務需求還可以幫助你確定哪一個使用實例需要健壯的、綜合的功能實現，哪一個僅需要一般實現，至少需要初始實現。

項目視圖和范圍的文檔

項目視圖和范圍的文檔（visionandscopedocument）把業務需求集中在一個簡單、緊湊的文檔里，這個文檔為以后的開發工作奠定了基礎。項目視圖和范圍文檔包括了業務機遇的描述、項目的視圖和目標、產品適用范圍和局限性的陳述、客戶的特點、項目優先級別和項目成功因素的描述。這必須是一個相對簡短的文檔，也許只有3～8頁紙，這取決于項目的性質和大小。

圖6-1描述了一個對項目視圖和范圍文檔的推薦模板，文檔模板對公司項目所創建的文檔結構進行了標準化。就像其它模板一樣，必須對圖6-1所示的模板圖進行改寫來滿足你項目的需要。

下面介紹這個模板的每一個部分。

a.業務需求

業務需求說明了提供給客戶和產品開發商的新系統的最初利益。不同的產品，例如信息管理系統，商業軟件包，系統捆綁軟件將有不同的側重點。然而，項目開發的投入是由于人們堅信：有了新產品，世界將變得更加美好。本部分描述了你為什么要從事此項項目的開發，以及它將給開發者和購買者帶來的利益。

a.1背景

在這一部分，總結新產品的理論基礎，并提供關于產品開發的歷史背景或形勢的一般性描述。

a.2業務機遇

描述現存的市場機遇或正在解決的業務問題。描述商品競爭的市場和信息系統將運用的環境。包括對現存產品的一個簡要的相對評價和解決方案，并指出所建議的產品為什么具有吸引力和它們所能帶來的競爭優勢。認識到目前只能使用該產品才能解決的一些問題，并描述產品是怎樣順應市場趨勢和戰略目標的。

a.3業務目標

用一個定量和可測量的合理方法總結產品所帶來的重要商業利潤。關于給客戶帶來的價值在本模板a.5的項目視圖和范圍文檔中闡述，這里僅把重點放在給業務的價值上。這些目標與收入預算或節省開支有關，并影響到投資分析和最終產品的交付日期。如果這些信息在其它地方已敘述，就請參考有關文檔，在此就不再重復了。

a.4客戶或市場需求

描述一些典型客戶的需求，包括不滿足現有市場上的產品或信息系統的需求。提出客戶目前所遇到的問題在新產品中將可能（或不可能）出現的闡述，提供客戶怎樣使用產品的例子。確定了產品所能運行的軟、硬件平臺。定義了較高層次的關鍵接口或性能要求，但避免設計或實現細節。把這些要求寫在列表中，可以反過來跟蹤調查特殊用戶和功能需求。

a.5提供給客戶的價值

確定產品給客戶帶來的價值，并指明產品怎樣滿足客戶的需要。可以用下列言辭表達產品帶給客戶的價值：

•提高生產效率，減少返工。

•節省開支。

•業務過程的流水線化。

•先前人工勞動的自動化。

•符合相關標準和規則。

•與目前的應用產品相比較，提高了可用性或減少了失效程度。

a.6業務風險

總結開發（或不開發）該產品有關的主要業務風險，例如市場競爭、時間問題、用戶的接受能力、實現的問題或對業務可能帶來的消極影響。預測風險的嚴重性，指明你所能采取的減輕風險的措施。

b.項目視圖的解決方案

文檔中的這一部分為系統建立了一個長遠的項目視圖，它將指明業務目標。這一項目視圖為在軟件開發生存期中作出決策提供了相關環境背景。這部分不應包括詳細的功能需求和項目計劃信息。

b.1項目視圖陳述

編寫一個總結長遠目標和有關開發新產品目的的簡要項目視圖陳述。項目視圖陳述將考慮權衡有不同需求客戶的看法。它可能有點理想化，但必須以現有的或所期待的客戶市場、企業框架、組織的戰略方向和資源局限性為基礎。這里是曾在前面章節討論過的“化學制品跟蹤系統”的簡單項目視圖陳述的一個實例。

“化學制品跟蹤系統”可使科學家查詢到化學制品倉庫或供應商將提供的化學制品容器。系統可隨時了解公司中每一個化學制品容器所處的位置，容器中所剩余的藥品劑量，任何時候每個容器所處的位置和用法的歷史記錄。通過充分利用公司內部的可用化學制品，廢棄極少量已使用或過期失效的化學制品，使用標準的化學制品的購買過程等將在化學制品上節省25%開支。“化學制品跟蹤系統”還能產生符合政府部門規定所要求的全部報表，包括化學制品的使用、存儲和廢棄等報表。

b.2主要特性

包括新產品將提供的主要特性和用戶性能的列表。強調的是區別于以往產品和競爭產品的特性。可以從用戶需求和功能需求中得到這些特性。

b.3假設和依賴環境

在構思項目和編寫項目視圖和范圍文檔時，要記錄所作出的任何假設。通常一方所持的假設應與另一方不同。如果你把它們都記錄下來，并加以評論，就能對項目內部隱含的基本假設達成共識。比如，“化學制品跟蹤系統”的開發者假設：該系統可以替代現有的倉庫存貨系統，并能與有關采購部門的應用相連接。把這些都記錄下來以防止將來可能的混淆和沖突。還有，記錄項目所依賴的主要環境，比如：所使用的特殊的技術、第三方供應商、開發伙伴或其它業務關系。

c.范圍和局限性

當一個化學家發明了可以把一種化學制品轉變為另一種化學制品的新的化學變化時，它所發表的論文中包含了“范圍和局限性”部分，這一部分描述了這一化學變化所能作和不能作的一種限定。類似地，一個軟件項目也必須定義它的范圍和局限性，并作為業務需求的一部分。項目范圍定義了所提出的解決方案的概念和適用領域，而局限性則指出產品所不包括的某些性能。澄清范圍和局限性這兩個概念有助于建立各風險承擔者所企盼的目標。有時客戶所要求的性能太奢華或者與產品所制定的范圍不一致。一般客戶所提出的需求超出項目的范圍時就應當拒絕它，除非這些需求是很有益的。這時，可適當擴大項目范圍來適應這些需求（在預算、計劃、人員方面也要相應進行變化）。記錄這些需求以及拒絕它們的原因，以備日后重新遇到時，有記錄可查。

c.1首次發行的范圍

總結首次發行的產品所具有的性能。描述了產品的質量特性，這些特性使產品可以為不同的客戶群（customercommunity）提供預期的成果。如果你的目標集中在開發成果和維持一個可行的項目規劃上，應當避免一種傾向，那就是把一些潛在的客戶所能想到的每一特性都包括到1.0版本的產品中。這一傾向所帶來的普遍惡果是產生軟件規劃的動蕩性和錯誤性。開發者應把重點放在能提供最大價值、花費最合理的開發費用及普及率最高的產品上。例如，我的同事scott的上一個項目開發小組決定，用戶可以用首發版的軟件進行包裹傳遞業務。1.0版本并不要求快速、結構緊湊或易于使用，但該軟件必須穩定運行；整個開發小組始終以這一目標為準。首發版的軟件完成了基本的系統目標，而隨后的版本則包含了附加的特性、選項和使用幫助。

c.2隨后發行的范圍

如果你想象一個周期性的產品演變過程，就要指明哪一個主要特性的開發將被延期，并期待隨后版本發行的日期。

c.3局限性和專用性

明確定義包括和不包括的特性和功能的界線是處理范圍設定和客戶期望的一個途徑。列出風險承擔者們期望的而你卻不打算把它包括到產品中的特性和功能。

d.業務環境

這一部分總結了一些項目的業務問題，包括主要的客戶分類概述和項目的管理優先級。

d.1客戶概貌

客戶概述明確了這一產品的不同類型客戶的一些本質的特點，以及目標市場部門和在這些部門中的不同客戶的特征。對于每一種客戶類型，概述要包括以下信息：

•各種客戶類型將從產品中獲得的主要益處。

•它們對產品所持的態度。

•感興趣的關鍵產品的特性。

•哪一類型客戶能成功使用。

•必須適應任何客戶的限制。

d.2項目的優先級

一旦明確建立項目的優先級，風險承擔者和項目的參與者就能把精力集中在一系列共同的目標上。達到這一目的的一個途徑是考慮軟件項目的五個方面：性能、質量、計劃、成本和人員（wiegers1996a）。在所給的項目中，其每一方面應與下面三個因素之一相適應。

•一個驅動（driver）—一個最高級別的目標。

•一個約束（constraint）—項目管理者必須操縱一個對象的限制因素。

•一個自由度（degreeoffreedom）—項目管理者能權衡其它方面，進而在約束限制的

范圍內完成目標的一個因素。未必所有的因素都能成為驅動，或所有的因素都能成為約束因素。在項目開始時記錄和分析哪一個因素適用于哪一類型，將有助于使每一個人的努力和期望與普遍認可的優先級相一致。

e.產品成功的因素

明確產品的成功是如何定義和測量的，并指明對產品的成功有巨大影響的幾個因素。不僅要包括組織直接控制的范圍內的事務，還要包括外部因素。如果可能，可建立測量的標準，用于評價是否達到業務目標，這些標準的實例有：市場股票、銷售量或收入、客戶滿意程度的測量、交易處理量和準確度。

3關聯圖

軟件項目范圍的描述為我們正在開發的系統和宇宙萬物之間劃清了界線。關聯圖(context

diagram)通過正在開發的系統或正在討論的問題和外部世界之間的聯系來描述這一界線。關聯圖確定了通過某一接口與系統相連的外部實體（稱為“端點”或“外部實體”），同時也確定

了外部實體和系統之間的數據流和物流。我們把關聯圖作為按照結構化分析所形成的數據流

圖的最高抽象層（robertsonandrobertson1994）。可以把關聯圖寫入項目視圖和范圍文檔或軟件需求規格說明中，或者作為系統數據流模型的一部分。“化學制品跟蹤系統”的簡單的關聯圖如圖6-2所示。整個系統被描述成一個簡單的循環，所以關聯圖并不明確提供系統的內部過程和數據。關聯圖中的流可以用信息（“化學制品請求”）或物理項（“化學制品容器”）來表示。以矩形圖示的端點可以表示用戶類(“藥劑師”)、組織（“采購部門”）或其它計算機系統（“培訓用數據庫”）。

你可能希望把化學制品的供應商作為一個端點放入關聯圖中。別忘了，公司總是發購買化學制品的訂單給化學制品供應商，并從供應商那里得到裝有化學制品的容器和發票，而供應商則得到支票。然而，這些過程發生在“化學制品跟蹤系統”范圍之外，并作為購買和進貨部門日常事務的一部分。關聯圖明確告訴我們，系統并不直接與供應商訂貨、進貨、或付賬。雖然某些端點與所規劃的系統沒有直接聯系，但有時關聯圖將給出與項目的問題域有關的端點之間的聯系（jackson1995）。不是教條地去追求如何繪制“正確”的關聯圖，而是使用這樣的圖來確定項目風險承擔者之間清晰而精確的關系。

4把注意力始終集中在項目的范圍上

在項目視圖和范圍文檔中記錄業務需求為防止開發過程范圍的擴展(creep)提供了有利的手段。項目視圖和范圍文檔可以使你判斷所提出的特性和需求放進項目是否合適。當某些人提出新的需求或改變需求或特性時，你必須問的第一個問題是：“這是否包含在項目范圍之內？”所提出的一些建議有時完全在項目范圍之外。它們可能是一個好的方案，但這個方案適用于其它項目或將來要發行的產品。另外一些建議很明顯是在項目范圍定義之內。如果這種建議與已經為某一確定產品所制定的需求相比，具有更高的優先級，則這些新的并符合要求的需求就可以加入到項目中。不過此時你必須作出權衡（tradeoff），決定是延遲還是取消其它已經確定的需求或特性。

第三種可能性是“所提出的新需求在項目范圍之外，但這是一個很有價值的方案，此時可以改變項目的范圍來適應這一需求。但要求你要修改項目視圖和范圍文檔。當改變項目的范圍時，你必須重新商議計劃預算、資源及進度安排，也許還有開發人員（特別是在需要新的技術和技巧時）。理想的情況是原先的安排和資源能合理地適應需求變更。然而，你必須在需求變更得到贊同后才重新進行計劃安排，除非你原先對需求的預算留有余地。范圍擴展存在固有的兩個主要問題：1)全部的工作必須重新進行以適應變化。2)當項目的范圍增大時，如果沒有調整原先所分配的資源和時間，則屬性會遭到破壞。一組確定的業務需求可以使項目依照計劃正常進行，在市場或業務需要變更時可以合理地調整項目范圍的大小；當一些有影響的人企圖往有許多約束的項目中添加更多的特性時，可以合理地拒絕這

些要求。