本節比較 RPSRS 與 SRS 初期建議架構之差異，找出 SRS 初期建議架構不足 之處，並以數位典藏特性為前提，與 DAAL 系統分析師討論實際需求後，評估 應加入哪些 RPSRS 之章節與內容。針對 SRS 初期建議架構在各章節名稱、順序 及內容，作適當之修改，以成為更完備之數位典藏 SRS 建議標準。
本節先依照 RPSRS 之章節順序，重點式簡介各章節內容，並說明與 SRS 初 期建議架構之對應情形及各章節的建議。最後再依照初期建議之章節順序，說明 初期建議與 RPSRS 之架構對應。
2.1. RPSRS 1. Introduction 與初期建議架構之比較
RPSRS 1. Introduction 提供整個 SRS 的概觀(overview)，包含(1) Purpose、(2) Scope、(3) Definitions, acronyms, and abbreviations、(4) References、(5) Overview 共五節，表 1 顯示其與 SRS 初期建議架構之對應。以下重點式列出 RPSRS 1.
Introduction 內容，並找出其與 SRS 初期建議架構之異同，以便於提出新的 SRS 建議標準。
2.1.1. RPSRS Purpose
RPSRS Purpose 摘要如下：
a) Delineate the purpose of the SRS;
b) Specify the intended audience for the SRS.
本節描述文件目的及預期的讀者，但 SRS 初期建議架構並無相對應之章節，
故建議加入一節「目的」於數位典藏 SRS 標準中，以說明文件目的及預期的讀 者。此外，由於數位典藏計畫依照典藏文物主題、計畫性質及委託單位等分為不 同的子計畫，故 SRS 初期建議架構之「1.1. 標的軟體系統摘述」之計畫名稱及 委託人資訊應移至此處。
表1. RPSRS 1. Introduction 與 SRS 初期建議架構之對應
RPSRS SRS 初期建議架構
1.1. Purpose
1.2. Scope 1.1. 標的軟體系統摘述 1.2. 著錄範圍
2.1. 目標
1.3. Definitions, acronyms, and abbreviations 1.3. 定義與縮寫符號 1.4. References 1.4. 參考資料
1.5. Overview 2.1.2. RPSRS Scope
RPSRS Scope 摘要如下：
a) Identify the software product(s) to be produced by name (e.g., Host DBMS, Report Generator, etc.);
b) Explain what the software product(s) will, and, if necessary, will not do;
c) Describe the application of the software being specified, including relevant benefits, objectives, and goals;
d) Be consistent with similar statements in higher-level specifications (e.g., the system requirements specification), if they exist.
本節描述產品所能提供之功能、目的及優點等，它與 SRS 初期建議架構之 對應情形如下：
(1) SRS 初期建議架構之「1.1. 標的軟體系統摘述」說明系統名稱及系統建 置目的，分別與上述 a)及 c)對應。
(2) SRS 初期建議架構之「1.2. 著錄範圍」說明系統之著錄範圍，如系統所 處理之典藏文物特性、文物出土地及系統資料來源等，與上述 b)對應。
(3) SRS 初期建議架構之「2.1. 目標」說明建置系統目的及系統欲達成的目 標，與上述 c)對應。
因此，建議將 SRS 初期建議架構之「1.1. 標的軟體系統摘述」、「1.2. 著錄 範圍」與「2.1. 目標」合併成一節，節名為「著錄範圍」。
2.1.3. RPSRS Definitions, acronyms, and abbreviations
RPSRS Definitions, acronyms, and abbreviations 摘要如下：
This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS.
本節對應於 SRS 初期建議架構之「1.3. 定義與縮寫符號」，兩者均定義出 現於 SRS 的專有名詞及縮寫符號，故應保留 SRS 初期建議架構之「1.3. 定義與 縮寫符號」，不需修改。
2.1.4. RPSRS References
RPSRS References 摘要如下：
a) Provide a complete list of all documents referenced elsewhere in the SRS;
b) Identify each document by title, report number (if applicable), date, and publishing organization;
c) Specify the sources from which the references can be obtained.
本節對應於 SRS 初期建議架構之「1.4. 參考資料」，兩者均列出 SRS 所參 考引用之資料清單，並說明各參考資料之標題、出版日期及發行組織等資訊。故 應保留 SRS 初期建議架構之「1.4. 參考資料」，不需修改。
2.1.5. RPSRS Overview
RPSRS Overview 摘要如下：
a) Describe what the rest of the SRS contains;
b) Explain how the SRS is organized.
本節說明 SRS 後續章節內容及文件組織等資訊。SRS 初期建議架構並無相 對應之章節，建議應加入一節「綜覽」於數位典藏 SRS 標準中，說明後續章節 內容及組織。
2.1.6. 小結
表 2 顯示 RPSRS 第 1 節與數位典藏 SRS 建議標準之對應。
表2. RPSRS 第 1 節與數位典藏 SRS 建議標準之對應
RPSRS 數位典藏 SRS 建議標準 1. Introduction 1. 前言
1.1. Purpose 1.1. 目的 1.2. Scope 1.2. 著錄範圍
1.3. Definitions, acronyms, and abbreviations 1.3. 定義與縮寫符號 1.4. References 1.4. 參考資料
1.5. Overview 1.5. 綜覽 2.2. RPSRS 2. Overall description 與初期建議架構之比較
RPSRS 2. Overall description 描述影響產品及其需求的一般因素，包含(1) Product perspective、(2) Product functions、(3) User characteristics、(4) Constraints、
(5) Assumptions and dependencies、(6) Apportioning of requirements 共六節，表 3 顯示其與 SRS 初期建議架構之對應。以下重點式列出 RPSRS 2. Overall description 內容，並找出其與 SRS 初期建議架構之異同，以便於提出新的 SRS 建議標準。
表3. RPSRS 2. Overall description 與 SRS 初期建議架構之對應 RPSRS SRS 初期建議架構 2.1. Product perspective 2.2. 系統開發環境
2.5. 與相關系統或專案之關係 3.3. 人機界面
2.2. Product functions
2.3. User characteristics 2.3. 系統用戶種類特性 2.4. Constraints
2.5. Assumptions and dependencies 2.6. Apportioning of requirements 2.2.1. RPSRS Product perspective
RPSRS Product perspective 摘要如下：
This subsection of the SRS should put the product into perspective with other related products. If the product is independent and totally self-contained, it should be so stated here. If the SRS defines a product that is a component of a larger system, as frequently occurs, then this subsection should relate the requirements of that larger system to functionality of the software and should identify interfaces between that system and the software.
A block diagram showing the major components of the larger system, interconnections, and external interfaces can be helpful.
This subsection should also describe how the software operates inside various constraints. For example, these constraints could include
a) System interfaces;
b) User interfaces;
c) Hardware interfaces;
d) Software interfaces;
e) Communications interfaces;
f) Memory;
g) Operations;
h) Site adaptation requirements.
本節說明與其他產品之間的相互關係，並描述軟體運作之限制，如使用者介
與上述 b)對應。
因此，建議將 SRS 初期建議架構之「2.2. 系統開發環境」、「2.5. 與相關 系統或專案之關係」及「3.3. 人機界面」合併成一節，節名為「產品面面觀」。
2.2.2. RPSRS Product functions
RPSRS Product functions 摘要如下：
This subsection of the SRS should provide a summary of the major functions that the software will perform. For example, an SRS for an accounting program may use this part to address customer account maintenance, customer statement, and invoice preparation without mentioning the vast amount of detail that each of those functions requires.
Sometimes the function summary that is necessary for this part can be taken directly from the section of the higher-level specification (if one exists) that allocates particular functions to the software product. Note that for the sake of clarity
a) The functions should be organized in a way that makes the list of functions understandable to the customer or to anyone else reading the document for the first time;
b) Textual or graphical methods can be used to show the different functions and their relationships.
本節以文字、表格及圖形等方式簡介系統功能，但SRS初期建議架構並無相 對應之章節。故建議應加入一節「產品功能」於數位典藏SRS標準，以提供功能 摘要。
2.2.3. RPSRS User characteristics
RPSRS User characteristics 摘要如下：
This subsection of the SRS should describe those general characteristics of the intended users of the product including educational level, experience, and technical expertise.
本節對應於 SRS 初期建議架構之「2.3. 系統用戶種類特性」，兩者均描述 系統使用者特性，如教育程度、專業知識等。故 SRS 初期建議架構之「2.3. 系 統用戶種類特性」內容不需修改，節名則改為「用戶種類特性」。
2.2.4. RPSRS Constraints
RPSRS Constraints 摘要如下：
This subsection of the SRS should provide a general description of any other items that will limit the developer’s options. These include
a) Regulatory policies;
b) Hardware limitations (e.g., signal timing requirements);
c) Interfaces to other applications;
d) Parallel operation;
e) Audit functions;
f) Control functions;
g) Higher-order language requirements;
h) Signal handshake protocols (e.g., XON-XOFF, ACK-NACK);
i) Reliability requirements;
j) Criticality of the application;
k) Safety and security considerations.
本節描述其他會限制開發者之項目，包含硬體限制、高階語言需求、可靠性 需求等，但 SRS 初期建議架構並無相對應之章節。故建議加入一節「限制」於 數位典藏 SRS 標準中，說明系統在上述各方面之限制。
2.2.5. RPSRS Assumptions and dependencies
RPSRS Assumptions and dependencies 摘要如下：
This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS. For example, an assumption may be that a specific operating system will be available on the hardware designated for the software product. If, in fact, the operating system is not available, the SRS would then have to change accordingly.
本節列出會影響軟體需求之因素，如特殊的作業系統。SRS 初期建議架構並 無相對應之章節。故建議加入一節「假設與相依性」於數位典藏 SRS 標準中。
2.2.6. RPSRS Apportioning of requirements
RPSRS Apportioning of requirements 摘要如下：
This subsection of the SRS should identify requirements that may be delayed until future versions of the system.
本節說明可延後至未來才製作的需求。SRS 初期建議架構並無相對應之章 節，故建議應加入一節「未來需求」於數位典藏 SRS 標準中，說明可延後的需 求。
2.2.7. 小結
表 4 顯示 RPSRS 第 2 節與數位典藏 SRS 建議標準之對應。
表4. RPSRS 第 2 節與數位典藏 SRS 建議標準之對應 RPSRS 數位典藏 SRS 建議標準 2. Overall description 2. 整體概述
2.1. Product perspective 2.1. 產品面面觀 2.2. Product functions 2.2. 產品功能 2.3. User characteristics 2.3. 用戶種類特性 2.4. Constraints 2.4. 限制
2.5. Assumptions and dependencies 2.5. 假設與相依性 2.6. Apportioning of requirements 2.6. 未來需求 2.3. RPSRS 3. Specific requirements 與初期建議架構之比較
RPSRS 3. Specific requirements 詳細描述軟體需求，其詳細程度須足以讓設 計師設計出滿足這些需求的系統，包含(1) External interface、(2) Functional requirements、(3) Performance requirements、(4) Logical database requirements、(5) Design constraints、(6) Software system attributes 共六節，表 5 顯示其與 SRS 初期 建議架構之對應。以下重點式列出 RPSRS 3. Specific requirements 內容，並找出 其與 SRS 初期建議架構之異同，以便於提出新的 SRS 建議標準。
表5. RPSRS 3. Specific requirements 與初期建議架構之對應 RPSRS SRS 初期建議架構 3.1. External interface 2.4. 數位化規格 3.2. Functional requirements 3.1. 功能性需求 3.3. Performance requirements
3.4. Logical database requirements 3.5. Design constraints
3.6. Software system attributes 3.2. 非功能性需求 2.3.1. RPSRS External interface
RPSRS External interface 摘要如下：
This should be a detailed description of all inputs into and outputs from the software system. It should complement the interface descriptions in 2. Overall description and should not repeat information there.
It should include both content and format as follows:
a) Name of item;
b) Description of purpose;
c) Source of input or destination of output;
d) Valid range, accuracy, and/or tolerance;
e) Units of measure;
f) Timing;
g) Relationships to other inputs/outputs;
h) Screen formats/organization;
i) Window formats/organization;
j) Data formats;
k) Command formats;
l) End messages.
本節詳細描述軟體系統之輸入及輸出，包含項目名稱、與其他輸入及輸出的 關係、資料格式、命令格式等，並與 2. Overall description 所描述之介面資訊互 補。SRS 初期建議架構與之對應的章節為「2.4. 數位化規格」。
2.3.2. RPSRS Functional requirements
RPSRS Functional requirements 摘要如下：
Functional requirements should define the fundamental actions that must take place in the software in accepting and processing the inputs and in processing and generating the outputs. It may be appropriate to partition the functional requirements into subfunctions or subprocesses. This does not imply that the software design will also be partitioned that way.
These include
a) Validity checks on the inputs b) Exact sequence of operations
c) Responses to abnormal situations, including 1) Overflow
2) Communication facilities 3) Error handling and recovery d) Effect of parameters
e) Relationship of outputs to inputs, including 1) Input/output sequences
2) Formulas for input to output conversion
本節對應於 SRS 初期建議架構之「3.1. 功能性需求」，定義軟體各功能對 輸入及輸出資料之處理過程，包含檢查輸入資料的正確性、操作流程、異常現象 的回報等。故 SRS 初期建議架構之「3.1. 功能性需求」內容不需修改。
2.3.3. RPSRS Performance require ments
RPSRS Performance requirements 摘要如下：
This subsection should specify both the static and the dynamic numerical requirements placed on the software or on human interaction with the software as a whole. Static numerical requirements may include the following:
a) The number of terminals to be supported;
b) The number of simultaneous users to be supported;
c) Amount and type of information to be handled.
Dynamic numerical requirements may include, for example, the numbers of transactions and tasks and the amount of data to be processed within certain time periods for both normal and peak workload conditions.
本節說明靜態與動態之數值需求，包含可支援之終端機個數、同時操作人數 及資料數及型態，在 SRS 初期建議架構並無相對應之章節。由於數位典藏系統 應支援網路多人線上同時操作之能力，建議加入一節「效能需求」於數位典藏 SRS 標準中。
2.3.4. RPSRS Logical database requirements
RPSRS Logical database requirements 摘要如下：
This should specify the logical requirements for any information that is to be
This should specify the logical requirements for any information that is to be