<P>●明確需求并達成共識； <BR>●建立關聯； <BR>●根據不同需求設計相應解決辦法； <BR>●進行系統優化； <BR>●提出設計方案； <BR>●監控和解決可能出現的問題以及需要做出的改變； <BR>●控制不同開發任務的開展； <BR>●對最終產品做出評測； <BR>●監控可能出現的重復開發； <BR>●提出項目實施時間表； <BR>●確定最終用戶界面。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 有時侯我們所進行的需求分析只停留于分析本身，而沒有進一步去思索我們為什么要進行需求分析。需求性是項目開發的源頭，只有進行認真的需求分析，我們才能做到對癥下藥、量體裁衣，才能才設計開發中去偽存真，不斷改進。"需求之需求"正是強調了貫穿始終的需求分析的重要。離開了能動的、變化的系統進程而空談需求管理，無異于紙上談兵。需求管理所產生的效益或許并不明顯，或許要日后才能體現，但是無序的，沒有經過精心策劃的需求管理是不可能產生效益的。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 以下篇幅分別介紹需求管理在系統工程中的不同應用。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 需求共識： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 首先，用戶需求通過非術語的形式進行表述，這種表述應當使每一位開發者明確自己的職責所在，并且清楚知道不同開發工作之間的關聯。這里的"用戶"泛指在實際應用環境中每一位可能使用最終產品的人。如果一個產品不能滿足客戶所需，那么設計方案再出色也無濟于事，許多方案有很高的技術設計水準卻最終不能獲得成功，其原因正在于此。可以把產品功能說得天花亂墜，但卻無法改變用戶需求決定最終產品基本模式的事實。 </P>
<P align=center><IMG src="200632983721280.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200632983721280.jpg" border=0></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 需求管理的首要任務在于使開發人員和用戶雙方對于需求都有一個明確的認識。因此用來進行需求分析的語言組織應當使所有相關人員，包括用戶，都能夠理解，都能夠進而對整個項目有一個整體把握，并明確每一個人在項目中所起的作用。因而需求管理需要解決的第一位也是最基本的任務就是明確需求，并使所有相關人員達成共識。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 根據需求設計解決辦法： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 我們在進行系統設計時，應當首先建立一個需求模型，但不能是為了建模而建模，需求模型實際是最終產品的抽象化表現。需求模型的建立使我們在明確需求的基礎上更進一步，使我們知道我們將要生產何種產品，該產品都具有那些功能。同時，創建需求模型的過程也使開發者明確自己的工作如何同整個項目有機地結合在一起。建立需求模型應當充分研究不同類型、不同<a href="200604241328115.html" tppabs="http://www.itisedu.com/phrase/200604241328115.html" target="_new">架構</a>建模方式的可行性，切忌主觀武斷。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 系統優化： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 任何設計都應以考慮用戶需求為優先，用戶需求的滿足程度即成為衡量設計優劣的標準。在一個項目設計周期中，開發人員經常會面臨選擇，以提煉需求，決定開發的優先次序，并在不同的實施方案中作出選擇。這些選擇必須考慮到收益與付出地平衡比例，這種選擇的重要性尤其在建立需求模型的后期凸現出來。基本需求在這時都已明確，而實施方案還未敲定，為了使用戶的基本需求得到落實，一定程度的開銷用于搭建不同構架的需求模式是合理的。假使我們已經有了一套翔實的需求分析，我們甚至不必將每一套方案都付諸實行，就可以成功地對系統設計進行優化。</P>
<P align=center><IMG src="200632983736944.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200632983736944.jpg" border=0></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 面對不同的可行性而需要作出選擇時，我們也必須參照收益與付出的比例關系。例如，在被要求提供計劃書時（Request for Proposal），我們應當盡量做到每一份計劃書的提供都物有所值。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 方案設計： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 明確需求后，開發人員就可以進行方案設計。通過對用戶需求和設計方案之間所存在關聯性進行分析比較，我們就能夠對設計方案進行評估。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 必要的修改： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 方案的設計不可能是一成不變的，經常會有方案設計同需求相悖的情況。如果我們無法準確把握用戶需求同方案設計之間的關系，我們就無法在需要對方案進行必要修改時正確判斷。優秀的需求分析應當非常精確細致地對用戶需求作出描述，同時也應該最大程度地給予方案設計者充分發揮的余地。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 任務劃分： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 一個大的開發項目可能涉及20-30組不同的開發隊伍，人員包括技術工程師、<a href="200602281725525.html" tppabs="http://www.itisedu.com/phrase/200602281725525.html" target="_new">軟件工程</a>師以及具體項目主管等等，而每一個模塊都有它自己的開發工具和開發語言。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 主持一個大項目的開發并不是件容易的事，總體項目主管的首要任務是對開發項目進行任務劃分，將整體開發任務細化為多個子模塊，從而使這些子模塊能夠平行開發而無需太多的干預。總體項目主管可以將細化的不同模塊的需求分析交給不同的開發隊伍，對于開發進程的監控只需參照需求的解決情況，對于具體的開發細節則不必過問太多。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 不同的開發隊伍會使用不同的開發語言和開發工具，會使用不同的符號和標記。相反，作為總體項目主管所使用的語言、符號和標記等則必須簡單易懂，以使所有的開發人員都等理解。換言之，總體項目主管應當使用自然語言，或只涉及少量的，簡單的術語和專用詞匯。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 產品測試： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 需求的滿足情況是決定最終產品成敗的判定基礎，對最終產品的測試評估必須以產品所試圖解決的需求為標準。下圖標示了不同的開發階段所對應的測試需求。</P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 這里有一個需求、產品和測試系統之間的關系問題，確定需要進行的測試屬于總體開發主管的工作范疇，雖然具體工作并非都要由開發主管來親自完成。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 重復開發： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 對于總體開發主管而言，針對方案設計的修改是一項經常性的工作（因為修改而造成的影響則應當盡可能減小）。在進行項目開發時，隨著開發進程的深入，各種修改的建議和問題的報告是屢見不鮮的，每解決一個問題，就是將產品同其需求性的結合又完善了一步。存在問題正是需求性尚未滿足的表現。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 方案設計的完善和需求性的滿足是同步的，因此真正的用戶對于產品的評價和建議尤其具有重要意義。在那些一步到位的產品設計中，真正用戶無法左右開發進程；但在一個能夠進行重復設計、重復開發的產品生命期中，開發人員應當及時搜集用戶對于產品的反饋信息，并將這些信息結合到下一步的開發工作中去。如下圖所示，用戶反饋同產品開發是統一的。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <a href="200604240825565.html" tppabs="http://www.itisedu.com/phrase/200604240825565.html" target="_new">項目管理</a>的輔助： </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 在有些地方，需求管理被作為一個技術問題來處理，需求管理所針對的<a href="200603090845215.html" tppabs="http://www.itisedu.com/phrase/200603090845215.html" target="_new">對象</a>只是產品，而同項目管理所涉及的問題例如進程安排或資源分配等無關。實際上，項目管理涉及三方面問題：進程安排、資源分配和質量管理（同需求的統一）。</P>
<P align=center><IMG src="200632983832682.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200632983832682.jpg" border=0></P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 試想以下三種情況： </P>
<P>●一場高水準的音樂會，預算合理，演出時間卻晚了兩天。 <BR>●質量優良的小轎車，交貨及時，然而造價是市價的兩倍。 <BR>●一套系統，完全滿足了用戶需求，但在開發過程中使用非法勞工。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 這三種情況雖然都滿足了用戶所需，然而缺乏實際意義，因此都以失敗告終。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "我付了錢，但這不是我想要的"，沒有用戶愿意這么說。要避免出現這種情況，在進行項目管理和財務預算時，也必須以需求管理為基礎。僅僅完成了一件設計并不意味著工作的結束，只有這件設計充分解決了需求，它才具有里程碑般的意義。同樣的，一件產品只有在測試和實際操作中完全滿足了需求，已經完全準備好了投入到下一階段的運營，才意味著這件產品在本階段工作的結束。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 開發進程中的每一塊里程碑都意味著需求的解決又前進了一步，這樣的每一塊里程碑也都是委托商付款的重要參照，產品開發的整個進程都可以通過需求管理進行監控。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 里程碑構造機制的基本方法之一就是進程管理，一項需求的滿足就意味著一塊里程碑的確立。我們應當對用戶需求、針對需求而進行的模塊設計以及每個子模塊的開發進程之間的關聯做到心中有數。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 通過我們對需求管理實際應用的分析，幾個關鍵因素凸現出來。首先，需求管理在開發周期中是自始至終存在的。注意：不要把它簡單理解為"需求周期"，需求管理必須始終保持更新，它構成了技術管理的基礎。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 其次，需求管理同項目管理是密不可分的。如果我們把每一個需求的解決看作一個里程碑，并以此出發對整個開發進程進行監控，我們就應該對整體開發工作進行精密細致的劃分，從而將需求分析具體化。 </P>
<P><STRONG>八、需求管理的工具</STRONG> </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 需求管理所用到的工具必須能夠處理和應用于本文所提到的各種需求，應當有助于我們分析需求，確定相應開發和支持工具以處理相關信息，進而處理系統相應模塊。系統工程師始終致力于用簡單的工具將需求形象化的展現出來，常用的工具比如附有標注說明的系統發布工具以及相關數據庫等。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 需求管理涉及到一系列復雜的對象，其任務面向很廣，關系到整個設計開發的方方面面。其使用的工具應當提供如圖列舉的一些功能：</P>
<P align=center><IMG src="200632983856858.jpg" tppabs="http://www.itisedu.com/manage/Upload/image/200632983856858.jpg" border=0></P>
<P><BR><STRONG>九、總結：需求管理</STRONG> </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 本文論述圍繞于需求管理工程。需求管理是開發工作有效進行的確證。很明顯需求管理是一種很高層次的系統行為，涉及整個開發過程和產品本身。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 需求管理首先要針對需求做出分析，隨后應用于產品并提出方案。需求分析的模型正是產品的原型樣本，優秀的需求管理提高了這樣的可能性：它使最終產品更接近于解決需求，提高了用戶對產品的滿意度，從而使產品成為真正優質合格的產品。從這層意義上說，需求管理是產品質量的基礎。</FONT>&nbsp;</P>
<P><BR></FONT>&nbsp;</P></div>
</body>
</html>