讓需求能夠重用

原文：Making Requirements Reusable
人們爲了提升軟件的生產力，老是在追求可重用性。代碼重用是人們考慮的最多的，但其餘軟件項目元素也具備可重用性。重用需求能夠提升生產率，改進質量，還能在相關的系統中保持更好的一致性。

可是，重用不是免費的。它有它自身的風險，不論是重用已經存在的需求仍是爲了重用建立新需求。建立高質量的可重用的需求比單純爲當前項目寫需求要花更多的時間和努力。在這篇文章中，咱們講述了一些組織爲了重用需求所用的方法。

已經存在的需求並不表明它當前的形式就是可重用的。它可能只是針對特定項目的，也可能由於BA當時比較肯定研發團隊具有某些特定的知識或者面對面溝經過，寫的時候（譯者：抽象）層次過高（並無那麼具體）。有的需求可能缺乏異常狀況應該如何處理的信息。所以，爲了提高需求未來對其餘BA的價值，還必須原始需求作一些調整。

寫得好的需求天然是能夠重用的。讓需求可重用所採起的措施對原始需求所在的項目也有好處。重用的人須要知道需求的依賴因素和被其它需求依賴的因素，這些相互關聯的需求合在一塊兒造成一個需求包。

能夠重用的需求必須有正確的抽象層次和邊界（scope）。特定領域的需求抽象層次會更低（譯者：更具體）一些，多半是由於他們只適用於原來的領域。通用需求在不一樣種類的系統中的應用範圍更逛。可是，若是爲了達到這個目標，並不會省多少力氣。由於BA仍然要敲定其中的細節。讓重用既簡單又值得是很難平衡的，簡單意味着更多的抽象或者更通用，值得意味着更多或者更具體的細節。

圖一就是一個例子，某個應用裏可能包含了一個支持用戶用信用卡支付的需求。這個需求能夠擴展成一個功能集合和一堆與信用卡支付相關的非功能需求。其它應用可能也要支持用信用卡支付，這就是個具備可重用性潛力的需求集合。
Figure 1

假如，你想支持更多的支付方式，好比信用卡、借記卡、禮品卡、eCheck、電子轉帳，所以想把這個需求變得更通用，未來就更有可能在更多項目中重用這個需求。某個項目可能只須要處理信用卡，其它項目須要處理其它支付方式。歸納初始的用戶需求對當前項目也很是有價值，就像從「支持信用卡支付」歸納爲「支持支付」。即便客戶只要求了信用卡支付，用戶可能很是想要其它支付方式，不論是如今仍是未來。

選擇正確的抽象層次對（項目）構建也很值得。 在有明確的多種支付方式需求的項目裏，對每種狀況生成清晰的需求和（業務）規則既能暴露出區別也能發現共性。而不考慮未來重用的可能性的話，高層抽象則能產生簡單的設計和構建。

以上是好的方面。壞的方面是把原來已經存在的需求變得更通用須要花點功夫。這是你但願收到重用回報投的資（That’s the investment you make in reusability, anticipating that you will recoup the investment—and more—through multiple, future reuse instances. ）。是要把今天的需求共享出來供未來重用，仍是如今就爲未來的項目提高需求的可重用性，決定權全在你本身。

有同事曾經分享過一個有警示做用的故事，怎樣用大量的細節需求減小重用的可能性的。有個團隊被分去給一個新項目寫需求，但他們太癡迷於重用了。BA們認爲若是能分別記錄下每一個需求的全部細節，就能重用這些需求了。最後他們寫了一萬四千條需求。整個需求庫（repository）裏有好多條目均可以只寫成一條，可是被組織成了樹狀結構，一條需求有好多條子需求用來描述上級需求的某個特定細節。需求被細化成這樣就只能綁定在一個應用上面了。

如此大量的需求也讓循環測試更難了，測試人員天天都在抱怨，由於要過這麼多的需求，他們花了比預想的多得多的時間去寫測試用例，他們爲了追蹤需求的覆蓋狀況還要給測試用例加上需求ID，但仍然很難管理。這還不夠，需求還經歷了巨大的變化，歷來都沒有徹底穩定下來。全部這些因素致使這個項目完了一年才實施，也沒有產生預想的可重用的需求集合。

理想狀況是，BA永遠都能寫出能在多個相關項目中重用的需求，所以能爲所在的組織節省大量的時間和金錢。現實倒是，你得先去尋找那些有重用潛質的特定需求，再打磨他們，提升他們能讓其餘BA以爲有用的可能性。