一個沒有說明文檔的IT系統如何進行運維並瞭解清楚所有需求？

一個遺留IT系統，只有少量的用戶需求文檔（不全），如何能夠從運行的業務系統詳細的瞭解清楚所有的需求和業務規則。

同意 @zllen ge 的說法，站在巨人的肩膀上，我希望做幾點補充，解決這種問題的關鍵是要找到該系統的直接使用者，對於如何定義「使用者」，大概分為如下兩類：

系統的擁有者：使用該系統的部門的直管領導

系統的操作者：一線操作員工

不知道這樣的定義是否合適，展開說一下：

對於系統的使用者，其更清楚該系統最初的開發目的，另外，從管理者的層面出發，其也更明確該系統所扮演的角色，這是從大的範圍來對一個系統的開發背景，概要需求作梳理；

對於系統的操作者，其自然更清楚該系統中某些具體的模塊的使用方式，運作方法或者功能跳轉邏輯，可以從功能層面對一個系統進行梳理；

在梳理系統的過程中有幾個點需要把握：

我們應該聽誰的

誰的意見更有參考價值

其實這兩個點歸根結底是一個問題，即「到底是聽領導的，還是聽一線操作員工的？」。

舉個例子吧。

目前手頭有一個倉庫管理系統，這個系統是跟一個類似於ERP的系統整合到一起的，你需要分析這樣一個遺留的倉庫管理系統的需求，那麼問題來了：

如果你去諮詢一線操作人員的意見，他會告訴你：

我這個物料入庫是怎麼個操作邏輯，各庫之間的周轉又是怎樣一個邏輯，我是如何記錄物料的進出，等等。

如果你去諮詢直接主管的意見，他則會告訴你：

我之所以要上這個系統，是因為以前的系統各個庫之間是孤立的，我把各個庫合併到一起管理並且整合進ERP，可以從整體上把握整個生命週期內物料的周轉。

那麼，作為系統的運維人員，你應該聽誰的？答案可能一線操作人員，因為你需要更關注系統功能細節上的操作規程。

作為系統的設計師/改造者，你應該聽誰的？答案則可能是直接主管，因為你需要首先從宏觀上了解這個系統所承擔的角色、設計的目的及項目深層次的背景，而這些，一線操作人員是不會告訴你的，當然，他們也極有可能是根本就不知曉的。

根據管理層的意見，先準確把握系統的架構及設計方向，再去根據一線運維人員的建議逐步細化需求，可能會更契合系統的設計初衷。

拙見！

1.去業務部門坐檯至少二天，看業務部門從頭到尾操作。2.在有測試環境的基礎上（若無則建議構建一個)，按照業務用戶的操作來一遍3.與業務用戶溝通，虛心請教4.關注相關的業務的公司的作業指導及相應的規章制度，關注業務流程

第一條路是找業務人員瞭解系統運作，包括基礎操作、業務流程內容、數據填報以及報表生成。這些信息的收集的深入程度需要依靠業務人員對系統的瞭解程度。第二條路是依靠第一條路得到的信息，將系統備份到一個新的環境自己折騰系統功能，從而歸納出部分業務規則。第三條路是聯繫原系統負責人，包括系統開發者和系統管理者，協調他給你部分信息。最後一條路是反編譯系統，分析資料庫設計等等。只能想到這些。

從資料庫入手～～

如果是沒有上線的系統，把自己當用戶，搭建模擬環境，參照現有文檔，使用系統是瞭解需求的最好辦法了。當然不是實際環境，肯定會有遺漏的。只能是儘可能多瞭解。