使用Rational RequisitePro并行管理基于文檔需求的開發(2)

　　圖 8. 分支 – 導入文件 3

　　在 Create Document 窗口中，選擇Yes。

　　識別包含的需求需要導入文件的書簽，所以選擇No以回答“您是否想要刪除這些書簽?”這個問題，因為您需要保持嵌入需求的書簽(圖 9，“分支 – 導入文件 4”)。

　　圖 9. 分支 – 導入文件 4

　　最后，選擇Commit按鈕(圖 10，“分支 – 導入文件 5”)。

　　圖 10. 分支 – 導入文件 5

　　在導入文件之后，原始 Rational RequisitePro 文件會有一個一模一樣的拷貝(如圖 11，“分支 – 被分支的文件及需求”所示，包含標記的需求)，而 R11 發布包含有它自己的 RequisitePro 文件(參見圖 12，“分支：R10 的 R11 分支”)。

　　圖 11. 分支 - 被分支的文件與需求

　　圖 12. 分支 - R10 的 R11 分支

　　注意，在文件的導入期間，已經創建了新的需求。新創建的需求并不是原始需求的拷貝，而是應用默認值的新實例。檢查一下，原始的需求是否擁有需要為需求的拷貝輸入的默認值。

　　R11 發布版本現在還包含了一個單獨的需求文檔及其需求。這些需求可以單獨進行編輯，而不用考慮原始的需求文檔與需求。

　　追蹤原始的和分支的版本

　　在這個簡單的例子中，很容易追蹤原始的和分支的需求。在擁有數百或者數千需求的實際項目中，您需要一個工具以仔細查看。

　　可以使用的另一種機制，就是創建原始需求與分支需求之間的追溯關系(圖 13，“通過追溯關系來追蹤原始的和已分支的需求”)。這起到兩個目的：

　　有一些文檔是為分支需求的起源而建立起來(追溯關系的方向，可以是從原始的需求到分支之后的需求)。

　　如果對需求所做的變更是在不同的分支中所做的，那么就會為通知團隊成員創建一種機制(如果是復雜的用例，那么最好與其他的團隊保持聯系)。

　　其中有一條很小的限制條件，那就是追溯的關系不允許是閉環的。因此，您必須要么記錄分支要么記錄合并關系。

　　圖 13. 根據追溯的關系來追蹤原始的和已分支的需求

　　另一種機制就是使用其他的屬性來管理分支或者合并。您可以通過向標為“來自于”和“合并至”的需求類型添加一條文本屬性，來記錄需求的狀態。不能進入來自于則意味著它是一個原始的需求。不能進入合并至則意味著分支的需求尚未得到合并(參見圖 14，“使用屬性以管理分支/合并”)。

　　圖 14. 使用屬性以管理分支/合并

　　合并一個 RequisitePro 文件

　　如果一個已存在的文件被分支了，那么它會在一定程度上得到更改。這種更改可能一處變更、添加或者刪除。我們將會向您展示怎樣對分支的需求文檔執行這三種變更操作，并完成合并過程，這樣您就可以看一下怎樣將這些操作集合到原始的需求文檔中。用例標題上會有一點的變動：需求 UC4 被刪除了，而添加了需求 UC5(圖 15，“對已分支的需求文檔所做的修改”)。

　　圖 15. 對已分支的需求文檔所做的修改

　　在從 Microsoft Word 菜單中應用變更之后，我們會選擇RequisitePro > Document Save以提交對數據庫所做的變更。

　　現在，將這些變更合并到原始的需求文檔之中。首先，您需要創建一個臨時文件。

　　從 Microsoft Word 菜單中，選擇RequisitePro > Document Save As，并以原始的 Microsoft Word 格式來存儲這些文件。

　　打開臨時文件，并從 Word 菜單中，選擇Insert > Bookmark。

　　通過雙擊書簽來進行導航。就算沒有 RequisitePro 文件，需求文檔中每一個需求都仍然會有一個書簽。在這個需求文檔的例子中，我們有兩個書簽。一個是用于已編輯過的需求的。另一個是用于已添加需求的(圖 17，“已添加的需求的書簽”)。

　　刪除與編輯需求相關的所有書簽，因為您并不需要 RequisitePro 以在導入期間考慮它。結果如圖 18，“已清理過的需求的書簽”所示。

　　在您完成操作之后保存文件。

　　圖 16. 已編輯的需求的書簽

　　圖 17. 已添加的需求的書簽

　　圖 18. 已清理過的需求的書簽

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

• 共3頁:
• 上一頁
• 1
• 2
• 3
• 下一頁