（建筑工程管理）軟件工程之需求分析

(建筑工程管理)軟件工程工程之需求分析首先我們必須了解需求工程和其他項目過程的關系：軟件需求包括三個不同的層次-業(yè)務需求、用戶需求和功能需求-也包括非功能需求:業(yè)務需書和需求驗證。以下列出和講解分析常1)確定需求開發(fā)過程：確定需求開發(fā)過程確定如何組織需求的收集、分析、細化且核實的對重要的步驟要給予壹定指導，這將有助于分析人員的工作，而2)編寫項目視圖和范圍文檔：項目視圖和范圍文檔應該包括高層的產品業(yè)務目標，所有的求均必須遵從能達到的業(yè)務需求。項目視圖說明使所有項目參和者對項目包括對現(xiàn)存產品的壹個簡要的相對評價和解決方案，且指出所建議的產品為需求。提出客戶目前所遇到的問題于新產品中將可能(或不可能)出現(xiàn)的闡述，提供客戶怎a競爭、時間問題、對業(yè)務可能帶來的消極影響。預測風險的嚴重性，指明你所同需求客戶的見法。它可能有點理想化，但必須以現(xiàn)有的或所期待。。、個因素。不僅要包括組織直接控制的范圍內的事務，仍要包括外部因素。如果可能，可建立測量的標準用于評價是否達到業(yè)務目標.3)用戶群分類：產品的用戶于很多方面存于著差異，例如：用戶使用產品的頻度、他們的識、他們所使用的產品特性、他們所進行的業(yè)務過程、他們于地理優(yōu)先級。根據(jù)這些差異，你能夠把這些不同的用戶分成小組。用戶把其它應用程序或系統(tǒng)接口所用的硬件組件也見成是附加用戶類的應用程序接口，能夠幫助你確定產品中那些和外部應用程序或組件類且歸納各自特點為避免出現(xiàn)疏忽某壹用戶群需求的情況，要將可4)選擇產品代表：擇每類用戶的產品代表為每類用戶至少選擇壹位能真正代表他們需求的能作出決策。這對于內部信息系統(tǒng)的開發(fā)是最易實現(xiàn)的，因為此而對于商業(yè)開發(fā)，就得于主要的客戶或測試者中建立起良好的合適的產品代表。他們必須壹直參和項目的開發(fā)而且有權作出決策。每壹個5)建立核心隊伍：建立起典型用戶的核心隊伍把同類產品或你的產品的先前版本用戶代表集目前產品的功能需求和非功能需求。這樣的核心隊伍對于商業(yè)開壹個龐大且多樣的客戶基礎。和產品代表的區(qū)別于于，核心隊伍成6)確定使用實例：讓用戶代表確定使用實例從用戶代表處收集他們使用軟件完成所需任務的描述-使用實例，討論用戶和系統(tǒng)間的交互方式和對話要求。于編寫使用實例的文檔時可某項任務的許多邏輯關聯(lián)任務和交互順序。因此，壹個使合，且且壹個說明是使用實例的例子。于描述時列出執(zhí)行者和例，畫出圖形分析模型是有益的，這些模型包括數(shù)據(jù)流程圖、實體關不向開發(fā)者提供他們所要開發(fā)的功能的細節(jié)。為了減少這種不確定性，你用實例敘述成詳細的功能需求。每壹個使用實例可引伸出多個功能需求，這執(zhí)行關聯(lián)的任務；且且多個使用實例可能需要相同的功能需求。使用實例方來的好處來自于該方法是以任務為中心和以用戶為中心的觀點。比起使用以么。個方法，用戶能夠利用這個方法和系統(tǒng)進行交互，從而達到特定可有效地捕捉大多數(shù)所期望的系統(tǒng)行為，可是你可能有壹些需求，這些需他執(zhí)行者之間的交互沒有特定的關系。這時你就需要壹個獨立的需求規(guī)格7)召開應用程序開發(fā)聯(lián)系會議：召開應用程序開發(fā)聯(lián)系會議應用程序開發(fā)聯(lián)系會議是范圍討論會，也是分析人員和客戶代表之間壹種很好的合作辦法，且能由此擬。該會議通過緊密而集中的討論得以將客戶和開發(fā)人員間的合作伙伴關系8)分析用戶工作流程：分析用戶工作流程觀察用戶執(zhí)行業(yè)務任務的過程。畫壹張簡單的示意圖(最好用數(shù)據(jù)流圖)來描繪出用戶什么時候獲得什么數(shù)據(jù)，且怎樣使用這些數(shù)據(jù)。編制檔將有助于明確產品的使用實例和功能需求。你甚至可能發(fā)現(xiàn)客戶且不真地9)確定質量屬性：確定質量屬性和其它非功能需求于功能需求之外再考慮壹下非功能的質，這會使你的產品達到且超過客戶的期望。對系統(tǒng)如何能很好地執(zhí)行某些行為或讓用簡易、直覺性、用戶友好、健壯性、可靠性、安全性和高效性。你將要和用戶壹起商10)檢查問題方案：通過檢查當前系統(tǒng)的問題方案來進壹步完善需求客戶的問題方案及補充新產品或新版本提供了大量豐富的改進及增加特性的想法，負責提供用戶支持及幫助11)需求重用：跨項目重用需求如果客戶要求的功能和已有的產品很相似，則可查見需求是1)繪制關聯(lián)圖：繪制系統(tǒng)關聯(lián)圖是用于定義系統(tǒng)和系統(tǒng)外部實體間的界限和接口的簡單模2)創(chuàng)建開發(fā)原型：創(chuàng)建用戶接口原型當開發(fā)人員或用戶不能確定需求時，開發(fā)壹個用戶接許多概念和可能發(fā)生的事更為直觀明了。用戶通過評價原型將使項目參和。3)分析可行性：分析需求可行性于允許的成本、性能要求下，分析每項需求實施的可行性，4)確定需求優(yōu)先級：確定需求的優(yōu)先級別應用分析方法來確定使用實例、產品特性或單項別。以優(yōu)先級為基礎確定產品版本將包括哪些特性或哪類需求。當允許需5)為需求建立模型：為需求建立模型需求的圖形分析模型是軟件需求規(guī)格說明極好的補充不同的信息和關系以有助于找到不正確的、不壹致的、遺漏的和冗余的需6)編寫數(shù)據(jù)字典：創(chuàng)建數(shù)據(jù)字典數(shù)據(jù)字典是對系統(tǒng)用到的所有數(shù)據(jù)項和結構的定義，以確壹的數(shù)據(jù)定義。于需求階段，數(shù)據(jù)字典至少應定義客戶數(shù)據(jù)項以確保客戶7)應用質量功能調配：使用質量功能調配質量功能調配是壹種高級系統(tǒng)技術，它將產品特性和對客戶的重要性聯(lián)系起來。該技術提供了壹種分析方法以明確那些是客戶最為關性。它將需求分為三類：期望需求，即客戶或許且未提及，但如若缺少會讓他們感到不會受到責備。含了業(yè)務需求，而使用實例文檔則包含了用戶需求。你必須編寫從使仍要編寫產品的非功能需求文檔，包括質量屬性和外部接口個軟件系統(tǒng)必須提供的功能和性能以及它所要考慮的限制條應該盡可能完整地描述系統(tǒng)預期的外部行為和用戶可視化行為。除了設計和實現(xiàn)上的限制，板。該模板為記錄功能需求和各種其它和需求關聯(lián)的重要信息提供了統(tǒng)壹目的且非是創(chuàng)建壹種全新的模板，而是采用壹種已有的且可滿足項目需要動。文檔如何編寫且且如何閱讀和解文檔中詳盡說明了這個產品的軟件需求，包括修正或發(fā)行版本號。如和整個系統(tǒng)的壹部分有關系，那么就只定義文檔中說明的部分或員。描述了文檔中剩余部分的內容及其組織結構。提出了最適合于其目的的簡短描述，包括利益和目標。把軟件和企業(yè)目標或業(yè)務策略品以及它所運行的環(huán)境、使用產品的用戶和已知的限制、假設明中所定義的產品的背景和起源。說明了該產品是否是產品系列中的所改進的下壹代產品、是否是現(xiàn)有應用程序的替代品，或者是否用該產品的不同用戶類且描述它們關聯(lián)的特征。有壹些需求可能只和特定，包括硬件平臺、操作系統(tǒng)和版本，仍有其它的軟件組件或和其共存列舉出于對軟件需求規(guī)格說明中影響需求陳述的假設因素(和已知因素相對立)。這可能包件或有關開發(fā)或運行環(huán)境的問題。你可能認為產品將符合壹個特殊的因素存于的依賴。例如，如果你打算把其它項目開發(fā)的組件集成到系依賴那個項目按時提供正確的操作組件。如果這些依賴已經(jīng)記錄到其它文夠保證新產品和外部組件正確連接的需求。關聯(lián)圖表示了高層抽象的外部數(shù)據(jù)和控制組件的詳細描述寫入數(shù)據(jù)字典中。如果產品的不同部分有不同布局，應該寫入壹個獨立的用戶界面規(guī)格說明中，而不能寫入軟件需求規(guī)每壹接口的特征。這種描述可能包括支持的硬件類型、軟硬件之間交描述該產品和其它外部組件(由名字和版本識別)的連接，包括數(shù)據(jù)庫、操作系統(tǒng)、工具、于軟件組件之間交換數(shù)據(jù)或消息的目的。描述所需要的服義了關聯(lián)的消息格式。規(guī)定通信安全或加密問題、數(shù)據(jù)傳輸速率和同簡短說明且指出該特性的優(yōu)先級是高、中，仍是低。或者你仍能夠包到9(高)。列出輸入激勵(用戶動作、來自外部設備的信號或其它觸發(fā)器)和定義這壹特性行為的系統(tǒng)詳細功能需求。這些是必須提交給用戶的軟件功能，使用戶能夠使用服務或者使用所指定的使用實例執(zhí)行任務。描述產品如何響應可預知的出。求，如產品的易用程度如何，執(zhí)行速度如何，可靠性如何，當?shù)脑硪詭椭_發(fā)人員作出合理的設。義容量需求，例如存儲器和磁盤空間的需求或者存儲于數(shù)據(jù)庫中表的最大程中可能發(fā)生的損失、破壞或危害關聯(lián)的需求。定義必須采取的安全、完整性或和私人問題關聯(lián)的需求，這些問題將會影響到產品的使用數(shù)據(jù)的保護。定義用戶身份確認或授權需求。明確產品必須滿足的安人員至關重要的其它產品質量特性。這些特性必須是確定、定量的且應指明不同屬性的相對側重點，例如易用程度優(yōu)于易學程度，或操作規(guī)則，例如什么人于特定環(huán)境下能夠進行何種操作。這些本身不行的用戶文檔部分，例如，用戶手冊、于線幫助和教程。明確所有已明的其它部分未出現(xiàn)的需求，例如國際化需求或法律上的需求。你仍理和維護部分來完善產品安裝、配置、啟動和關閉、修復和容錯，以以便讀者能夠正確地解釋軟件需求規(guī)格說明，包括詞頭和縮寫。你可多項項目的詞匯表，且且只包括特定于單壹項目的軟件需求聯(lián)的分析模型的位置，例如數(shù)據(jù)流程圖、類圖、狀態(tài)轉換圖或說明中待確定問題的列表，其中每壹表項均是編上號的，以便于跟2)指明需求來源：指明需求的來源為了讓所有項目風險承擔者明白需求規(guī)格說明書中為何提供這些功能需求，要均能追溯每項需求的來源，這可能是壹種使用實例或其它客戶要求，3)為每項需求注上標號：為了滿足軟件需求規(guī)格說明的可跟蹤性和可修改性的質量標準，軟件需求。為每項需求注上標號制定壹種慣例來為需求規(guī)格說明書中的每得需求能被跟蹤，記錄需求變更且為需求狀態(tài)和變更活動建立度量。需求4)記錄業(yè)務規(guī)范：是指關于產品的操作原則，比如誰能于什么情況下采取什么動作。將這中的壹個獨立部分，或壹獨立的業(yè)務規(guī)范文檔。某些業(yè)務規(guī)范將引范。5)創(chuàng)建需求跟蹤能力矩陣：建立壹個矩陣把每項需求和實現(xiàn)、測試它的設計和代碼部分聯(lián)矩陣同時也把功能需求和高層的需求及其它關聯(lián)需求聯(lián)系起來、度量單位、精度以及允許取值范圍的共享倉庫。數(shù)據(jù)字典的維護獨立于軟件需求規(guī)格說明，護的任何階段，各個風險承擔者均能夠訪問數(shù)據(jù)字典。它定義了原數(shù)復雜數(shù)據(jù)元素、重復的數(shù)據(jù)項、壹個數(shù)據(jù)項的枚舉值以及可選的數(shù)據(jù)分析的基本工具。壹個數(shù)據(jù)流圖確定了系統(tǒng)的轉化過程、系統(tǒng)所操縱的數(shù)據(jù)或物質的收集(存儲)，仍有過程、存儲、外部世界之間的數(shù)據(jù)流或物質流。數(shù)據(jù)運用到系統(tǒng)分析上，這種方法很適用于事務處理系統(tǒng)和其它功能密集數(shù)據(jù)關系。分析實體聯(lián)系圖有助于對業(yè)務或系統(tǒng)數(shù)據(jù)組成的理解和圖：實時系統(tǒng)和過程控制應用程序能夠于任何給定的時間內以有限的狀態(tài)存于。當機的例子。大多數(shù)軟件系統(tǒng)需要壹些狀態(tài)建模或分析，就像大多數(shù)系序中，用戶界面能夠見作是壹個有限狀態(tài)機。于任何情況下僅有壹個對話元素(例如壹個菜單，工作區(qū)，行提示符或對話框)對用戶輸入是可用的。于激活的輸采取的活動，能夠導航到有限個其它對話元素。因此，許多用戶界面壹種稱為對話圖來建模。對話圖描繪了系統(tǒng)中的對話元素和它們之間。析和設計，且且它運用于許多項目的設計中，從而析、設計和編程的域。類圖是用圖形方式敘述面向對象分析所確定的類以1)審查需求文檔：對需求文檔進行正式審查是保證軟件質量的很有效的方法。組織壹個由不同代表(如分析人員，客戶，設計人員，測試人員)組成的小組，對需求規(guī)格說明書及關2)依據(jù)需求編寫測試用例：根據(jù)用戶需求所要求的產品特性寫出黑盒功能測試用例?？蛻粢源_認是否達到了期望的要求。仍要從測試用例追溯回功能需求以確保沒且確保所有測試結果和測試用例相壹致。同時，要使用測試用例來驗證需3)編寫用戶手冊：于需求開發(fā)早期即可起草壹份用戶手冊，用它作為需求規(guī)格說明的參考優(yōu)秀的用戶手冊要用淺顯易懂的語言描述出所有對用戶可見的功能。而輔4)確定合格的標準：確定合格的標準讓用戶描述什么樣的產品才算滿足他們的要求和適合二、需求管理例文檔、軟件需求規(guī)格說明及關聯(lián)分析準，這些文檔就定義了開發(fā)工作的需求基線。這個基線于客戶和開發(fā)人員之產品功能需求和非功能需求的壹個約定。需求約定是需求開發(fā)和需求管理之。哪些需求變更，此變更是否于項目范圍內，估價它們，且對此評估作出決策確和變更關聯(lián)的任務且評估完成這些任務需要的工作量。通過這些分析將有員會作出更好的決策。影響分析能夠提供對建議的變更的準確理解，幫助做變更批準決策。通過對變更內容的檢驗，確定對現(xiàn)有的系統(tǒng)做出是修改或拋創(chuàng)建新系統(tǒng)以及評估每個任務的工作量。進行影響分析的能力依賴于跟蹤能求、設計模板、源