軟件工程PPT電子教案課件-第4章需求分析基礎(chǔ).ppt

軟件工程,哈爾濱工程大學(xué),software engineering,第4章 需求分析基礎(chǔ),分析的任務(wù)、過程、原則 初步需求獲取技術(shù) 需求建模 問題抽象、問題分解與多視點分析 支持需求分析的快速原型技術(shù) 需求規(guī)格說明與評審,軟件需求：用戶對目標(biāo)軟件系統(tǒng)在功能、行為、 性能、設(shè)計約束等方面的期望,第4章 需求分析基礎(chǔ),ieee軟件工程標(biāo)準(zhǔn)詞匯表(1997年)中定義需求為： (1)用戶解決問題或達(dá)到目標(biāo)所需的條件或權(quán)能(capability)。 (2)系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其它正式規(guī)定文檔所需具有的條件或權(quán)能。 (3)一種反映上面(1)或(2)所描述的條件或權(quán)能的文檔說明。 準(zhǔn)確、完整和規(guī)范化的軟件需求是軟件開發(fā)成功的關(guān)鍵。軟件項目中40%-60%的問題都是在需求階段埋下的禍根 主要障礙：用戶對應(yīng)用問題的理解、描述以及他們對目標(biāo)軟件的需求往往具有片面性、模糊性，甚至不一致性,第4章 需求分析基礎(chǔ),不適當(dāng)?shù)男枨筮^程所引起的一些風(fēng)險： 調(diào)研的用戶不多，導(dǎo)致產(chǎn)品無法被接受 用戶需求的增加帶來過度的耗費(fèi)和降低產(chǎn)品的質(zhì)量 模棱兩可的需求說明可能導(dǎo)致時間的浪費(fèi)和返工 用戶增加一些不必要的特性和開發(fā)人員畫蛇添足(gold-plating) 過分簡略的需求說明以致遺漏某些關(guān)鍵需求 忽略某類用戶的需求將導(dǎo)致眾多客戶的不滿 不完善的需求說明使得項目計劃和跟蹤無法準(zhǔn)確進(jìn)行,4.1 需求分析的任務(wù)與原則,軟件需求分析：對應(yīng)用問題及環(huán)境的理解和分析，為問題涉及的信息、功能及系統(tǒng)行為建立模型。將用戶需求精確化、完全化，最終形成需求規(guī)格說明書 分析目標(biāo)：準(zhǔn)確理解用戶的要求，進(jìn)行細(xì)致的調(diào)查分析，將用戶的非形式的要求轉(zhuǎn)化為完整的需求定義，再將需求定義轉(zhuǎn)換為相應(yīng)的形式化的規(guī)格說明,深入描述軟件的功能和性能，確定軟件的設(shè)計約束、軟件同其他系統(tǒng)元素的接口細(xì)節(jié)，定義軟件的其他有效性需求,一方面必須全部理解用戶的各項要求但又不能全盤接受；另一方面要準(zhǔn)確表達(dá)被接受的要求。只有經(jīng)過確切描述的軟件需求才能成為軟件設(shè)計的基礎(chǔ),需求分析的任務(wù),需求分析的任務(wù)：就是借助于當(dāng)前系統(tǒng)的邏輯模型導(dǎo)出目標(biāo)系統(tǒng)的邏輯模型，解決目標(biāo)系統(tǒng)的 “做什么” 的問題。,理 解 需 求,表 達(dá) 需 求,怎么做,做什么,需求分析的任務(wù),需求分析階段要解決的問題，是讓用戶和開發(fā)者共同明確將要開發(fā)的是一個什么樣的系統(tǒng)。 主要兩個任務(wù) （1）通過對問題及其環(huán)境的理解、分析和綜合，建立分析模型(analysis model)。 （2）在完全地弄清用戶對軟件系統(tǒng)的確切要求的基礎(chǔ)上，用“軟件需求規(guī)格說明書”（software requirement specification，srs）把用戶的需求表達(dá)出來。,需求分析的任務(wù),建立分析模型 由于用戶群體的各個用戶往往會從不同的角度闡述他們對原始問題的理解和對目標(biāo)軟件的需求，分析模型是描述軟件需求的一組模型。 一方面用于精確地記錄用戶對原始問題和目標(biāo)軟件的描述 另一方面，它也將幫助分析人員發(fā)現(xiàn)用戶需求中的不一致性，排除不合理的部分，挖掘潛在的用戶需求 這種模型往往包含問題及其環(huán)境所涉及的信息流、處理功能、用戶界面、行為模型及設(shè)計約束等。是形成需求說明、進(jìn)行軟件設(shè)計與實現(xiàn)的基礎(chǔ),需求分析的任務(wù),編寫需求說明 應(yīng)該具有準(zhǔn)確性和一致性。它是連接計劃時期和開發(fā)時期的橋梁，也是軟件設(shè)計的依據(jù)。 應(yīng)該具有清晰性和無二義性。它是溝通用戶和系統(tǒng)分析員思想的媒介，雙方要用它來表達(dá)對于需要計算機(jī)解決的問題的共同理解。 應(yīng)該直觀、易讀和易于修改。應(yīng)盡量采用標(biāo)準(zhǔn)的圖形、表格和簡單的符號來表示，使不熟悉計算機(jī)的用戶也能一目了然。,需求分析過程,問題識別,分析與綜合,編寫文檔,分析評審,問題識別,從分析當(dāng)前系統(tǒng)包含的數(shù)據(jù)開始 例如當(dāng)前系統(tǒng)使用的賬冊、卡片和報表，手工處理當(dāng)前信息的方法與不足，用戶需要改進(jìn)的主要問題及其迫切性等 對軟件功能的需求和界面的需求 為了收集到全面完整的信息，需將客戶按使用頻率、使用特性、優(yōu)先及等方面進(jìn)行分類，每類選擇若干用戶代表，從代表那里收集他們希望的軟件系統(tǒng)功能、用戶與系統(tǒng)間的交互和對話方式等需求 對質(zhì)量的要求，包括性能、有效性、可靠性、可用性和設(shè)計約束等，提高用戶對軟件的滿足程度 如果客戶的要求和已有產(chǎn)品很相似，則需要考慮可否復(fù)用一些已有的軟件組件,分析與綜合（需求提煉：分析建模）,分析人員應(yīng)了解問題及環(huán)境，應(yīng)與用戶合作清除用戶需求的模糊性、岐義性和不一致性，并對相互沖突的需求進(jìn)行折衷 分析人員與用戶合作對問題進(jìn)行分析、綜合，結(jié)合軟件的特點及開發(fā)經(jīng)驗，尋求軟件需求 為用戶的問題及準(zhǔn)備開發(fā)的軟件建立模型，從不同的角度、不同的抽象級別精確地說明對問題的理解、對目標(biāo)軟件的需求 圖形化的分析模型是說明軟件需求極好的手段，常用的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、控制流圖、狀態(tài)轉(zhuǎn)換圖、用例圖、類對象關(guān)系及其行為圖文圖等。有些軟件還需要繪制系統(tǒng)關(guān)聯(lián)圖、創(chuàng)建用戶接口原型、確定需求優(yōu)先級別,編寫srs（需求描述）,以需求模型為基礎(chǔ)，考慮到軟件問題的可解性，生成需求規(guī)格說明和初步的用戶手冊。 需求規(guī)格說明包含對目標(biāo)軟件系統(tǒng)的外部行為的完整描述、需求驗證標(biāo)準(zhǔn)以及用戶在性能、質(zhì)量、可維護(hù)性等方面的要求。 初步用戶手冊包括用戶界面描述以及有關(guān)目標(biāo)軟件使用方法的初步構(gòu)想。 文檔 遵循規(guī)范，內(nèi)容全面、結(jié)構(gòu)清晰、措辭準(zhǔn)確、格式嚴(yán)謹(jǐn) 將初步用戶手冊作為分析文檔,有助于分析人員從用戶角度考慮軟件需求，并鼓勵用戶盡早參予軟件開發(fā)活動 必須使用統(tǒng)一格式的文檔進(jìn)行描述。為了使需求描述具有統(tǒng)一的風(fēng)格，可以采用已有的且可滿足項目需要的模板，如ieee標(biāo)準(zhǔn)830-1998和gb9385中描述的srs模板,需求評審,分析人員在用戶和軟件設(shè)計人員的配合下，對自己生成的需求規(guī)格說明和初步的用戶手冊進(jìn)行評審，確保軟件需求的完全性、精確性和一致性，并使用戶和軟件設(shè)計人員對需求規(guī)格說明及用戶手冊的理解達(dá)成一致。 需求規(guī)格說明得到用戶和軟件開發(fā)方的確認(rèn)后，應(yīng)成為用戶方與軟件開發(fā)方合同的一部分。,需求分析流程,需求分析的原則,原則 能夠表達(dá)和理解問題的信息域和功能域 能夠?qū)栴}進(jìn)行分解和不斷細(xì)化，建立問題的層次結(jié)構(gòu) 需要給出系統(tǒng)的邏輯視圖和物理視圖 方法 面向數(shù)據(jù)流的分析 面向數(shù)據(jù)的分析 面向?qū)ο蟮姆治?需求的四項基本標(biāo)準(zhǔn)：明確(clear)、完整(complete)、一致(consistent)、可測試(testable),4.2 初步需求獲取技術(shù),訪談與會議 深入調(diào)查研究 聯(lián)合小組 開發(fā)原型,訪談與會議,個別訪談或小組會議 分析人員應(yīng)精心準(zhǔn)備問題，通過用戶對問題的回答，逐步理解用戶對目標(biāo)軟件的要求 (1)循序漸進(jìn) 首先關(guān)心一般性、整體性問題，然后再討論細(xì)節(jié)問題。 (2)客觀、公正 不應(yīng)限制用戶在回答問題過程中自由發(fā)揮。 (3)總結(jié) 問題匯總后應(yīng)能反映軟件或其子系統(tǒng)的全貌，能覆蓋用戶對目標(biāo)軟件或其子系統(tǒng)在功能、行為、性能諸方面的要求。細(xì)節(jié)問題留待以后解決。,深入調(diào)查研究,調(diào)查研究 考察用戶軟件或其子系統(tǒng)業(yè)務(wù)流程 學(xué)習(xí)用戶的有關(guān)業(yè)務(wù)知識，在用戶幫助下了解用戶的軟件或子系統(tǒng)業(yè)務(wù)流程，結(jié)合軟件開發(fā)和應(yīng)用的經(jīng)驗提出新的用戶需求 注意：開發(fā)軟件系統(tǒng)不僅是為了模擬手工操作過程，還必須將最好的經(jīng)濟(jì)效益、最快的處理速度、最合理的操作流程、最友好的用戶界面作為軟件的目標(biāo),聯(lián)合小組,建立軟件開發(fā)方和用戶方共同組成的聯(lián)合小組，小組成員對分析負(fù)有相同的責(zé)任 聯(lián)合小組要制定自己的工作制度和計劃，確定專門的記錄員，另設(shè)專人負(fù)責(zé)會議的議程和資料的綜合、整理 選擇易于理解、比較簡潔、精確的表示機(jī)制作為描述語言，如輔以文字說明的流程圖,需求獲取一般過程,1、識別系統(tǒng)用戶 分析客戶方的所有用戶類型以及潛在的類型，然后根據(jù)他們的要求來確定系統(tǒng)的整體目標(biāo)和系統(tǒng)的工作范圍。如有領(lǐng)導(dǎo)使用，則應(yīng)該有領(lǐng)導(dǎo)查詢系統(tǒng)；如果是單機(jī)系統(tǒng)，則對安全性可以少考慮。 2、用戶調(diào)研與訪談 會議、電話、email、小組討論、模擬演示等，每次都要有記錄，確定功能需求、非功能需求(響應(yīng)時間、自動恢復(fù)時間)、環(huán)境限制、設(shè)計約束等。 3、訪談結(jié)果整理 對于用戶提出的每個需求都要知道“為什么”，并判斷這種需求是否有充足的理由。 將那種以“如何實現(xiàn)”的表達(dá)方式轉(zhuǎn)換為“實現(xiàn)什么”。 分析由用戶需求衍生出的隱含需求，并識別用戶沒有明確提出來的隱含需求。如工時統(tǒng)計計算工資，生產(chǎn)系統(tǒng)工資系統(tǒng)。 4、訪談結(jié)果呈現(xiàn) 明確標(biāo)識出那些未確定的需求項。 使需求符合系統(tǒng)的整體目標(biāo)。 保證需求項之間的一致性，解決需求項之間可能存在的沖突。,出版社管理信息系統(tǒng)調(diào)查表,實例分析,家庭保安系統(tǒng) 家庭保安市場正以每年40%的速度增長。我們希望建立一種基于微處理器的家庭保安系統(tǒng)，它能夠識別異常事件并采取相應(yīng)的防護(hù)措施。這些異常事件包括：非法入侵、火災(zāi)、水淹，等等。一旦異常情況被相應(yīng)的傳感器探測出來，系統(tǒng)應(yīng)自動用電話向監(jiān)控中心報警。此外，系統(tǒng)應(yīng)允許戶主對其行為實施程序式控制。 聯(lián)合小組首先制定工作制度，經(jīng)過數(shù)次會議討論，明確問題的范圍、問題與環(huán)境的關(guān)系，并就開發(fā)軟件產(chǎn)品的必要性達(dá)成共識后，小組負(fù)責(zé)人要求每位參加人列出應(yīng)用問題及環(huán)境中有關(guān)的對象、這些對象所實施的操作以及對象間的互相作用,實例分析,控制面板、電話機(jī)、監(jiān)控中心、煙霧報警器、門窗報警器、警報器等對象；用戶編程控制、電話撥號、報警等操作 要求對對象及操作進(jìn)行詳細(xì)描述 用戶可能提出約束條件，如成本、響應(yīng)時間優(yōu)先處理順序等 最后初步分析活動，綜合、整理，形成文檔，該文檔作為后續(xù)分析活動的基礎(chǔ)。部分需求文檔（不包括約束條件和測試標(biāo)準(zhǔn)）如下 “家庭保安系統(tǒng)”的軟件允許用戶在安裝時進(jìn)行系統(tǒng)配置，實施對傳感器的監(jiān)控并通過控制面板與用戶進(jìn)行信息交互。,實例分析,配置操作包括： （1）指定每一傳感器的種類和編號； （2）設(shè)置開、關(guān)機(jī)密碼； （3）指定報警電話號碼； （4）指定報警延遲和電話重?fù)苎舆t時間（以秒為單位）。 當(dāng)軟件系統(tǒng)接收到傳感器發(fā)出的數(shù)據(jù)后，判別是否出現(xiàn)異常事件。如果是，則在指定的延遲時間內(nèi)撥報警電話號碼，撥號操作將按照重?fù)苎舆t反復(fù)進(jìn)行，直到電話接通。然后軟件系統(tǒng)負(fù)責(zé)報告時間、地點和異常事件的性質(zhì)。 開機(jī)后，軟件系統(tǒng)負(fù)責(zé)顯示當(dāng)前工作狀態(tài)，接收并處理用戶指令。,4.3 需求建模,建立軟件模型是分析活動的關(guān)鍵 目標(biāo)軟件系統(tǒng)的模型用來刻劃系統(tǒng)所涉及的信息、處理功能及系統(tǒng)運(yùn)行時的外部行為 模型不應(yīng)涉及軟件實現(xiàn)細(xì)節(jié)，這樣會分散分析人員的注意力，限制軟件設(shè)計人員的聰明才智 分析人員應(yīng)以簡潔、準(zhǔn)確、清晰的方式，系統(tǒng)地描述軟件需求模型，如選擇圖形符號表示信息流、處理功能及系統(tǒng)行為，利用受限的自然語言給出用戶需求描述 為了處理大型問題，模型表示機(jī)制應(yīng)具備良好的結(jié)構(gòu)化能力,4.3 需求建模,通常由一組模型組成 信息(或數(shù)據(jù))模型 功能模型 行為模型 最常用的兩種分析模型 結(jié)構(gòu)化分析模型 面向?qū)ο蠓治瞿Ｐ?pressman用簡明的圖形介紹了這兩種分析模型的組成結(jié)構(gòu),4.3 需求建模,結(jié)構(gòu)化分析模型,模型的核心是dd(data dictionary，數(shù)據(jù)字典)，它是系統(tǒng)所涉及的各種數(shù)據(jù)對象的總和。 從dd出發(fā)可以構(gòu)建3種圖： 1）e-r圖(entity-relation diagram，實體關(guān)系圖)：用于描述數(shù)據(jù)對象間的關(guān)系，它代表軟件的數(shù)據(jù)模型，。,2）dfd(data flow diagram，數(shù)據(jù)流圖)：主要作用是指明系統(tǒng)中數(shù)據(jù)是如何流動和變換的，以及描述數(shù)據(jù)流進(jìn)行變換的功能，在dfd中出現(xiàn)的每個功能的描述則寫在加工說明(pspec)中，一起構(gòu)成軟件的功能模型。 3）std(status transfer diagram，狀態(tài)-變遷圖)：用于指明系統(tǒng)在外部事件的作用下將會如何動作，表明了系統(tǒng)的各種狀態(tài)以及各種狀態(tài)之間的變遷，從而構(gòu)成行為模型的基礎(chǔ)，關(guān)于軟件控制方面的附加信息則包含在控制說明(cspec)中。 早期模型僅包括dd、dfd和pspec等3個組成部分，主要用于描述軟件的數(shù)據(jù)模型(用dd)與功能模型(用dfd和pspec),4.3 需求建模,面向?qū)ο蠓治瞿Ｐ?模型的核心是“使用實例”(use case)，簡稱“用例”。當(dāng)通過fast小組獲得軟件的需求后，軟件分析員即可據(jù)此創(chuàng)建一組“場景”(scenario)，每個場景包含了一個使用實例。從這些用例出發(fā)，進(jìn)一步抽取和定義ooa模型的3種模型，即： 1）類-對象模型：描述系統(tǒng)所涉及的全部類-對象，每一個類-對象都通過屬性、操作和協(xié)作者來進(jìn)行進(jìn)一步描述。,2）對象關(guān)系模型：描述對象之間的靜態(tài)關(guān)系，同時定義了系統(tǒng)中所有重要的消息路徑，它也可以具體化到對象的屬性、操作和協(xié)作者。 3）對象行為模型：描述了系統(tǒng)的動態(tài)行為，即對象在特定的狀態(tài)下如何反映外界的事件。 與結(jié)構(gòu)化分析模型相類似，上述3種模型大體上相當(dāng)于e-r圖、dfd圖和std圖，分別起到描述數(shù)據(jù)模型、功能模型與行為模型的作用。,4.4 問題的抽象、分解與多視點分析,抽象：關(guān)注一般問題的解決途徑，以此指導(dǎo)特殊問題的求解。 分析人員應(yīng)該注意用戶描述的抽象級別，統(tǒng)一規(guī)劃系統(tǒng)行為。 避免不一致性，減少分析的工作量。,分解,根據(jù)問題的規(guī)模和復(fù)雜性進(jìn)行分解，并對子問題展開進(jìn)一步的分析 逐級分解，直至子問題的規(guī)模降至合適程度 在問題分解過程中，要建立子問題之間的相互聯(lián)系 必須遵循子問題內(nèi)部緊藕合，子問題之間松藕合的原則,視點分解法,視點分解法 在分析的初期，整體地把握一個大型問題的軟件需求是困難的。需要從各個角度分別對問題進(jìn)行理解和分析，然后再綜合，達(dá)到全面理解的目的 需求分析視點 系統(tǒng)觀點 用戶觀點 信息觀點 功能觀點 行為觀點等 整理、綜合用戶描述，應(yīng)注意用戶視點的變化，避免遺漏,4 .5 支持需求分析的快速原型技術(shù),按照傳統(tǒng)的軟件開發(fā)方法，目標(biāo)軟件要等到木已成舟才能交用戶認(rèn)可。 分析、設(shè)計及編碼積累的各種問題，導(dǎo)致用戶對目標(biāo)軟件提出諸多修改，甚至全盤否決，造成人力、物力的巨大浪費(fèi)。 軟件開發(fā)早期，快速建立目標(biāo)軟件系統(tǒng)原型，讓用戶對原型進(jìn)行評估并提出意見。 原型幾經(jīng)改進(jìn)最終確定，它將進(jìn)化成軟件產(chǎn)品。 設(shè)計和編碼人員遵循原型確立的外部特征實現(xiàn)軟件產(chǎn)品。 如果軟件產(chǎn)品含有大量人機(jī)交互、可視輸出、或者涉及復(fù)雜的算法，應(yīng)采用快速原型技術(shù)。,支持需求分析的快速原型技術(shù),分析階段使用快速原型技術(shù)與問題本身的復(fù)雜度以及可用的開發(fā)工具、環(huán)境有關(guān)。 如果問題非常復(fù)雜，在當(dāng)前工具、環(huán)境的支持下開發(fā)可運(yùn)行的原型需要投入太多人力或占用太多時間，那么可對某些子問題，尤其是用戶界面，使用快速原型技術(shù)進(jìn)行部分分析。 某些軟件項目，雖不能構(gòu)造實際可運(yùn)行的快速原型，但可以采用幻燈片演示等方法，向用戶直觀描述目標(biāo)軟件系統(tǒng)的外部行為。,快速建造原型過程,(1)利用需求分析技術(shù)、方法，生成簡化的需求規(guī)格說明 (2)對簡化的需求規(guī)格說明進(jìn)行檢查、修訂，生成設(shè)計規(guī)格說明。為了快速生成原型,只關(guān)心軟件的總體結(jié)構(gòu)、用戶界面和數(shù)據(jù)設(shè)計，而不注重過程內(nèi)部的控制流。 (3)在快速原型工具或環(huán)境的幫助下，快速生成可運(yùn)行的軟件原型并進(jìn)行測試、改進(jìn)。主要工具有：可重用軟部件庫、用戶界面自動生成器等。,快速建造原型過程,(4)將原型提交用戶評估并征求改進(jìn)意見。 (5)迭代上述過程，直到用戶滿意。 通過評審的原型應(yīng)全面、準(zhǔn)確地反映用戶對目標(biāo)軟件在外部行為方面的需求，可以作為需求規(guī)格說明的一部分并成為軟件設(shè)計和編碼的基礎(chǔ)。,軟件原型的分類,探索型：目的是要弄清對目標(biāo)系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性。 實驗型：這種原型用于大規(guī)模開發(fā)和實現(xiàn)之前，考核方案是否合適，規(guī)格說明是否可靠。 進(jìn)化型：這種原型的目的不在于改進(jìn)規(guī)格說明，而是將系統(tǒng)建造得易于變化，在改進(jìn)原型的過程中，逐步將原型進(jìn)化成最終系統(tǒng)。,原型開發(fā)模型,原型開發(fā)技術(shù),可執(zhí)行規(guī)格說明 基于腳本(scenario)的設(shè)計 自動程序設(shè)計 專用語言 可復(fù)用(reusable)的軟件 簡化假設(shè),4.6 需求規(guī)格說明與評審,產(chǎn)生需求規(guī)格說明并進(jìn)行評審 需求規(guī)格說明應(yīng)成為開發(fā)過程必須遵循的指導(dǎo)原則,需求規(guī)格說明,目標(biāo) (1) 用戶通過需求規(guī)格說明可初步判定目標(biāo)軟件能否滿足需求，設(shè)計人員將需求規(guī)格說明作為軟件設(shè)計的基礎(chǔ) (2)支持目標(biāo)軟件系統(tǒng)的確認(rèn)，需求規(guī)格說明的各項需求應(yīng)該是可測試的 (3)控制系統(tǒng)進(jìn)化過程，需求分析完成后，如果用戶追加需求，開發(fā)人員再次進(jìn)行需求分析，擴(kuò)充需求規(guī)格說明，進(jìn)行軟件設(shè)計等,需求規(guī)格說明,內(nèi)容 功能、行為需求 描述系統(tǒng)的輸入、輸出及相互關(guān)系 非行為需求 描述軟件系統(tǒng)工作時應(yīng)具備的各種屬性，如效率、可靠性、安全性、可維護(hù)性、可移植性等 為使需求規(guī)格說明更加簡潔，其它內(nèi)容不應(yīng)寫入，如人員、成本、進(jìn)度、設(shè)計方案、質(zhì)量控制等。這些內(nèi)容單獨(dú)形成文檔,需求規(guī)格說明,1 引言 1.1 需求規(guī)格說明的目的 1.2 軟件產(chǎn)品的作用范圍 1.3 定義、同義詞與縮寫 1.4 參考文獻(xiàn) 1.5 需求規(guī)格說明概覽 2 一般性描述 2.1 產(chǎn)品與其環(huán)境之間的關(guān) 2.2 產(chǎn)品功能,2.3 用戶特征 2.4 限制與約束 2.5 假設(shè)與前提條件 3 特殊需求 附錄 索引,特殊需求描述,3 特殊需求 3.1 功能或行為需求 3.1.1 功能或行為需求1 3.1.1.1 引言 3.1.1.2 輸入 3.1.1.3 處理過程描述 3.1.1.4 輸出 3.1.2 功能或行為需求2 3.1.n 功能或行為需求n 3.2 外部界面需求 3.2.1 用戶界面 3.2.2 硬件界面 3.2.3 軟件界面,3.3 性能需求 3.4 設(shè)計約束 3.4.1 標(biāo)準(zhǔn)化約束 3.4.2 硬件約束 3.5 屬性 3.5.1 可用性 3.5.2安全性 3.5.3 可維護(hù)性 3.5.4 可移植性 3.6 其它需求 3.6.1 數(shù)據(jù)庫需求 3.6.2 用戶操作需求 3.6.3 工作場地需求,需求評審,需求規(guī)格說明進(jìn)入設(shè)計階段之前，必須進(jìn)行評審。如果發(fā)現(xiàn)錯誤或缺陷，應(yīng)及時糾正或更改需求分析、模型，需求規(guī)格說明，并重新評審。 衡量需求規(guī)格說明的標(biāo)準(zhǔn) 正確性 無歧義性 完全性 可驗證性 一致性 可理解性 可修改性 可追蹤性,需求評審,(1)正確性。需求規(guī)格說明書的功能、行為、性能描述必須與用戶對目標(biāo)軟件產(chǎn)品的期望相吻合。 (2)無歧義性。需求規(guī)格說明的任何語法單位只能有唯一的語義解釋。確保無歧義性的一種有效措施是在需求規(guī)格說明中使用標(biāo)準(zhǔn)化術(shù)語，并對術(shù)語的語義進(jìn)行顯式的、統(tǒng)一解釋。 (3)完全性。需求規(guī)格說明書不能遺漏