1.啥是R3PR？

Requirement：需要做什么

Plan：計劃怎么做

Resources：指派誰去做。當然資源還包括其他的，但誰讓咱只是管編碼的呢，在我手里，只有人是資源

Process：實際怎么做

Result：結果怎么樣

2.包含哪些信息？

舉個例子，編一個計算器程序。

Requirement：

ID	需求名稱	描述	與其他需求關系	屬性	狀態
1	輸入界面	讓用戶輸入表達式	2，4，5	優先級=高，重要性=強，…	新建
2	算法實現	根據表達式計算結果	2，4	優先級=高，重要性=強，…	評審
3	輸出界面	顯示結果	5	優先級=較高，重要性=較強，…	新建
4	性能1	又快又準	2	優先級=高，重要性=強，…	完成
5	性能2	操作方便	1，3	優先級=高，重要性=強，…	新建

思考：

需求為什么要狀態？

因為需求不是靜態的，需求應該是在開發過程可以增加、刪除、變更的。比如在初始設計時，是沒有與bug相關的需求的，但是到開發階段，就有與bug相關的需求了。因為需求是動態的，所以需求的狀態是應該記錄的

需求間有哪些關系？我們需要區分這些關系的種類嗎？

需求間可以有你所能想象的各種關系。通過關系可以把需求組成一張網，然后從一個需求出發，找出它的關系網中的其他需求。這對分析和管理需求是重要的。但是關系的種類也許不必要區分。打個比方，在許多社區網站上都有一個“加關注”功能，社區網站的管理者或數據分析者可以利用用戶之間的關注關系描繪出一張用戶的關系網。但是好像沒有誰給關注再分個類，標明關注強度或關注理由等信息。這些信息沒有用嗎？按理說也有用，但是為什么不做呢？我想應該是性價比。要求用戶在加關注時填寫過多信息會降低用戶體驗，同時給社區管理帶來的增值不夠明顯。同理，需求之間表示存在關聯應該就足夠了，更多的信息并不能極大提高管理效率，但是增加了管理成本（填寫這些信息并保證他們的正確性和完整性所付出的努力都是成本）。

需求為什么需要屬性？

屬性把需求看做了一個集合，利用屬性就可以從這個集合中提取出一個子集。當需求很多的時候，屬性提供了一個過濾或聚焦的工具，讓管理者可以快速找到感興趣的需求集合。那一個需求需要多少屬性才夠？誰也說不準。所以最好需求的屬性是能夠自定義的，當需要什么樣的分類時就添加什么樣的屬性

?

Plan：

ID	任務名稱	子任務	前置任務	描述	工時估計
1	實現輸入界面	?	?	?	2
1.1	?	表達式輸入框	?	用戶可以輸入一個表達式	1
1.2	?	計算命令按鈕	?	用戶啟動計算過程	1
2	實現算法	?	?	?	6
2.1	?	表達式解析	?	解析用戶輸入的表達式	3
2.2	?	表達式計算	2.1	計算解析后的表達式	3
3	實現輸出	?	?	返回計算結果	1
4	檢驗性能1	?	?	?	3
4.1	?	檢驗是否快	?	?	2
4.2	?	檢驗是否好	?	?	1
5	檢驗性能2	檢驗操作是否方便	?	?	2

Resources：

ID	資源名	分配的任務
1	張三	1，3
2	李四	2
3	王五	4，5

思考：

計劃中的任務和需求有什么區別？

計劃中的任務講的是要做什么，需求講的也是要做什么，他們的區別在哪里？最大的區別在任務之間有明確的先后關系，而需求之間沒有。正是因為任務有先后關系，才能在此基礎上，排出時間進度。而任務的工時，任務分配給誰等等，不過是為了讓排出的時間進度更準確。

需求與任務之間應該是什么關系？

理論上是多對多關系。即一個需求可能需要多個任務去實現，一個任務可能為多個需求服務。但在實際操作時，也許可以用一對多描述。想象一下你是怎么提出任務的：拿著需求列表，指著一個需求說，我希望這個需求用這幾個任務去完成，然后手指下滑，指著下一個需求，繼續說，我希望這個需求用這幾個任務去完成…，最終，得到了一張任務列表。那么，如果一個任務能夠為多個需求服務，怎么辦呢？首先，需求之間任務重疊的概率是很低的，因為如果需求間有太多的重合任務，說明你的需求分析有問題，沒有把應該分離的需求分離開。其次，真的有兩個需求A和B之間有重疊的部分，完全可以把重疊的部分提出來，形成一個新需求C，A和B的任務各自完成不重疊的部分，而把重疊的部分委托給C。比如日志服務就是一個范例。這樣做有什么好處呢？首先，思維模式是順暢的，因為我們通常是根據需求去確定任務，而不是根據任務去反推他應該為哪個需求服務。其次，產生的任務是高質量的，因為你既沒有為需求A和B提出重復的任務，又解耦了A和B之間的關聯，提出了一個通用性更強的需求C。

?

Process：

ID	為什么干	誰干的	啥時干的
1	完成[任務1.1]的界面部分	張三	01-02-03 10：35：25
2	完成[任務1.2]的界面部分	張三	01-02-03 10：36：25
3	完成[任務2.1]的輸入校驗	李四	01-02-03 10：45：25
4	完成[任務1.1]	張三	01-02-03 10：55：25
5	[任務4.1]檢測不合格	王五	01-02-03 12：35：25
6	完成[任務2.1]	李四	01-02-03 14：35：25
7	[任務4.2]檢測不合格	王五	01-02-03 22：35：25
…	?	?	?

過程應該怎么管理？

過程是指任務的實現。過程的記錄通常是借助版本控制系統。那么哪種版本控制系統是更好的呢？想象一下，你為了完成一個任務，需要編寫3個文件，A文件寫完你提交了，任務完成了嗎？沒有。應該3個文件都提交，才算齊活。因此，以任務單元提交為模型的版本控制系統才是合理的，而以文件單元提交為模型的版本控制系統會給管理帶來很多不必要的工作量。

過程應該記錄哪些信息？怎么記？

過程應該記錄的信息不外乎3類：誰干的？啥時干的？為什么干？。因為過程是用版本控制系統記錄的。版本控制系統一般都自動記錄了who和when，剩下手工記錄的只有why了。why一般都通過commit時的comment記錄。那comment應該怎么記錄why呢。我想首先應該記錄的是與commit相關聯的任務ID或需求ID，這樣管理時就知道這次commit是針對哪個任務或需求了。至于其他信息，不過是對commit與任務/需求之間關聯的更詳細的解釋，怎么寫都行。那究竟應該記錄任務ID還是需求ID呢？看你使用什么bug管理系統。普通的功能需求往往對應多個任務，將commit與任務ID對應更精準。而bug的處理通常是一個bug對應一個任務/需求，有的bug管理系統把bug算需求，有的呢則算任務，不管怎么算，在comment中記錄任務id或需求id是必須的。否則就容易丟失“為什么干”的信息。

?

Result:

ID	描述	狀態	?
1	性能1	bug	?
2	性能2	合格	?

思考：

結果應該怎么記錄？

結果是通過測試過程獲得的，結果的目的是驗證需求是否得到滿足。所以結果應該和需求發生關聯。在結果的記錄中，應該有對應需求的id，同時結果要表明需求是否已滿足，因此結果應該改變或維持對應需求的狀態。其次，一個不滿足需求的結果應該產生新的需求或任務，即bug報告。在bug報告中除了盡量清楚的描述bug外，重要的是要把被測需求的id記錄下來，這樣別人才知道這個bug針對誰。

轉載于:https://www.cnblogs.com/madbyte/archive/2010/07/26/1785375.html

總結

以上是生活随笔為你收集整理的关于需求管理的胡思乱想---R3PR的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。