需求的問題

需求的問題，是一個簡單的問題 

需求決定了軟件做什么，要提供什么功能。 

軟件工程初期的一般過程是，軟件開發的計劃，確定要實現的目標和進度等，然后就是需求規格說明書，該說明書要得到用戶的認可。用戶往往提供了一份要求的說明，開發人員在這個基礎上進行了加工和整理。此后的開發過程，都是圍繞著需求規格說明書進行進一步地細化，直至開發出產品。當然，測試計劃中也要針對需求進行驗證，看看是否滿足了用戶的要求。 

一般來說，用例視圖可以很好地表現需求。用例圖中，若干角色actor與系統提供的用例（功能）之間的連接關系。 

以下是參考《IEEE推薦的軟件需求規格說明的方法（IEEE 830-1998）》的一個系統規格說明書SRS模板： 
  

一、引言

（一） 目的
（二） 文檔約定
（三） 預期的讀者和閱讀建議
（四） 產品的范圍
（五） 參考文獻

二、綜合描述

（一） 產品的前景
（二） 產品的功能
（三） 用戶類型和特征
（四） 運行環境
（五） 設計和實現上的限制
（六） 假設和依賴

三、外部接口需求

（一） 用戶界面
（二） 硬件接口
（三） 軟件接口
（四） 通信接口

四、系統特性

（一） 說明和優先級
（二） 激勵/響應序列
（三） 功能需求

五、其它非功能需求

（一） 性能需求
（二） 安全設施需求
（三） 安全性需求
（四） 軟件質量屬性
（五） 業務規則
（六） 用戶文檔

六、其它需求

附錄A：詞匯表
附錄B：分析模型
附錄C：待確定問題的列表 
  
另外，《GB9385-88 計算機軟件需求說明編制指南》也為軟件需求實踐提供了規范化的方法。

需求的問題，是一個復雜的問題 

有些時候，需求的問題會變得很復雜的。尤其是在做行業軟件或者ERP的時候，你遇到不同的客戶，每個客戶都有他的想法或要求，而且有些客戶沒有明確的思路，有些則有他們很固執的思路，一時間仿佛需求是沒完沒了的?；蛟S你的軟件已經是一個產品，那么究竟對什么功能進行取舍，對什么功能要增加進軟件的核心，對什么功能采用二次開發，都是需要仔細判斷的事情。  
  

1 需求的重復和變更 

對于比較大的系統，客戶不可能一次性地把需求完全提清楚。這是必須容忍的。只要你不斷溝通和了解，用戶需求就會不斷增加。有些公司采用的方法是在需求規格說明書上讓客戶簽字，然后嚴格按照該說明書來實現。如果以后客戶有新的要求，則要另外考慮。但在另一方面，客戶永遠是上帝，一個軟件的成功，應該是用戶用得非常流暢和滿意。  

  
2 有些需求無法實現 

和客戶的溝通也很重要。什么是必須滿足的需求，而另外一些需求可能暫時不能提供實現，這也需要解釋清楚。  

  
3 實現的功能和客戶原來提出的需求會有所差別。 

很多軟件的問題最后總結下來是因為需求沒有明確。開發人員沒有認準客戶究竟需要什么。這時候只能修改軟件。 

需求的問題，是一個技術的問題 

每個需求的特性可體現在很多方面：如優先級、有效性，效率，靈活性，完整性，互操作性，可靠性，健壯性，可用性；可維護性，可移植性，可重用性，可測試性等。

確定需求優先級：可以粗略地分為三級：

高	一個關鍵任務的需求，必須在此版本實現；只有在這些需求上達成一致意見，軟件才會被接受；必須完美地實現
中	支持必要的系統操作，最終所要求的，但如果有必要，可以延遲到下一版本；實現這些需求將增強產品的性能，但如果忽略這些需求，產品也是可以被接受的；需要付出努力，但不必做得太完美
低	功能或質量上的增強，如果資源允許的話，實現這些需求會使產品更完美；實現或不實現均可；可以包含缺陷

更精確的優先級設定如下表：

權值	1	1			1		1
MILY: 宋體; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'">需求	收益	代價	價值	價值%	成本	成本%	風險	風險%	優先級
<需求>	<1-9>	<1-9>	<>	<>	<1-9>	<>	<1-9>	<>	<>

其中各權值按實際情況而定，不能確定按1取值。

收益：實現此需求對用戶的益處；

代價：未實現此需求對用戶的損害；

價值=收益*收益權值+代價*代價權值

價值%=價值/（總價值）*100%

成本：實現此需求所需的各種成本；

成本%=成本/（總成本）*100%

風險：實現此需求所承擔的風險，特別是技術上的；

風險%=風險/（總風險）*100%

優先級=價值%/（成本%*成本權值+風險%*風險權值）

最后按需求優先級排序，優先實現高優先級的需求。

  

風險的控制和避免：

對需求將可能面臨的風險要有充分的估計并盡量避免風險的發生及其所造成的損失。建立風險跟蹤，保持對危害最大的幾項風險的控制，并在開發過程中周期性地更新風險跟蹤項目。

需求的問題，是一個管理的問題 

需求取得：市場銷售部門、技術支持或客戶服務所得到的需求，或者開發人員內部通過對業務的分析歸納得出的一些要改進的功能。

對需求進行管理的環節應該盡可能精簡。最好直接由系統分析來做。經過很多環節的篩選，需求可能已經走樣了。紙面上只有一兩句話的需求，背后有你看不到的真正想法存在。 所以應該主動走出去尋找需求，應該選擇最典型的客戶進行訪問。領會他們的管理思路和改革方向。  

需求決策：對于相互矛盾的需求，在同類用戶中由產品代表決策；對于不同類用戶要根據重要性作適當折衷；對于用戶的特別喜好要根據用戶的重要性決定；用戶中領導的需求要服從最終實際使用的用戶需求；當開發者想象中的產品通常要服從用戶的需求，但并不表示用戶總是對的。 

需求分析：分析需求的各個特性，制作出需求分析規格說明書。

需求評審：由相關人員共同對需求進行評審。

需求變更：如果遇到需求的變更，需要及時作出調整，即使與開發部門聯系，提出變更的建議，并分析可能產生的影響，如對產品穩定性的影響。變更的需求需要嚴格的測試。 

版本控制：確定需求文檔版本，確定單個需求文檔的版本； 

需求跟蹤：需求的跟蹤記錄需求的狀態，包括未定義、放棄、需完善、已定義、實現中、待測試、測試中、完成、放棄實現等 

需求管理工具：曾經看到過的工具有Rational Requsite Pro 4.5版。需要用Word 97支持。但對中文的支持不夠好。 

筆者對Requsite Pro4.5的功能進行了整理。請在本站點的ROSE工具欄目中尋找該文。  

筆者也制作了一個IE版的需求管理工具，使用了ASP/Aclearcase/" target="_blank" >ccess2000。特點是和客戶管理聯系在一起。提供了對需求各屬性的描述，也提供了對每一條需求的討論和跟蹤。這是一個1.0 Beta版的，剛開始使用的東西。 

看詳細說明并下載，請在本站點的系統分析欄目中尋找該文。 

　

/*

跋：

以上標題的結構，有些象一首歌的主題，其實還真有這么一首歌，叫做《三兒的問題》，不想被我改編了一下，遂成為：

　

需求的問題，是簡單的問題，

需求的問題，是復雜的問題，

需求的問題，是技術的問題，

需求的問題，是管理的問題，

需求的問題，是你們的，我們的，

他們的，大家的問題。


*/ 

原文轉自：http://www.anti-gravitydesign.com