軟體工程文件規範--前景文件（轉）

1. 介紹

　　這一部分應該提供整個前景文件的概述，它包含以下幾部分：

　　1.1 前景文件的目的

　　文件目的是收集、分析、定義高層使用者需要和產品特徵。集中於目標使用者所需要的能力以及為什麼存在這些需要。有關係統如何滿足這些需要的特定需求應該放在“軟體需求規格說明”和“用例規格說明”中。

　　1.2 產品綜述

　　陳述該應用系統的目的、版本以及要交付的新特徵。這一部分應該做以下幾件事：

　　1）確定要建立或增強的產品或應用系統；

　　2）提供有關產品將做什麼以及需要時不做什麼的一般性描述；

　　3）描述產品的應用，包括與相關的利益、目的、目標。

　　1.3 參考

　　這一部分應該做以下幾件事：

　　1）列出在前景文件中引用的其他文件的清單；

　　2）標明每個文件的題目、報告號（如果有的話）、日期和出版機構；

　　3）指定該參考獲取的來源；

　　4）這個資訊可透過引用附錄或其它文件來提供。

2. 使用者描述

　　為了有效地提供滿足客戶需要的產品和服務，理解完成這項工作時所面對的挑戰是很有必要的。這一部分應該剖析應用系統的使用者和限制使用者生產的關鍵問題。這一部分不能用於陳述特定需求，而是提供有關為什麼需要第5部分指定的需求的背景和理由。

　　2.1 使用者/市場統計

　　總結激勵產品決策的主要市場統計；描述和定位目標；利用潛在使用者數量或客戶願意花在試圖滿足你的產品或增強所完成的需要上的錢的數量來預測市場的大小和增長率；回顧主要的行業趨勢和技術；回答以上戰略問題：你的機構在這些市場中的聲譽如何？你希望它做成什麼樣？這個產品或服務如何支援你的目標？

　　2.2 使用者剖析

　　描述系統中每個不同的使用者。使用者的型別可能是從權威到新手差距很大。例如，權威可能需要一個複雜、靈活的支援跨平臺工具，而一個新手可能需要一個易於使用、使用者友好的工具。對使用者的全面剖析覆蓋每種使用者的以下題目：

　　1）技術背景和複雜程度；

　　2）主要職責；

　　3）為誰提交使用者產品；

　　4）使使用者的工作更容易或更困難的趨勢；

　　5）影響成功的問題；

　　6）目標使用者對成功的定義以及使用者如何等到回報。

　　2.3 使用者環境

　　目標使用者的工作環境的詳細描述。以下是一些建議：

　　1）完成該任務涉及多少人？是否會變化？

　　2）任務的週期是多長？其中每項活動需要多少時間？是否會變化？

　　3）是否有一些獨特的環境約束：移動的、室外的、飛機上的，等等？

　　4）現在正在使用哪種系統平臺？未來的平臺是什麼？

　　5）正在使用其他什麼應用系統？你的應用系統是否能與這些系統整合？

　　2.4 關鍵使用者需要

　　列出使用者認為的關鍵問題或需要。為每個問題澄清以下內容：

　　1）這個問題的原因是什麼？

　　2）現在是怎麼解決的？

　　3）使用者預期的解決方案是什麼？

　　重要的是理解使用者對解決每個問題所放的相對重要性。分級和累積投票技術可以說明

　　必須解決的問題以及每個問題強調的事物。

　　2.5 替代品和競爭對手

　　確定使用者認為目前可得到的替代品。可包括購買對手的產品、構建一個全部是自己的解決方案或者維持現狀。列出所知的已有的以及即將得到的競爭對手的產品。包括終端使用者所理解的每位對手的強項和弱項。

　　2.5.1 競爭對手1

3. 產品綜述

　　這一部分對產品能力、到其他應用系統的介面以及系統配置等等提供一個高層檢視，通常由以下三個部分組成。

　　3.1 產品前景

　　這部分應該合理地把該產品與其他相關產品及使用者的需求放在一起。如果產品是獨立的而且是完全獨立的，就在這裡說明它；如果產品是一個大型系統的元件之一，那麼這一部分應該說明系統之間如何互動而且應該確定相關的介面。一種展示大型系統主要元件、互連及外部介面的簡單方法就是利用框圖。

　　3.2 產品定位陳述

　　提供一個整體陳述，從最高層次總結產品在市場上的獨特定位。Moore（1991）稱此為產品定位陳述，並推薦以下格式：


　　為了 （目標客戶）
　　誰 （陳述需要或機遇）
　　產品名 是一個（產品分類）
　　它 （對主要優點的陳述，即驅動購買的原因）
　　不像 （主要競爭替代品）
我們的產品 （對主要區別的陳述）


　　產品定位陳述向所有相關人員說明了應用系統的意圖以及專案的重要性。

　　3.3 能力總結

　　總結產品將提供的主要優點和特徵。例如，客戶支援系統的前景文件可能會使用這一部分強調問題建檔、路電和狀態報告—不提及各個功能需求的細節。

　　組織特徵，以便清單能夠被客戶或所有第一次閱讀文件的人理解。一個簡單的表列出主要的優點及其所支援的特徵。

　　客戶支援系統


　　客戶收益 支援特徵
收益1 特徵
收益2 特徵
收益3 特徵


　　3.4 假定和相關條件

　　列出所有一旦變更將影響整個產品前景的假設條件。例如，某個假定條件可能指出，指定用於軟體產品的硬體可得到某個特定的作業系統，如果該作業系統得不到，則前景必須變更。

　　3.5 成本和定價

　　對於將銷售給外部客戶的產品以及許多機構內使用的應用系統，成本和定價將直接影響應用系統的定義和實現。在這一部分，把所有成本和相關的定價約束記錄下來。例如，分銷成本（磁碟、CD-ROM、CD母盤的編號）或者其他貨品銷售成本（手冊、打包）根據應用的性質對於專案的成功可能無關也可能有實質性影響。

4. 特徵屬性

　　與需求一樣，特徵也有屬性，提供附加的專案資訊，用於評估、跟蹤、劃分優先順序、管理為實現提出的項。這一部分陳述所有建議在前景文件中使用的屬性，描述所選擇的屬性及其意義，使各方都能更好地理解每個特徵的背景。

　　4.1 狀態

　　在專案管理團隊協商和評審之後確定。狀態資訊在專案基線定義過程中跟蹤程式。

　　1）建議的（proposed）：描述正在對該特徵進行討論，但還沒有得到“正式渠道”的稽核與採納，“正式渠道”可以是一個由專案團隊、產品管理、使用者或客戶團隊的代表組織的工作小組；

　　2）批准的（approved）：它的能力被斷定是有用和可行的，得到正式渠道的認可並加以實現；

　　3）收編的(incorporated)：已經在某個特定時間收編入產品基線的特徵；

　　4.2 優先順序

　　產品優先順序是由營銷人員、產品經理或商業分析人員設定的。根據特徵對終端使用者的相對優先順序把它們劃分等級開啟了一個與客戶、分析人員以及開發團隊成員之間的對話。優先順序用於管理廣度和確定開發優先順序。一種優先順序劃分模式如下：

　　1）關鍵的（critical）：本質特徵。實現的失敗意味著系統將不能滿足客戶的需要。所有關鍵的特徵必須在釋出中實現，否則進度將推遲。

　　2）重要的（important）：對於大多數應用的系統效率和效力都重要的特徵。該功能無法容易地用其他方式實現。如果缺少重要的特徵，可能影響客戶或使用者的滿意程度，甚至影響收益，但釋出不會因此而推遲；

　　3）有用的（useful）：在不太典型的應用中有用的特徵，但不經常使用或者有其他合理的有效變通。如果釋出中沒有這類特徵也不會對客戶滿意程度或收益造成重大的影響

　　4.3 工作量

　　由開發團隊設定，用於管理廣度和確定開發優先順序。由於有些特徵比其他特徵要求更多的時間和資源，因此對各特徵採用團隊數量或人周、程式碼行、功能點等等進行評估將是預測複雜度的最好辦法，從而可對在給定時間範圍內能完成什麼不能完成什麼有一個預期。

　　4.4 風險

　　由開發團隊設定，設定的依據是專案經歷意外事件的可能性，如成本過高、進度延遲甚至專案被撤消等。許多專案經理發現，把風險分為高、中、低就已經足夠了，儘管還可以再細一些。風險通常可以透過度量專案團隊進度預測的不確定性（範圍）進行間接地評估。

　　4.5 穩定性

　　由分析人員和開發團隊設定，設定的依據是特徵變更的可能性或團對變更特徵的理解。這個資訊有助於建立開發優先順序或確定下一步中哪些附加啟發是適當的。

　　4.6 目標當布

　　記錄特徵將首先出現在哪一個產品版本中。這個域可用於把特徵分配到特定的基線版本中。當把目標版本與狀態域結合起來時，團隊可以建議、記錄和討論該版本的各個特徵，而不必把它們提交給開發。只有一些狀態被設定為“收編的”特徵並且其目標版本被定義的特徵才能實現。在發生廣度管理時，目標版本的版本號會不斷增加，於是該項仍然存在於前景文件中，但被安排到以後的版本中去。

　　4.7 分配給

　　在許多專案中，把特徵分配給“特徵團隊”，負責進一步啟發、書寫軟體需求和實現。這個簡單清單將幫助所有專案團隊成員更好地瞭解自己的職責。

　　4.8 原因

　　這一文字域用來跟蹤所要求特徵的來源。特徵的存在有很多特定的理由。這個域記錄了特徵的解釋或對解釋的引用。例如，引用可以是產品需求規格說明的頁號和行號，或是重要客戶面談錄影帶上的一個分鐘標誌。

5. 產品特徵

　　這一部分記錄產品特徵。特徵提供了給使用者帶來利益所需要的系統能力，每個特徵都提供了一個滿足使用者需要的服務。例如，問題跟蹤系統的一個特徵可能是“提供走勢報告”的能力，趨勢報告可能繼續支援一個“更好理解專案狀態”的需要。

　　因為前景文件是由許多涉及人員稽核的而且是達成共識的基礎。所以特徵應該用用肪的自然語言描述。特徵描述應該簡短、精練，通常是1-2個句子。

　　為了有效管理應用的複雜度，我們建議：對於任何新系統或在原有系統上加強的系統，把能力抽象到較高層次產生大約25-99個特徵。這些特徵是產品定義、廣度管理和專案管理的基本基礎。每個特徵都可以在後面的規格說明中被更詳細地說明。

　　在整個這一部分中，每一個特徵都應該是使用者、操作者或其他外部系統可以感知的。

　　5.1 特徵＃1

　　5.2 特徵＃2

6. 關鍵用例

　　描述一些關鍵用例，可以是對體系結構有意義或最方便幫助讀者理解系統如何使用的用例。

7. 其他產品需求

　　7.1 可應用標準

　　列出產品必須符合的標準，如法律和規章（FDA、FCC）、通訊標準（TCP/IP、ISDN）、平臺相容標準（Windows、UNIX）以及質量和安全標準（UL、ISO、CMM）。

　　7.2 系統需求

　　定義支援應用所必須的所有系統需求。包括支援的主機作業系統、網路平臺、配置、記憶體、外設以及軟體。

　　7.3 許可和安裝

　　許可和安裝問題對於開發工作有直接影響。例如，支援序列號、口令安全或網路許可證的需要必須建立其他開發過程中必須考慮的附加的系統需注。安裝需求也會影響編碼或者產生開發獨立安裝軟體的需求。

　　7.4 效能需求

　　效能問題包括使用者負載因素、頻寬或通訊能力、吞吐量、準確度、可靠性或在某些負載條件下的響應時間等。

8. 建檔需求

　　這一部分描述所有支援成功地部署系統必須開發的文件

　　8.1 使用者手冊

　　描述使用者手冊的目的和內容。討論其需要的長度、詳盡程式、索引和詞彙表的需要、指南及參考手冊策略，等等。還要指定格式和列印約束。

　　8.2 線上幫助

　　許多應用系統都提供一個線上的幫助系統來輔助使用者。這些系統的本質是應用系統開發所特有的，因為它們把程式設計（如超連結）和技術書寫（如組織和表示）結合起來。許多人發現在線上幫助系統是專案中的專案，它從廣度管理和計劃活動中直接受益。

　　8.3 安裝指南、配置和自述檔案

　　對於一個全面的解決方案來說，有一個包括安裝指令和配置指南的文件非常重要，而一個自述（Read Me）檔案也通常作為標準元件而存在。自述檔案中可能包括一個“本版本的新增內容”部分以及一個與以前版本的相容問題的討論。許多使用者還希望在自述檔案中說明所有已知的錯誤和變通方法。

　　8.4 標記和打包

　　當今最新的藝術化的應用系統提供了一個從安裝選單提示的產品打包和裝載清單、炫耀的螢幕、幫助系統、GUI對話等開始的一致的外觀和感覺。這一部分定義要整合到程式碼中的標記的型別和需要。包括版本和專利說明、公司商標、標準化圖示及其他圖形無素等。

9. 詞彙表

　　詞彙表定義所有專案特有的術語。包括所有閱讀文件的使用者或其他人無法理解的縮寫和簡寫。

[@more@]