?? 軟件需求.htm
字號:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0050)http://www.itisedu.com/phrase/200603061756235.html -->
<HTML><HEAD><TITLE>軟件需求</TITLE>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.2873" name=GENERATOR></HEAD>
<BODY>
<CENTER>
<H1>軟件需求</H1></CENTER>
<DIV>
<P align=right><FONT face=Verdana><FONT color=#f70938><FONT face=黑體><A
href="http://www.itisedu.com/phrase/200604112229525.html"
target=_new>中科永聯</A>高級技術培訓中心（</FONT><FONT face=黑體>www.itisedu.com</FONT><FONT
face=黑體>）<IMG src="軟件需求.files/200632719853128.jpg" border=0></FONT></FONT></P>
<P><BR> <A
href="http://www.itisedu.com/phrase/200603061756235.html"
target=_new>軟件需求</A>是(1)用戶解決問題或達到目標所需的條件或權能(Capability)。<BR> (2)系統或系統部件要滿足合同、標準、規范或其它正式規定文檔所需具有的條件或權能。<BR> (3)一種反映上面(1)或(2)所描述的條件或權能的文檔說明。<BR> （IEEE<A
href="http://www.itisedu.com/phrase/200602281725525.html"
target=_new>軟件工程</A>標準詞匯表(1997年)中定義）</P>
<P><STRONG>一、<A href="http://www.itisedu.com/phrase/200604232134205.html"
target=_new>軟件</A><A href="http://www.itisedu.com/phrase/200603101518295.html"
target=_new>需求</A>的發展</STRONG></P>
<P> <A
href="http://www.itisedu.com/phrase/200603282310205.html"
target=_new>需求工程</A>是隨著<A
href="http://www.itisedu.com/phrase/200603021438435.html"
target=_new>計算機</A>的發展而發展的，在計算機發展的初期，軟件規模不大，<A
href="http://www.itisedu.com/phrase/200603282233345.html"
target=_new>軟件開發</A>所關注的是代碼編寫，<A
href="http://www.itisedu.com/phrase/200603062220345.html"
target=_new>需求分析</A>很少受到重視。后來軟件開發引入了生命周期的概念，需求分析成為其第一階段。隨著<A
href="http://www.itisedu.com/phrase/200602281706245.html"
target=_new>軟件系統</A>規模的擴大，需求分析與定義在整個軟件開發與維護過程中越來越重要，直接關系到軟件的成功與否。人們逐漸認識到需求分析活動不再僅限于軟件開發的最初階段，它貫穿于系統開發的整個生命周期。80年代中期，形成了軟件工程的子領域——需求工程(requirement
engineering,
RE)。進入90年代以來，需求工程成為研究的熱點之一。從1993年起每兩年舉辦一次需求工程國際研討會(ISRE)，自1994年起每兩年舉辦一次需求工程國際會議(ICRE)，在1996年Springer-Verlag發行了一新的刊物——《Requirements
Engineering》。一些關于需求工程的工作小組也相繼成立，如歐洲的RENOIR(Requirements Engineering Network of
International Cooperating Research Groups )，并開始開展工作。</P>
<P><STRONG>二、軟件需求的層次</STRONG></P>
<P> 下面這些定義是需求工程領域中常見術語的定義說明。</P>
<P> 軟件需求包括三個不同的層次—業務需求、用戶需求和功能需求—也包括非功能需求。業務需求( business
requirement)反映了組織機構或客戶對系統、產品高層次的目標要求，它們在項目<A
href="http://www.itisedu.com/phrase/200603141659315.html"
target=_new>視圖</A>與范圍文檔中予以說明。用戶需求(user requirement)
文檔描述了用戶使用產品必須要完成的任務，這在使用實例(<A
href="http://www.itisedu.com/phrase/200603042249305.html" target=_new>use
case</A>)文檔或方案腳本(scenario)說明中予以說明。功能需求(functional
requirement)定義了開發人員必須實現的軟件功能，使得用戶能完成他們的任務，從而滿足了業務需求。所謂特性(feature)是指邏輯上相關的功能需求的集合，給用戶提供處理能力并滿足業務需求。軟件需求各組成部分之間的關系如圖所示。</P>
<P> 作為補充，軟件需求規格說明還應包括非功能需求，它描述了系統展現給用戶的行為和執行的操作等。它包括產品必須遵從的標準、規范和合約；外部界面的具體細節；性能要求；設計或實現的約束條件及質量屬性。所謂約束是指對開發人員在軟件產品設計和構造上的限制。質量屬性是通過多種角度對產品的特點進行描述，從而反映產品功能。多角度描述產品對用戶和開發人員都極為重要。
值得注意的一點是，需求并未包括設計細節、實現細節、項目計劃信息或測試信息。需求與這些沒有關系，它關注的是充分說明你究竟想開發什么。</P>
<P> Frederick Brooks在他1987年的經典的文章“No Silver Bullet：Essence and Accidents of<A
href="http://www.itisedu.com/phrase/200604240910235.html" target=_new>Software
Engineering</A> ”中充分說明了需求過程在軟件項目中扮演的重要角色：</P>
<P> 開發軟件系統最為困難的部分就是準確說明開發什么。最為困難的概念性工作便是編寫出詳細技術需求，這包括所有面向用戶、面向機器和其它軟件系統的接口。同時這也是一旦做錯，將最終會給系統帶來極大損害的部分，并且以后再對它進行修改也極為困難。</P>
<P> 為什么這么說呢，因為在大多數的軟件系統中，最終用戶可能都不清楚他的需求是什么，這是千真萬確的。如果你的用戶告訴你需求就是這些了，不要相信他，繼續刨根問底，直到你們都筋疲力盡了。</P>
<P> 雖然聽上去有些不可思議，但這是教訓之談，在我從事的項目之中，沒有一個用戶在軟件接近完成的時候打電話對我說，我看了你們的軟件，我想我必須改動一些地方。在那些日子中，我甚至得了一種電話鈴音恐懼癥。</P>
<P><STRONG>三、需求風險</STRONG></P>
<P> 下面列出了在做需求分析時一些很危險的做法，如果你發現你的一些做法與之相似，那么，給自己一些時間，好好思考一下，這些做法會對你的軟件產生致命的影響。</P>
<P><STRONG> 1. 無足夠用戶參與</STRONG></P>
<P> 客戶經常不明白為什么收集需求和確保需求質量需花費那么多功夫，開發人員可能也不重視用戶的參與。究其原因：一是因為與用戶合作不如編寫代碼有意思；二是因為開發人員覺得已經明白用戶的需求了。在某些情況下，與實際使用產品的用戶直接接觸很困難，而客戶也不太明白自己的真正需求。但還是應讓具有代表性的用戶在項目早期直接參與到開發隊伍中，并一同經歷整個開發過程。
最重要的就是用戶必須要重視他的軟件，必須讓他明白：如果失敗，他的損失最大(當然你的損失也不小，但這時候你必須讓他重視這項工作)。如果用戶不夠重視，想辦法解決，否則你就不用再繼續了。</P>
<P><STRONG> 2. 用戶需求的不斷增加</STRONG></P>
<P> 在開發中若不斷地補充需求，項目就越變越龐大以致超過其計劃及預算范圍。這使得問題更難解決。實際上，問題根源在于用戶需求的改變和開發者對新需求所作的修改。要想把需求變更范圍控制到最小，必須一開始就對項目視圖、范圍、目標、約束限制和成功標準給予明確說明，并將此說明作為評價需求變更和新特性的參照<A
href="http://www.itisedu.com/phrase/200603061723295.html"
target=_new>框架</A>。說明中包括了對每種變更<A
href="http://www.itisedu.com/phrase/200604161444295.html"
target=_new>進行變更</A>影響因素分析的變更控制過程，有助于所有<A
href="http://www.itisedu.com/phrase/200604240830255.html"
target=_new>風險承擔者</A>明白業務決策的合理性，即為何進行某些變更，相應消耗的時間、資源或特性上的折中。</P>
<P> 產品開發中不斷延續的變更會使其整體結構日漸紊亂，補丁代碼也使得整個<A
href="http://www.itisedu.com/phrase/200604232224305.html"
target=_new>程序</A>難以理解和維護。插入補丁代碼使模塊違背強內聚、松耦合的設計原則，特別是如果項目<A
href="http://www.itisedu.com/phrase/200602271137552.html"
target=_new>配置管理</A>工作不完善的話，收回變更和刪除特性會帶來問題。如果你盡早地區別這些可能帶來變更的特性，你就能開發一個更為健壯的結構，并能更好地適應它。這樣設計階段需求變更不會直接導致補丁代碼，同時也有利于減少因變更導致質量的下降。</P>
<P> 最糟糕的莫過于用戶覺得如果不再加點什么功能就對不起自己。我曾經看過一個<A
href="http://www.itisedu.com/phrase/200603091358275.html"
target=_new>數據倉庫</A>的一期工程，在設計階段沒有很好的定義范圍，當我向<A
href="http://www.itisedu.com/phrase/200604240825565.html"
target=_new>項目管理</A>者提出這個問題的時候，他認為都已經說好了，合同上也寫清楚了，并沒有加以重視。可是最后，用戶提出的修改意見已經遠遠超出了范圍，項目時間也延長了一倍。整個的項目組成員疲憊不堪，可是卻不斷的接到用戶投訴說項目失敗。</P>
<P><STRONG> 3. 模棱兩可的需求</STRONG></P>
<P> 模棱兩可是需求規格說明中最為可怕的問題(Lawrence
1996)。它的一層含義是指諸多讀者對需求說明產生了不同的理解；另一層含義是指單個讀者能用不止一個方式來解釋某個需求說明。</P>
<P> 模棱兩可的需求會使不同的風險承擔者產生不同的期望，它會使開發人員為錯誤問題而浪費時間，并且使測試者與開發者所期望的不一致。一位<A
href="http://www.itisedu.com/phrase/200603111950135.html"
target=_new>系統測試</A>人員曾告訴我，她所在的測試組經常對需求理解有誤，以致不得不重寫許多<A
href="http://www.itisedu.com/phrase/200603291707535.html"
target=_new>測試用例</A>并重做許多測試。</P>
<P> 模棱兩可的需求帶來不可避免的后果便是返工—重做一些你認為已做好的事情。返工會耗費開發總費用的40%，而70%～85%的重做是由于需求方面的錯誤所導致的(leffingwell
1997)。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發出產品，在同樣的時間內開發更多、更好的產品，甚至能偶爾回家休息休息。</P>
<P> 處理模棱兩可需求的一種方法是組織好負責從不同角度審查需求的隊伍。僅僅簡單瀏覽一下需求文檔是不能解決模棱兩可問題的。如果不同的評審者從不同的角度對需求說明給予解釋，但每個評審人員都真正了解需求文檔，這樣二義性就不會直到項目后期才被發現，那時再發現的話會使得更正代價很大。</P>
<P><STRONG> 4. 不必要的特性</STRONG></P>
<P> “畫蛇添足”是指開發人員力圖增加一些“用戶欣賞”但需求規格說明中并未涉及的新功能。經常發生的情況是用戶并不認為這些功能性很有用，以致在其上耗費的努力“白搭”了。</P>
<P> 開發人員應當為客戶構思方案并為他們提供一些具有創新意識的思路，具體提供哪些功能要在客戶所需與開發人員在允許時限內的技術可行性之間求得平衡，開發人員應努力使功能簡單易用，而不要未經客戶同意，擅自脫離客戶要求，自作主張。</P>
<P> 同樣，客戶有時也可能要求一些看上去很“酷”，但缺乏實用價值的功能，而實現這些功能只能徒耗時間和成本。為了將“畫蛇添足”的危害盡量減小，應確信：你明白為什么要包括這些功能，以及這些功能的“來龍去脈”，這樣使得需求分析過程始終是注重那些能使用戶完成他們業務任務的核心功能。</P>
<P> 時刻記住：軟件成功的標準是是否解決用戶的問題，而不是它有多Cool的功能。</P>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -