我參與了幾個基本上涉及用「新」系統替換「舊」系統的項目。總的來說，建立「新」系統的團隊中實際上沒有人對「舊」系統有任何真正的瞭解。每當我對此提出質疑時，我都被告知這是有目的的......通過不知道「舊」系統，團隊能夠以不同的方式思考，而不受到事情如何完成的限制。所以會發生什麼事情，團隊中通常只有1或2個人知道關於「舊」系統的任何信息，並且每當出現有關「舊」系統如何做的問題時，都會諮詢他們。誰應該學習「舊」系統？
但總是似乎發生的是，在「新」系統交付之後，總會有用戶提問「我們如何在新系統中X（在舊系統中很容易）」 ？」對於開發者來說，這往往是他們第一次聽說X.所以他們必須去研究X是什麼，而且他們給用戶的答案往往是「你不能」或「你可以，但是它是非常尷尬「。
這對我來說看起來不太合適......在我看來，每個「新」系統的開發人員都知道「舊」系統真的很好，而且這並不一定會殺死很多人他們的創造力，如果他們有體面的設計和開發技能。
想法哪種方法最好？
用一個新的更換舊系統通常意味着異功能（即至少是舊的系統能夠做到這樣做的能力）
所以，當老系統的深入瞭解不是強制性的，知道接口並構建一套功能測試套件對於有效開發新系統非常有用。
該套件將用於驗證新開發的結果，請記住結果絕不能爲100％（否則，您將成功複製第一個系統的錯誤！）
另外，對於一個非常龐大的系統，你需要爲你的新方案至少有三個實現：
如果我們正在談論很長一段時間，那也涉及到一位能夠管理舊系統演變的架構師（它不能靜止不動，等待幾個月或幾年後才能替換新架構），保留那些與新實現相同方向的進化。
您需要更好的業務分析師。他們是那些應該檢查舊系統的人，並且準確（完全）定義新系統需要做的事情。他們應該爲您提供完整的要求清單，以便所有需要發生的事情都被考慮在內。
無論誰寫的要求需要更徹底。如果這是不可能的，那麼你可能需要參與並學習'舊系統'。
但是總會有東西被遺漏 - 這只是人性而已。顯然，你應該儘可能使「新系統」儘可能靈活，這樣當用戶意識到他們已經被遺忘時，需要添加功能。
我明白你的痛苦。
這聽起來像新系統的規範是不完整的，因爲某人（項目經理，項目發起人）不能確保舊系統的功能被記錄和檢查以查看客戶實際使用的內容。
如果這樣做，那麼沒有人知道舊系統應該沒有問題，因爲規範是您正在開發的對象。
如果你沒有規範，除了你會遇到的所有其他問題，每個人都應該知道舊系統以避免這個問題。
+1'如果你沒有規範......每個人都應該知道舊系統' - 在太多的情況下也是如此。 – 2009-11-23 12:59:17
在那裏沒有BA，它很痛。試圖與用戶討論'新'需求有時也很困難，因爲a）他們並不總是需要一個新系統，b）他們只是想讓它做舊的工作 – blank 2009-11-23 13:52:14
噢。第1號要求總是與舊系統相同。 「你需要製作字體Times New Roman，這就是舊系統的樣子」。 – 2009-11-23 14:39:04