系统需求分析书doc.docx
《系统需求分析书doc.docx》由会员分享，可在线阅读，更多相关《系统需求分析书doc.docx（20页珍藏版）》请在冰点文库上搜索。
系统需求分析书doc
數位典藏國家型科技計畫
考古發掘遺物、照片、記錄與檔案
數位典藏計畫
遺物典藏管理系統軟體需求規格書
（version0.9）
合作單位：
中央研究院歷史語言研究所
系統分析：
中央研究院資訊科學研究所
系統開發：
中央研究院資訊科學研究所
中華民國 九十一 年 六 月 十八 日
需求確認表
敬啟者:
謝謝您詳細閱讀本組為貴單位所分析的考古發掘遺物典藏管理系統需求分析文件，對於軟體需求規格書所載之內容是否符合貴單位之需求
是 □ 否□
若軟體需求規格書所載內容不符合貴單位的需求，請說明原因。
謝謝。
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
系統分析員
受訪者簽名＿＿＿＿＿＿＿＿＿＿
單位主管簽名 ＿＿＿＿＿＿＿＿＿＿＿
中華民國 年 月 日
目錄
圖目錄
1.前言
1.標的軟體系統摘述
本計畫主要係將考古調查與發掘所發現之遺物、所有過程之記錄與影像檔案，以數位化的方式有效的保存於電腦系統中，使得考古調查與發掘之研究現場與過程，能儘可能完整的記錄與保存，進而還原考古現場。
本系統並應考量到研究學者與一般社會大眾資訊需求的不同，符合不同使用者能以適當的方式進行相關查詢與檢索。
同時應提供資料管理者與研究人員資料建置與維護的功能，以確保資料的正確性。
本計畫在器物方面，將結合金石拓片計畫小組、故宮博物院及歷史博物館等單位，並與其計畫之數位典藏系統進行資料交換之整合工作，以建立一個考古發掘研究的數位化博物館，進而提供中央研究院、中華民國及世界上考古研究單位之的參考。
2.定義與縮寫符號
（1）XML-ExtensibleMarkupLanguage
（2）CDWA（CategoriesfortheDescriptionofWorksofArt），見參考資料。
3.參考資料
（1）中央研究院後設資料工作組製之考古發掘遺物、照片與記錄Metadata需求規格書，http:
//www.sinica.edu.tw/~metadata/project/project-frame.html。
2.
文件目的與系統描述
1.名稱
本計畫全名為“考古發掘遺物、照片、記錄與檔案數位典藏計畫”，簡稱為“考古發掘數位典藏計畫”，系統名稱為“考古發掘遺物典藏管理系統”。
2.目標
本計畫之目標在記錄考古工作中發掘之遺物、調查之過程與研究之成果，以建立考古發掘資料庫整合中心，做為研究學者與社會大眾研究及教育學習之知識平台。
3.範圍
由於“考古發掘數位典藏計畫”其來源涵蓋了法國舊石器時代石器，龍山文化考古遺址發掘、新石器時代遺址、安陽殷墟發掘、濬縣辛村西周遺址發掘、汲縣山彪鎮與輝縣琉璃閣東周發掘、臺灣考古發掘之標本、照片、記錄、檔案等，而且典藏種類也包括器物、甲骨、人骨與獸骨，及其他考古發掘出土與歷來對其研究處理所衍生而來的資料。
因此整個考古發掘計畫可以區分為四個層次：
遺址、發掘單位、遺跡及遺物。
本計畫採分階段方式發展，目前本需求規格書中是以典藏考古發掘之遺物層次為主要範圍，目的係以建置考古發掘遺物典藏管理系統，其內容如下：
（1）預定整合遺物資料庫，其中包含遺物、科學鑑定、合編關係等資訊，並提供各種資料的著錄與維護功能。
（2）藉由不同資料的查詢介面，提供社會大眾或研究學者進行跨資料的檢索及導覽功能，並且以相互連結方式提供完整的典藏資訊。
（3）提供資料整合與資料轉換工具，以符合與其他計畫資料交流之需求。
4.
軟體環境
本系統建置在開放網路環境之中，並以網頁為操作介面，使用者可透過網際網路及瀏覽器操作系統所有功能。
在系統架構上主要包括三種類型的軟體規劃分別是資料庫（Database）、網頁應用程式與多媒體整合中心。
圖表1：
系統架構圖
5.數位化規格
（1）公用典藏格式：
以A4大小為準，檔案的最高解析度為150dpi。
亦即在網頁上能夠以A4尺寸進行一次一倍的放大。
（2）印刷出版格式：
以A4大小為標準，檔案的解析度為400-600dpi。
亦即能夠以兩百線以上的水準進行分色印刷。
（3）國家典藏格式：
以4×5幻燈片底片為標準，檔案的解析度為130百萬畫素以上。
6.系統用戶種類特性
由於本系統為建立考古發掘資料庫整合中心，就功能而言需要提供不同類型使用者之使用。
因此系統應針對不同的使用對象和權責提供分層存取權限之設定功能。
在使用對象上可分為三類：
（1）典藏管理人員：
主要負責典藏資料的建檔與管理工作。
（2）典藏研究人員：
通常需要參考完整典藏資料以進行更深入研究工作。
（3）一般民眾：
此類型使用者需求簡單而且快速的查詢和導引界面，以提供教育學習中的知識教材。
3.分項功能需求
1.系統需求
為達成考古發掘數位典藏系統之目標，因此系統必需滿足以下幾項特性：
（1）績效需求：
資料之正確性及一致性，資訊系統發展符合使用者實際需求。
（2）操作需求：
系統使用網頁存取介面，並建立一套標準人機界面操作模式，提供使用者理想作業環境，並改善網路存取服務速度的限制，提供快取服務與快速瀏覽介面。
（3）可靠性：
系統必需維持高度的穩定性，儲存在系統中的資料不能因系統相關問題，而導致資料毀損。
即使系統發生故障亦能在極短的時間內恢復系統的正常運作。
（4）控制需求：
系統操作力求簡單明瞭，避免不當作業流程，以求作業之流暢與安全。
由外部傳入資料必須記錄其傳入狀況，系統設計需採用資訊工程之標準方法，以利專案品質的控制以及未來系統之維護。
（5）安全需求：
具備帳號認證之功能，以區分使用者與系統管理人員之權限，且資料庫具備資料存取管制功能，以效防止非合法授權者侵入系統內竊取資料。
系統內部架設防火牆以保護各伺服器之網路安全。
（6）整合需求：
此系統將與其他計畫資料庫提供XML整合需求，並可提供資料轉出與資料匯入之解決方案。
2.界面需求
（1）網頁操作模式必須簡單清楚，容易操作不複雜。
（2）使用800*600的螢幕解析度，色彩最少為HighColor，確保圖形的色彩不失真。
且不會因解析度的不同而導致界面呈現出問題。
（3）所有圖形設計必須無版權問題。
（4）圖形設計以GIF及JPG為標準格式。
（5）網頁設計必需使用標準的HTML語法，使Netscape與IE呈現相同的界面。
3.
功能需求
系統主要針對遺物層級管理工作所設計之功能，其中包括遺物基本資料建置、合編資料建置、遺物管理功能。
圖表2：
系統功能
（1）.遺物基本資料建置
遺物基本資料建置目的在提供考古發掘中遺物資料管理功能，其中包括遺物基本資料新增及維護等作業。
各模組詳細的功能說明如下：
A.遺物基本資料新增：
提供考古發掘中的遺物資料新增功能，可詳細記錄每一件出土物品的重要內容及針對遺物所做的考古研究過程中重要的數據。
B.遺物基本資料維護：
每一件被記錄下來的遺物資料，皆可透過查詢介面，檢索符合查詢條件的遺物資料，並能詳細檢視遺物記錄內容。
若有需要修改或刪除處理，也可直接調整遺物資料。
查詢的結果中必須顯示出是否被合編在其他遺物之中，並顯示該合編後的遺物登錄號。
（請參考合編資料建置功能）
（2）.
合編資料建置
在合編資料中主要記錄每樣考古出土的物品可能因年代久遠而損毀或分裂成許多部份的遺物，透過考古研究中必須還原最初且完整的物品資訊。
因此利用合編關係可以重新建立許多遺物的併合、套件或合件關係。
在合編資料建置中包括了合編關係新增及維護兩項作業。
A.合編關係新增：
透過考古研究過程中所還原之考古物品，可以利用合編關係的新增作業記錄下遺物彼此之關係與說明，這些資料可以提供未來考古工作重要的參考。
合編過程中須指定每個子項目在該合編資料的順序。
合編後的資料將被當成一筆新的遺物記錄，並且賦予新的遺物登錄號。
合編後的資料必須將第一筆子項目的內容抄錄到新的遺物之中。
合編後的子項目，不能再更動或修改內容。
B.合編關係維護：
主要提供合編關係條件查詢方式，檢索出已存在的合編記錄，並且能修改或刪除該資料。
（3）.遺物管理功能
本功能係提供系統中遺物相關資料之管理作業，包括針對遺物所作的處理作業，如：
科學鑑定分析、維護與修復、保存狀況記錄、媒體檔案維護等；另外，還可以管理遺物資料中所用到的代碼選項。
A.科學鑑定分析：
透過科學鑑定的方法，可以還原出更多遺物自身的資訊，並提供考古研究上重要的參考來源。
B.維護與修復：
出土時的遺物往往在經過多年的自然演化而破碎或是在保存過程中而損壞，因此需要定期的保養及維謢處理，這些記錄可以透過此作業加以管理。
C.保存狀況記錄：
保存狀況的記錄可以詳細知道遺物在每個時期的情形。
D.媒體檔案維護：
在遺物的記錄中，不只是文字資料的記錄，也包括了各個時期所保留之不同類型的媒體資料，也會針對不同業務種類、範圍或品質記錄不同的檔案。
E.代碼選項維護：
在資料欄位中定義許多代碼選項，這些選項能夠提供使用者透過選取方式輸入資料以減少手動輸入的錯誤，並且在介面上也要呈現出階層式的代碼選項關連。
利用代碼選項維護作業可以新增、修改或刪除系統中的所有代碼。
4.
需求規格表
項目編號
項目需求
1
遺物基本資料建置
1.1
遺物基本資料新增
1.2
遺物基本資料維護
2
合編資料
2.1
合編資料新增
2.2
合編資料維護
3
遺物管理功能
3.1
科學鑑定分析
3.2
維護與修復
3.3
保存狀況記錄
3.4
媒體檔案維護
3.5
代碼選項維護
5.
需求回溯表
項目編號
項目需求
是否符合需求項目
1
遺物基本資料建置
1.1
遺物基本資料新增
1.2
遺物基本資料維護
2
合編資料
2.1
合編資料新增
2.2
合編資料維護
3
其他功能
3.1
科學鑑定分析
3.2
維護與修復
3.3
保存狀況記錄
3.4
媒體檔案維護
3.5
代碼選項維護
6.
附錄
1.2002/05/27會議記錄
討論主題：
畫面及操作流程之設計、設計群組功能之可行性討論
出席人員：
史語所-林玉雲；資訊所-范紀文、王祥安、黃國倫
詳細內容：
1、范：
考古發掘計畫系統分析部份，將交由黃國倫負責，王祥安將轉往程式開發設計部份，若分析上有問題亦可請王祥安協助。
2、林：
在畫面上已請陳光祖先生看過流程，在代碼表上，希望可做到有條件式分層、複選的功能，如遺物功能分類選單包含三層，一、二層分類需能有複選的功能；工藝分類、表面遺痕選單亦需複選，不知技術上是否可行？
范：
此部份需求會想辦法解決。
3、王：
是否可將代碼表有樹狀結構部份，標上樹狀結構的代碼，並將最後確認之代碼表寄給資訊所一份。
林：
此部份會修改後寄上。
4、范：
關於中西曆轉換部份，目前僅能對應到西元的部份，西元前的資料（漢代）由於有兩不同之版本，因此目前正在整理漢代的曆法規則中，之後會陸續補上。
林：
這部份對映規則由資訊所負責實作即可。
5、范：
資訊所方面會將軟體需求規格、軟體設計規格、畫面流程設計作成文件給史語所方面簽名確認，畫面部份會加入美工設計（美編），並在史語所確認流程後，估計約一星期美編設計可完成，並再給史語所確認。
6、林：
是否可提供系統群組設定之功能，以達到每個群組可依其喜好勾選欲顯示的欄位，ex貝類、甲骨等群組，以加快大量（數千件）資料登入之速度。
范：
此部份功能，與先前之規畫設計方式差異很大，因此將先把考古發掘之基本系統建置完成，此部份功能再加入考量。
2.2002/5/14會議記錄
討論主題：
畫面及操作流程之設計、選項代碼設計方式之討論
出席人員：
史語所—林玉雲小姐；資訊所—王祥安
詳細內容：
1、林：
記錄類型部份，是否可作成類似樹狀分層的方式選擇（條件式選項方式）？
ex先選擇大陸考古，下再分成漢簡、甲骨。
類似狀況還有工藝分類、材質分類等，這部份資料會再整理完整後寄給資訊所。
王：
目前設計為人工自行挑選，要使用分層方式，需改變設計方式，若分層項目不多則使用原設計方式。
2、林：
系統是否可提供一個欄位可重覆選擇的方式？
ex材料中的複合材質。
王：
目前度量的部份可提供重覆輸入的方式，這樣的方式是否可符合史語所的需求？
林：
此方式可以可接受。
3、王：
關於先前反映系統中代碼與現存代碼不同的部份，之前並未取得相關資料，是否可提供最新的代碼表？
林：
待與陳主任討論後會再寄出。
4、林：
在畫面的安排上，希望將銘刻等資料可在新增遺物基本資料中可點選新增，而不用在遺物資料維護中才可以做到。
王：
流程是可以改變的，不過若要在遺物基本資料中加入其他相關資料新增功能，則必須先將遺物的基本資料新增完後，才能再做其他相關的資料新增功能，另外請將希望畫面的安排方式，作成文件寄給我們。
林：
會在完成文件後寄出。
5、王：
合編遺物需串連的項目有哪些欄位？
林：
需串連的欄位只有遺物編號與清點編號，遺物基本資料則抄錄合編子項中，遺物基本資料最小的那一筆，其他相關的資料則不需抄錄。
6、林：
保存狀況中希望可與媒體檔案串連，使研究者可在保存狀況中看見影像檔。
王：
這部份的功能會再考慮加入。
7、林：
漢代的年代對照表已整理寄出，此部份功能是否可以使用了？
王：
資訊所已收到此資訊，年代對照表由另一位同事正在開發中，目前尚無法使用。
3.
2002/04/30問題討論
討論主題：
史語所林玉雲小姐詢問考古發掘雛型系統之畫面流程問題
詳細內容：
問題一：
請問資料建置之異動記錄如何管理。
包括資料建置時間、編目員之名稱，及最近一次修改時間、編目人員之名稱代碼等。
回答：
建置時間與建置者所用之身份，會由系統自動產生，因此在新增時並不會出現，在查詢時才會出現相關訊息，並且無法修改其值，編目員名稱並非記錄建置者帳號身份，若需對編目員編代碼以方便輸入（即輸入代碼即可秀出編目員相關資料），則可依您的需求改變系統設計以選項方式輸入，請您再斟酌輸入方式。
問題二：
唯一檢查值的欄長多長，結構如何？
以目前典藏號的結構而言，RXXXXXX（約十四萬餘件的容納量），但是以前的典藏人員有一號多件的情形，為避免重新給號的困擾，以在原號後加「-」區分不同器物為處理的原則，例如R001257共有10件鏃，以R001257-01，R001257-02一直到R001257-10加以區分，有些原典藏號有上百件的情形，因此唯一檢查值是否以RXXXXXX-XXX為檢查結構的元素，請問有何高見？
回答：
目前遺物登入號設定長度為20個Char，對於您所說的情況應足以應付，若您覺得不夠長，目前尚可修改長度，但系統建置完成後即無法修改，至於輸入結構目前設定只要是字元即可輸入，結構部份則由史與所方面決定。
唯一值檢查的功能是設計用來檢查輸入之編號是否已存在系統中，以避免重覆輸入。
問題三：
請問權威檔是否已有處理的機制？
如考古學文化及歷史時期各朝代各王的處理原則。
回答：
權威檔部份將待基礎系統建置好後再開發相關部份，目前以開發基礎系統優先進行。
問題四：
日期的處理方式，中西曆對照的機制，是否會處理？
請系統化處理所有日期有關欄位，並參考國際標準組織的格式？
回答：
中西曆對照的機制系統將會處理，輸入日期格式也會使用標準輸入格式，以西曆為主，再秀出中曆對照。
問題五：
請將「登錄日期」以下各欄一直到「備註」合併為一大項中的各欄。
另，清點編號、收藏來源等項目，原METADATA表格中應有很多種類，請提供選項及查詢的功能。
欄位內容如附：
回答：
合併欄位為一大項將立即處理，清點編號與收藏來源部份將修正為選項輸入方式亦會對照Metadata表格後處理。
清點編號
類型
紅號，田野登記號，y號，簡號，其他
收藏來源
取得方式
採集，發掘，購買，受贈，接收，託管，交換，其他
來源者
角色
交換，託管，受贈
問題六：
合編資料的建置，除了建立和子目的關係外，如何重新編目合編以後遺物，包括品名、年代…度量、科學分析等等和一般遺物資料建置程序無異的流程，簡言之，合編後需再重新描述所有資料建置的欄位。
回答：
依先前討論之結果，合併資料建立後，部份資料將由系統自動串連合編子項後產生，哪些欄位需由系統自動串連產生，煩請以文件告知我們，我們將會由系統自動處理，由系統產生的資料將不需再重新描述。
4.
2002/04/01會議記錄
討論主題：
目前工作進度報告、工作討論-畫面及操作流程之設計、計畫之遭遇問題及困難點討論、約定下次討論時間項目
出席人員：
史語所—林玉雲小姐、陳秀慧小姐；資訊所—范紀文、王祥安
詳細內容：
1、林：
畫面部份可將同一類型資料放在一個區域，如工藝方法、名稱、描述放在同一方框中，此部份會再考慮那些要放在一起。
王：
此點可以再改進。
2、林：
在輸入日期時是否能有個固定的格式限定使用者，例如MM-DD-YYYY。
王：
此點可以考慮加入控制。
3、林：
媒體檔案部份，可能會在很多功能時會用到，例如：
科學鑑定分析時可能會拍攝，維護修復時可能會拍攝，應將此功能於其他畫面時出現。
王：
此部份可加入在需要媒體檔案功能之頁面加入功能操作。
4、林：
當人員進行新增修改時，是否可以記錄此記錄的修改者、修改時間等資訊，以方便日後追查。
王：
此部份可在資料庫中加入記錄異動之欄位解決。
5、林：
在銘刻之原文部份，是否可以有直排（書）、斷行的輸入功能，張復老師所開發的功能，似乎無法達到此一需求。
王：
這部份的技術個人無法了解是否有此技術，需再進行了解
6、林：
在基本資料中，先前有記錄部份度量的資料（以目測方式記錄），目前的畫面中並無此項。
王：
在資料庫欄位中並無看到此部份資料，會再回去檢查相關資料。
7、在權限管理部份，是否以點選每個功能時要求輸入帳號密碼的方式管理權限，因位權限控制可能會非常複雜，若以畫面區隔可能要有數十個版面。
王：
建議是在一開始即檢查登錄資料，限定使用者操作權限的方式，方便使用者操作。
8、林：
合編關係部份，合編遺物編號應如何製定？
當已產生合編關係之遺物，在操作系統時說明該遺物是否有合編記錄之功能，另外，當合編遺物編號新建立時，需能自動產生遺物相關記錄，如遺物登錄號部份是將遺物子項中所有的遺物登錄號串連起來等等。
王：
合編遺物編號之製定規則，需由史語所這邊來訂定，只要能與遺物之R號區分並有唯一性即可，系統並無特定要求。
可加入當遺物為合編子項時，提供使用者相關訊息之功能，當新增遺物合編編號時，串連合編子項部份，需可慮串連後之長度是否超過系統限制，若只用於顯示而不去修改與儲存之方式才可行。
9、陳：
漢簡計畫已開始進行，目前正討論與文物陳列館這邊的資料庫系統設計問題，目前有兩種看法，一是使用文物陳列館這邊的資料庫，一是自行開發資料庫再透過連結方式連結到文物陳列管之資料庫，請給與技術上的建議。
王：
由於漢簡計畫今年10月需有系統成果展示，即始獨自開發資料庫，時程上已經很趕，若要整合文物陳列管資料庫恐有困難，若要單獨開發資料庫，需考慮資料間的主從關係，兩資料庫間欄位的對映問題，即資料交換之方式。
下次開會時間採動態方式約定，但時間以不超過一個月為原則。
5.
2002/03/12會議記錄
討論主題：
今年度計畫工作項目、今年度計畫工作時程安排、目前人力及工作
出席人員：
史語所—陳光祖主任、林玉雲小姐；資訊所—范紀文、王祥安
進度報告、計畫之遭遇問題及困難點討論、約定下次討論時間項目
詳細內容：
1、范：
目前工作的方式，是以四層架構，由遺物層先做，做完之後再往上發展。
王：
目前工作的時程表如表所列，基本上的程序是分成四層，每層的程序是先進行著錄資訊了解及系統分析，之後進行典藏資料管理系統之設計及客製化，最後再進行客製化檢索介面工作，每一層階依此程序，而時間上都是連續的進行。
2、林：
目前依畫面流程來看，似乎是切成數個子Table，與原先在同一大Table的概念有的不符合。
范：
資料在同一大Table呈獻的方式是不可能這麼做，我們會參考書目後端管理系統的作法，流程與展現上可以再討論、修改，以功能區的方式設計管理介面。
至於美工方面則需由史語所方面協助。
3、陳：
GIS系統加入的時機為何？
是否可以在進入遺址層的時候開始共同運作？
范：
需先等資料架構確認時才可與他們討論，因此當做到遺址層時，應該可以開始討論，估計七、八月份時可與GIS小組一同討論，兩個系統整合的問題。
4、林：
關於加強影像處理能力系統部份與接圖系統部份，何時可以完成？
范：
此部份工作由實驗室另一位同仁在開發，將開發大型影像圖檔無段式縮放瀏覽的程式、開發自動化影像接合系統，預計7、8月份後可以使用。
5、陳：
目前資訊所參與此計畫之人力分配情況為何？
由於本系統複雜度高，系統又才起步，是否可以增加人力？
范：
目前計畫人力，主要由范紀文與王祥安負責，王祥安負責資料庫管理系統之開發，圖檔部份由呂音儀小姐負責開發，本人也會協助處理本計畫。
6、林：
在3D技術上，洪一平老師之新版系統，是否可整合？
范：
新系統可整合至本平台沒有問題。
7、林：
以後的開會時間為何？
范：
每個月固定一次或兩次開會討論計畫進度，若有需要則視需要召開會議，目前固定每個月第一個星期的星期一下午2點開會。
8、林：
關於開發經驗分享，是否可將過程文件化，並在Metadata部份，是否請計算機中心的人員來一起記錄？
陳：
可請他們一起來看系統開發的過程，或許可以每隔一段時間請他們來開會或請他們配合。
范：
我們會將著錄資訊、需求分析、系統設計等的資料文件化、並在最後時可將系統設計與計畫的經驗共同發表（由玉雲、祥安、紀文共同撰寫）。
9、林：
系統界面部份，需區分管理者模式、使用者模式，何時可以確認？
陳：
在系統上可能需要多次修改。
范：
當系統架構確定後，可以再進行系統流程、界面的修改，再一、二星期後可以先初部確認界面，系統會再依需求不斷改進。
10.陳：
我們將提供本系統給中國大陸使用，在系統轉移上是否會有問題？
是否可請范紀文提供系統在大陸建置所需的人力、時間、軟硬體需求等規格。
范：
會幫忙協助作出此規畫書。
11.林：
關於甲骨、漢簡計畫，將可能同步開發，在資料使用上是否有甚麼建議？
王：
建議在資料架構上應由雙方同意目前資料架構，並確認資料之主從關係與存取權限。
12.下次會議的時間：
約定為四月一日下午兩點。
升级会员 