?? 200603282323585.html
字號:
<TD class=hui vAlign=top><B>需求承諾</B><BR>XXX項目需求文檔_《XXX需求說明書》，版本號：X.X.X,是建立在XXX與XXX雙方共同對需求理解的基礎之上，同意后續的開發工作根據該工作產品開展。如果需求發生變化，雙方將共同遵循項目定義的“變更控制規程”執行。需求的變更將導致雙方重新協商成本、資源和進度等。<BR>甲方簽字<BR>乙方簽字</TD></TR></TBODY></TABLE></P>
<P></B><FONT face=Verdana> 不少人會草率地對待需求承諾：不就是在一張紙的最后一行文字下面簽字嗎，反正已經評審過了，我就簽吧。但他將來變更需求時可能會表示不瞞：“不錯，我是簽字了，但是我并沒有閱讀文檔。是你們要我在文檔上簽字的，我是相信你們才這么做的。”為了避免發生此類糾紛，人們在作出承諾之前務必要認真閱讀文檔，一定要明白簽字意味著什么。</FONT></P>
<P><FONT face=Verdana>需求跟蹤(Requirement Track)</FONT></P>
<P><FONT face=Verdana> 為什么要進行需求跟蹤？在整個開發過程中，進行需求跟蹤的目的是為了建立和維護從用戶需求開始到測試之間的一致性與完整性。確保所有的實現是以用戶需求為基礎。對于需求實現是否全部的覆蓋。同時確保所有的輸出與用戶需求的符合性。</FONT></P>
<P><FONT face=Verdana> 需求跟蹤有兩種方式，正向跟蹤與逆向跟蹤：</FONT></P>
<P><FONT face=Verdana> 正向跟蹤：以用戶需求為切入點，檢查《用戶需求說明書》或《需求規格說明書》中的每個需求是否都能在后繼工作產品中找到對應點。<BR> 逆向跟蹤：檢查設計文檔、代碼、<a href="200603291707535.html" tppabs="http://www.itisedu.com/phrase/200603291707535.html" target="_new">測試用例</a>等工作產品是否都能在《需求規格說明書》中找到出處。<BR>正向跟蹤和逆向跟蹤合稱為“雙向跟蹤”。不論采用何種跟蹤方式，都要建立與維護《需求跟蹤矩陣》。需求跟蹤矩陣保存了需求與后續開發過程輸出的對應關系。矩陣單元之間可能存在“一對一”、“一對多”或“多對多”的關系。見下表：簡單的需求跟蹤矩陣示例。</FONT><BR></P>
<P>
<TABLE class=hui cellSpacing=1 cellPadding=7 width=559 border=1>
<TBODY>
<TR>
<TD vAlign=center width="8%" bgColor=#c0c0c0><B>需求代號</B></TD>
<TD vAlign=center width="25%" bgColor=#c0c0c0><B>需求規格說明書V1.0</B></TD>
<TD vAlign=center width="20%" bgColor=#c0c0c0><B>設計文檔V1.2</B></TD>
<TD vAlign=center width="15%" bgColor=#c0c0c0><B>代碼1.0</B></TD>
<TD vAlign=center width="15%" bgColor=#c0c0c0><B>測試<a href="200604240937105.html" tppabs="http://www.itisedu.com/phrase/200604240937105.html" target="_new">用例</a></B></TD>
<TD vAlign=center width="17%" bgColor=#c0c0c0><B>測試記錄</B></TD></TR>
<TR>
<TD vAlign=top width="8%">R001</TD>
<TD vAlign=top width="25%">標題或標識符</TD>
<TD vAlign=top width="20%">標題或標識符</TD>
<TD vAlign=top width="15%">代碼<a href="200602282323195.html" tppabs="http://www.itisedu.com/phrase/200602282323195.html" target="_new">文件</a>名稱</TD>
<TD vAlign=top width="15%"> </TD>
<TD vAlign=top width="17%">測試用例標識或名稱</TD></TR>
<TR>
<TD vAlign=top width="8%">R002</TD>
<TD vAlign=top width="25%">…</TD>
<TD vAlign=top width="20%">…</TD>
<TD vAlign=top width="15%">…</TD>
<TD vAlign=top width="15%"> </TD>
<TD vAlign=top width="17%">…</TD></TR>
<TR>
<TD vAlign=top width="8%">…</TD>
<TD vAlign=top width="25%">…</TD>
<TD vAlign=top width="20%">…</TD>
<TD vAlign=top width="15%">…</TD>
<TD vAlign=top width="15%"> </TD>
<TD vAlign=top width="17%">…</TD></TR></TBODY></TABLE></P>
<P>簡單的需求跟蹤矩陣示例1</FONT></P><FONT face=Verdana>
<P><FONT face=Verdana> 使用需求跟蹤矩陣的優點是很容易發現需求與后續工作產品之間的不一致，有助于開發人員及時糾正偏差，避免干冤枉活。</FONT></P>
<P><FONT face=Verdana> 很多人有這樣的誤解：如果依照“需求開發－系統設計－編碼－測試”這樣的順序開發產品，由于每一步的輸出就是下一步的輸入，所以不必擔心設計、編程、測試會與需求不一致，因此可以省略需求跟蹤。那么，需要指正的是，按照<a href="200603061230195.html" tppabs="http://www.itisedu.com/phrase/200603061230195.html" target="_new">軟件生命周期</a>嚴格線性順序的開發模型并不能保證各個開發階段的工作產品與需求保持一致。因為開發者是人而不是機器。而且，大多數開發人員也都深有體會。</FONT></P>
<P><FONT face=Verdana> 生活中“以訛傳訛”的例子，想必大家都很熟悉。學生甲在精工實習時被機器弄破了手指，于是到醫院包扎。同學乙路過醫院時看到甲的手血跡斑斑，以為甲的手指被機器割斷，于是將這個壞<a href="200603090938465.html" tppabs="http://www.itisedu.com/phrase/200603090938465.html" target="_new">消息</a>告訴同學丙。丙急忙轉告同學丁，說甲的手被機器割斷，正躺在醫院里。丁十萬火急地告訴全班同學，大家陷入悲痛之中，都以為“甲的胳膊被機器割斷了，正躺在醫院里，人快不行了。”</FONT></P>
<P><FONT face=Verdana> 由于人們的表達能力、理解能力不可能完全相同，人與人之間的協作很難達到天衣無縫的境界。而使用需求追溯的本身也是一種傳遞的過程。</FONT></P>
<P><FONT face=Verdana> 需求追溯本身并不是一件復雜的事，而是我們的本身一種理念在支配著我們。也許就有人認為這本身就是在浪費時間，主要麻煩是，當需求或工作產品發生變更時，開發人員要及時更新需求跟蹤矩陣。然而沒想到的事，如果后來再花時間來做同樣的事的時候，將會付出更多。也時也就丟去了本身做這件事的意義。</FONT></P>
<P><FONT face=Verdana>需求變更控制(Requirement Change Control)</FONT></P>
<P><FONT face=Verdana> 需求變更通常會對項目的進度、人力資源產生很大的影響，這是開發商非常畏懼的問題。也是必須面臨與需要處理的問題。作為軟件項目，特別在外地實施的工程軟件項目而言，需求發生若干次變更似乎是不可避免的。需求發生變更的起因主要有：</FONT></P>
<P><FONT face=Verdana> 隨著項目生命周期的不斷往前推進，人們（包括開發方和客戶方）對需求的了解越來越深入。原先的提出的需求可能存在著一定的缺陷，因此要變更需求。<BR> 市場業務需求發生了變化，原先的需求可能跟不上當前的市場業務發展，因此要變更需求。由于市場變化而導致需求發生變更，開發商大可不必為此煩惱，應當高興才對。倘若市場靜如死水，那么開發商吃了“上一頓”就沒有“下一頓”。正因為市場在變化，才會產生更多商機，聰明的開發商才會有活干，有錢賺。<BR> 如果在項目開發的初始階段，開發人員和用戶沒有搞清楚需求或者搞錯了需求，到了項目開發后期才將需求糾正過來，導致產品的部分內容需要重新開發。毫無疑問，這種需求變更將使項目付出額外的代價。這種損失是由于雙方工作失誤造成的，雙方應當好好反省，認真學習需求開發和管理的方法，避免再犯相似的錯誤。</FONT></P>
<P><FONT face=Verdana> 總的而言，人們提出需求變更，本就是出于能夠是產品更加符合市場或客戶需求，出發點本身是好的。但對于開發小組而言，需求的變更則意味著要需要重新進行估計，調整資源、重新分配任務、修改前期工作產品等，而作為開發商，需要增預算與投資，開發組要為此付出較重的代價。假定每次需求<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604161514015.html \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon. \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604161514015.html'" tppabs="http://www.itisedu.com/phrase/200604161514015.html" target="_new">變更請求</a>都被接受的話，那么這個項目將會成為一個連環式的工程。</FONT></P>
<P><FONT face=Verdana> 需求變更控制的動機是：</FONT></P>
<P><FONT face=Verdana> 如果需求變更帶來的好處大于壞處，那么允許變更，但必須按照已定義的變更規程執行，以免變更失去控制。<BR> 如果需求變更帶來的壞處大于好處，那么拒絕變更。<BR> 當然，好處與壞處并不是主觀的，而是通過客觀的分析與評價而得出的。<BR> 對于需求的變更，在某一個程度上來說，也就是項目的范圍進行了變化。而需求同時又是項目進行的基礎。是非常得要的基石。通常對于需求的變更需要客戶與開發方共同參與，包括負責人及市場人員。當然，我們需要根據變更的內容來靈活運用。<BR> 需求變更控制過程中最難辦的事情是莫過于“拒絕客戶提出的需求變更請求”。客戶會想當然地以為變更需求是他的權利，因為他付錢給開發方。通常情況下開發方是不敢得罪客戶的，但是無原則地退讓將使開發小組陷入困境。怎么解決這個問題呢，通常情況下，每一類“游戲”都有一定的游戲規則，那么我們事先也需要建立“游戲規則”。<BR> 如果事先沒有“游戲規則”的話，開發方的負責人需要一些社交技巧來減緩矛盾。例如首先承認客戶提出的需求變更請求是合理的，再闡述己方的難處，最后建議在開發該產品新版本時修改需求。這種方式比直接拒絕有效得多，既不得罪客戶，又為自己爭取了余地。<BR> 另外還有一種方法，可以將變更需求先進行記錄，并通知給客戶，當其需求變化在開發組不能接受的范圍時，可以通過市場進行相關的協調。<BR> 需求變更本是正常的，并不可怕，可怕的是需求的變更得不到控制。<BR></FONT></P>
<P></FONT><FONT face=Verdana></P>
<P><FONT face=Verdana><STRONG>二、為什么需要管理需求？</STRONG></FONT></P>
<P><FONT face=Verdana> 簡單地說,系統開發<a href="200603082251135.html" tppabs="http://www.itisedu.com/phrase/200603082251135.html" target="_new">團隊</a>之所以管理需求,是因為他們想讓項目獲得成功.滿足項目需求即為成功打下了基礎.若無法管理需求,達到目標的幾率就會降低. 以下最近收集的證據很有說服力: Standish Group 從 1994 年到 2001 年的 CHAOS Reports 證實,導致項目失敗的最重要的原因與需求有關. 2001年,Standish Group 的CHAOS Reports報導了該公司的一項研究,該公司對多個項目作調查后發現,百分之七十四的項目是失敗的,既這些項目不能按時按預算完成.其中提到最多的導致項目失敗的原因就是"變更用戶需求". </FONT></P><FONT face=Verdana>
?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -