1、軟件工程文檔規范-前景文檔摘要本文是軟件工程文檔之一：前景（visio）文檔的寫作規范， 前景文檔以客戶的語言描述總體的需求說明，它與需求規格說明書是相互配合的。（2002-10-2209:00:45）By風過留楓1. 介紹這一部分應該提供整個前景文檔的概述，它包含以下幾部分：1.1前景文檔的目的文檔目的是收集、分析、定義高層用戶需要和產品特征。集中于目標用戶所需要的能力以及為什么存在這些需要。有關系統如何滿足這些需要的特定需求應該放在“軟件需求規格 說明”和“用例規格說明"中。1.2產品綜述陳述該應用系統的目的、版本以及要交付的新特征。這一部分應該做以下幾件事：1）確定要創建或增強

2、的產品或應用系統；2）提供有關產品將做什么以及需要時不做什么的一般性描述；3）描述產品的應用，包括與相關的利益、目的、目標。1.3參考這一部分應該做以下幾件事：1）列出在前景文檔中引用的其他文檔的清單；2）標明每個文檔的題目、報告號（如果有的話）、日期和出版機構；3）指定該參考獲取的來源；4）這個信息可通過引用附錄或其它文檔來提供。2. 用戶描述為了有效地提供滿足客戶需要的產品和服務， 理解完成這項工作時所面對的挑戰是很有必要的。 這一部分應該剖析應用系統的用戶和限制用戶生產的關鍵問題。 這一部分不能用于陳述特定需求，而是提供有關為什么需要第 5 部分指定的需求的背景和理由。2.1 用戶 /

3、市場統計歸納總結激勵產品決策的主要市場統計； 描述和定位目標； 利用潛在用戶數量或客戶愿意花在試圖滿足你的產品或增強所完成的需要上的錢的數量來預測市場的大小和增長率； 回 顧主要的行業趨勢和技術； 回答以上戰略問題： 你的機構在這些市場中的聲譽如何？你希望它做成什么樣？這個產品或服務如何支持你的目標？2.2 用戶剖析描述系統中每個不同的用戶。 用戶的類型可能是從權威到新手差距很大。 例如， 權威可能需要一個復雜、 靈活的支持跨平臺工具， 而一個新手可能需要一個易于使用、 用戶友好的 工具。對用戶的全面剖析覆蓋每種用戶的以下題目：1）技術背景和復雜程度；2）主要職責；3）為誰提交用戶產品；4）使

4、用戶的工作更容易或更困難的趨勢；5）影響成功的問題；6）目標用戶對成功的定義以及用戶如何等到回報。2.3 用戶環境目標用戶的工作環境的詳細描述。以下是一些建議：1）完成該任務涉及多少人？是否會變化？2）任務的周期是多長？其中每項活動需要多少時間？是否會變化？3）是否有一些獨特的環境約束：移動的、室外的、飛機上的，等等？4）現在正在使用哪種系統平臺？未來的平臺是什么？5）正在使用其他什么應用系統？你的應用系統是否能與這些系統集成？2.4 關鍵用戶需要列出用戶認為的關鍵問題或需要。為每個問題澄清以下內容：1）這個問題的原因是什么？2）現在是怎么解決的？3）用戶預期的解決技術方案是什么？重要的是理解

5、用戶對解決每個問題所放的相對重要性。分級和累積投票技術可以說明必須解決的問題以及每個問題強調的事物。2.5 替代品和競爭對手確定用戶認為目前可得到的替代品。可包括購買對手的產品、 構建一個全部是自己的解決技術方案或者維持現狀。列出所知的已有的以及即將得到的競爭對手的產品。包括最終用戶所理解的每位對手的強項和弱項。2.5.1 競爭對手13. 產品綜述這一部分對產品能力、 到其他應用系統的接口以及系統配置等等提供一個高層視圖，通常由以下三個部分組成。3.1 產品前景這部分應該合理地把該產品與其他相關產品及用戶的需求放在一起。如果產品是獨立的而且是完全獨立的， 就在這里說明它；如果產品是一個大型系統

6、的組件之一，那么這一部分應該說明系統之間如何交互而且應該確定相關的接口。一種展示大型系統主要組件、互連及外部接口的簡單方法就是利用框圖。3.2 產品定位陳述提供一個整體陳述，從最高層次歸納總結產品在市場上的獨特定位。Moore （1991）稱此為產品定位陳述，并推薦以下格式：為了（目標客戶）誰（陳述需要或機遇）產品名是一個（產品分類）它（對主要優點的陳述，即驅動購買的原因）不像（主要競爭替代品）我們的產品（對主要區別的陳述）產品定位陳述向所有相關人員說明了應用系統的意圖以及工程的重要性。3.3 能力歸納總結歸納總結產品將提供的主要優點和特征。例如，客戶支持系統的前景文檔可能會使用這一部分強調問

7、題建檔、路電和狀態報告一不提及各個功能需求的細節。組織特征，以便清單能夠被客戶或所有第一次閱讀文檔的人理解。一個簡單的表列出主要的優點及其所支持的特征。客戶支持系統客戶收益支持特征收益1特征收益2特征收益3特征3.4 假定和相關條件列出所有一旦變更將影響整個產品前景的假設條件。例如，某個假定條件可能指出，指定用于軟件產品的硬件可得到某個特定的操作系統，如果該操作系統得不到，則前景必須變更。3.5 成本和定價對于將銷售給外部客戶的產品以及許多機構內使用的應用系統，成本和定價將直接影響應用系統的定義和實現。 在這一部分，把所有成本和相關的定價約束記錄下來。例如， 分銷 成本（磁盤、CD-ROM C

8、D母盤的編號）或者其他貨品銷售成本（手冊、打包）根據應用的 性質對于工程的成功可能無關也可能有實質性影響。4. 特征屬性與需求一樣，特征也有屬性，提供附加的工程信息，用于評估、跟蹤、劃分優先級、經 管為實現提出的項。這一部分陳述所有建議在前景文檔中使用的屬性，描述所選擇的屬性及其意義，使各方都能更好地理解每個特征的背景。4.1 狀態在工程經管團隊協商和評審之后確定。狀態信息在工程基線定義過程中跟蹤進程。1）建議的（proposed ）:描述正在對該特征進行討論，但還沒有得到“正式渠道”的 審核與采納，“正式渠道”可以是一個由工程團隊、產品經管、用戶或客戶團隊的代表組織的工作小組；2）批準的（a

9、pproved ）:它的能力被斷定是有用和可行的，得到正式渠道的認可并加 以實現；3）收編的（incorporated） ：已經在某個特定時間收編入產品基線的特征；4.2 優先級產品優先級是由營銷人員、 產品經理或商業分析人員設置的。 根據特征對最終用戶的相對優先級把它們劃分等級打開了一個與客戶、 分析人員以及開發團隊成員之間的對話。 優先 級用于經管廣度和確定開發優先級。一種優先級劃分模式如下：1）關鍵的（ critical ）：本質特征。實現的失敗意味著系統將不能滿足客戶的需要。所有關鍵的特征必須在發布中實現，否則進度將推遲。2）重要的（important ）：對于大多數應用的系統效率和效

10、力都重要的特征。該功能無法容易地用其他方式實現。 如果缺少重要的特征， 可能影響客戶或用戶的滿意程度， 甚至影響收益，但發布不會因此而推遲；3）有用的（useful ）：在不太典型的應用中有用的特征，但不經常使用或者有其他合理的有效變通。如果發布中沒有這類特征也不會對客戶滿意程度或收益造成重大的影響4.3 工作量由開發團隊設置， 用于經管廣度和確定開發優先級。 由于有些特征比其他特征要求更多的時間和資源， 因此對各特征采用團隊數量或人周、 代碼行、 功能點等等進行評估將是預測復雜度的最好辦法，從而可對在給定時間范圍內能完成什么不能完成什么有一個預期。4.4 風險由開發團隊設置， 設置的依據是工

11、程經歷意外事件的可能性， 如成本過高、 進度延遲甚至工程被撤消等。許多工程經理發現，把風險分為高、中、低就已經足夠了，盡管還可以再細一些。風險通常可以通過度量工程團隊進度預測的不確定性（范圍）進行間接地評估。4.5 穩定性由分析人員和開發團隊設置，設置的依據是特征變更的可能性或團對變更特征的理解。這個信息有助于建立開發優先級或確定下一步中哪些附加啟發是適當的。4.6 目標當布記錄特征將首先出現在哪一個產品版本中。 這個域可用于把特征分配到特定的基線版本中。當把目標版本與狀態域結合起來時， 團隊可以建議、 記錄和討論該版本的各個特征，而不必把它們提交給開發。 只有一些狀態被設置為“收編的”特征并

12、且其目標版本被定義的特征才能實現。 在發生廣度經管時， 目標版本的版本號會不斷增加， 于是該項仍然存在于前景文檔中，但被安排到以后的版本中去。在許多工程中，把特征分配給“特征團隊”，負責進一步啟發、書寫軟件需求和實現。這個簡單清單將幫助所有工程團隊成員更好地了解自己的職責。4.8 原因這一文本域用來跟蹤所要求特征的來源。 特征的存在有很多特定的理由。 這個域記錄了 特征的解釋或對解釋的引用。 例如， 引用可以是產品需求規格說明的頁號和行號， 或是重要 客戶面談錄像帶上的一個分鐘標志。5. 產品特征這一部分記錄產品特征。 特征提供了給用戶帶來利益所需要的系統能力， 每個特征都提供了一個滿足用戶需

13、要的服務。 例如， 問題跟蹤系統的一個特征可能是“提供走勢報告”的能力，趨勢報告可能繼續支持一個“更好理解工程狀態”的需要。因為前景文檔是由許多涉及人員審核的而且是達成共識的基礎。 所以特征應該用用肪的自然語言描述。特征描述應該簡短、精練，通常是1-2 個句子。為了有效經管應用的復雜度，我們建議：對于任何新系統或在原有系統上加強的系統，把能力抽象到較高層次產生大約 25-99 個特征。 這些特征是產品定義、 廣度經管和工程經管 的基本基礎。每個特征都可以在后面的規格說明中被更詳細地說明。在整個這一部分中，每一個特征都應該是用戶、操作者或其他外部系統可以感知的。5.1 特征15.2 特征26.

14、關鍵用例描述一些關鍵用例， 可以是對體系結構有意義或最方便幫助讀者理解系統如何使用的用例。7. 其他產品需求7.1 可應用規范列出產品必須符合的規范，如法律和規章（ FDA FCC、通信規范（TCP/IP、ISDN）、 平臺兼容規范（Windows、UNIX）以及質量和安全規范（UL、ISO、CMM。7.2 系統需求定義支持應用所必須的所有系統需求。包括支持的主機操作系統、 網絡平臺、 配置、內 存、外設以及軟件。許可和安裝問題對于開發工作有直接影響。 例如， 支持序列號、 口令安全或網絡許可證的需要必須創建其他開發過程中必須考慮的附加的系統需注。 安裝需求也會影響編碼或者產 生開發獨立安裝軟

15、件的需求。7.4 性能需求性能問題包括用戶負載因素、帶寬或通信能力、吞吐量、 準確度、可靠性或在某些負載 條件下的響應時間等。8. 建檔需求這一部分描述所有支持成功地部署系統必須開發的文檔8.1 用戶手冊描述用戶手冊的目的和內容。討論其需要的長度、詳盡程序、 索引和詞匯表的需要、指 南及參考手冊策略，等等。還要指定格式和打印約束。8.2 在線幫助許多應用系統都提供一個在線的幫助系統來輔助用戶。 這些系統的本質是應用系統開發所特有的，因為它們把編程（如超鏈接）和技術書寫（如組織和表示）結合起來。許多人發現在在線幫助系統是工程中的工程，它從廣度經管和計劃活動中直接受益。8.3 安裝指南、配置和自述文件對于一個全面的解決技術方案來說，有一個包括安裝指令和配置指南的文檔非常重要，而一個自述（Read Me）文件也通常作為規范組件而存在。自述文件中可能包括一