軟件工程之需求分析(文件)
【正文】 包括用戶界面風格指導、合同、標準、系統(tǒng)需求規(guī)格說明、使用實例文檔，或相關產(chǎn)品的軟件需求規(guī)格說明。 產(chǎn)品的功能 概述了產(chǎn)品所具有的主要功能。有一些需求可能只與特定的用戶類相關。這可能包括你打算要用的商業(yè)組件或有關開發(fā)或運行環(huán)境的問題。例如，如果你打算把其它項目開發(fā)的組件集成到系統(tǒng)中，那么你就要依賴那個項目按時提供正確的操作組件。需要把對接口數(shù)據(jù)和控制組件的詳細描述寫入數(shù)據(jù)字典中。而對于用戶界面的細節(jié)，例如特定對話框的布局，應該寫入一個獨立的用戶界面規(guī)格說明中，而不能寫入軟件需求規(guī)格說明中。明確并描述在軟件組件之間交換數(shù)據(jù)或消息的目的。定義了相關的消息格式。 激勵/響應序列 列出輸入激勵（用戶動作、來自外部設備的信號或其它觸發(fā)器）和定義這一特性行為的系統(tǒng)響應序列。描述產(chǎn)品如何響應可預知的出錯條件或者非法輸入或動作。確定相互合作的用戶數(shù)或者所支持的操作、響應時間以及與實時系統(tǒng)的時間關系。 安全設施需求 詳盡陳述與產(chǎn)品使用過程中可能發(fā)生的損失、破壞或危害相關的需求。定義用戶身份確認或授權需求。至少應指明不同屬性的相對側重點，例如易用程度優(yōu)于易學程度，或者可移植性優(yōu)于有效性。明確所有已知的用戶文檔的交付格式或標準。你可能希望為整個公司創(chuàng)建一張跨越多項項目的詞匯表，并且只包括特定于單一項目的軟件需求規(guī)格說明中的術語?！ ?）為每項需求注上標號：為了滿足軟件需求規(guī)格說明的可跟蹤性和可修改性的質(zhì)量標準，必須唯一確定每個軟件需求。需求標識方法有序列號。將這些編寫成需求規(guī)格說明書中的一個獨立部分，或一獨立的業(yè)務規(guī)范文檔。在開發(fā)過程中建立這個矩陣，而不要等到最后才去補建。它定義了原數(shù)據(jù)元素、組成結構體的復雜數(shù)據(jù)元素、重復的數(shù)據(jù)項、一個數(shù)據(jù)項的枚舉值以及可選的數(shù)據(jù)項?！ ?shù)據(jù)流圖：描繪了系統(tǒng)的數(shù)據(jù)關系。當滿足所定義的標準時，狀態(tài)就會發(fā)生改變，例如在特定條件下，接收到一個特定的輸入激勵。在任何情況下僅有一個對話元素（例如一個菜單，工作區(qū)，行提示符或?qū)υ捒颍τ脩糨斎胧强捎玫摹? 類圖：面向?qū)ο蟮能浖_發(fā)優(yōu)于結構化分析和設計，并且它運用于許多項目的設計中，從而產(chǎn)生了面向?qū)ο蠓治?、設計和編程的域。另外在需求開發(fā)期間所做的非正式評審也是有所裨益的。同時，要使用測試用例來驗證需求模型的正確性，如對話框圖和原型等。 4）確定合格的標準：確定合格的標準讓用戶描述什么樣的產(chǎn)品才算滿足他們的要求和適合他們使用的。這個基線在客戶和開發(fā)人員之間就構筑了計劃產(chǎn)品功能需求和非功能需求的一個約定?！ ?．建立變更控制委員會，組織一個由項目風險承擔者組成的小組作為變更控制委員會，由他們來確定進行哪些需求變更，此變更是否在項目范圍內(nèi)，估價它們，并對此評估作出決策以確定選擇哪些，放棄哪些，并設置實現(xiàn)的優(yōu)先順序，制定目標版本。影響分析可以提供對建議的變更的準確理解，幫助做出信息量充分的變更批準決策。這樣能減少因疏忽而不得不變更產(chǎn)品的機會，這種變更在變更需求的情況下是必須進行的。最好的辦法是使用合適的配置管理工具在版本控制下為需求文檔定位。需求文檔的每一個版本必須被統(tǒng)一確定?！ ?．跟蹤每項需求的狀態(tài)建立一個數(shù)據(jù)庫，其中每一條記錄保存一項功能需求?！ ?．使用需求管理工具商業(yè)化的需求管理工具能幫助你在數(shù)據(jù)庫中存儲不同類型的需求，為每項需求確定屬性，可跟蹤其狀態(tài)，并在需求與其它軟件開發(fā)工作產(chǎn)品間建立跟蹤能力聯(lián)系鏈?！ ?．衡量需求穩(wěn)定性記錄基準需求的數(shù)量和每周或每月的變更（添加、修改、刪除）數(shù)量。為了盡量減少困惑、沖突、誤傳，應僅允許指定的人來更新需求。版本控制工具能自動完成這些任務。之后的需求變更就遵循變更控制過程即可。進行影響分析的能力依賴于跟蹤能力數(shù)據(jù)的質(zhì)量和完整性。明確與變更相關的任務并評估完成這些任務需要的工作量。 1．確定需求變更控制過程，確定一個選擇、分析和決策需求變更的過程。二、需求管理 需求開發(fā)的結果應該有項目視圖和范圍文檔、使用實例文檔、軟件需求規(guī)格說明及相關分析模型。優(yōu)秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能?？蛻敉ㄟ^使用測試用例以確認是否達到了期望的要求。4. 需求驗證 1）審查需求文檔：對需求文檔進行正式審查是保證軟件質(zhì)量的很有效的方法。因此，許多用戶界面可以用狀態(tài)轉換圖中的一種稱為對話圖來建模。大多數(shù)軟件系統(tǒng)需要一些狀態(tài)建模或分析，就像大多數(shù)系統(tǒng)涉及到轉換過程、數(shù)據(jù)實體和業(yè)務對象。相反，當你在系統(tǒng)設計階段建立實體聯(lián)系圖時，通常要定義系統(tǒng)數(shù)據(jù)庫的物理結構。一個數(shù)據(jù)流圖確定了系統(tǒng)的轉化過程、系統(tǒng)所操縱的數(shù)據(jù)或物質(zhì)的收集（存儲），還有過程、存儲、外部世界之間的數(shù)據(jù)流或物質(zhì)流?！ ?shù)據(jù)字典：一個定義應用程序中使用的所有數(shù)據(jù)元素和結構的含義、類型、數(shù)據(jù)大小、格式、度量單位、精度以及允許取值范圍的共享倉庫?！ ?）創(chuàng)建需求跟蹤能力矩陣：建立一個矩陣把每項需求與實現(xiàn)、測試它的設計和代碼部分聯(lián)系起來。使用待確定（to be determined, TBD ）符號等。這種慣例應當很健全，允許增加、刪除和修改。附錄C ：待確定問題的列表 編輯一張在軟件需求規(guī)格說明中待確定問題的列表，其中每一表項都是編上號的，以便于跟蹤調(diào)查。你還可以增加有關操作、管理和維護部分來完善產(chǎn)品安裝、配置、啟動和關閉、修復和容錯，以及登錄和監(jiān)控操作等方面的需求。這些本身不是功能需求，但它們可以暗示某些功
物理相關推薦
鄂ICP備17016276號-1