Lect需求分析基礎(chǔ)

1、蘭州大學(xué)信息科學(xué)與工程學(xué)院需求分析基礎(chǔ)Descriptions and specifications of a system123ES2022-7-7蘭州大學(xué)信息學(xué)院2主要內(nèi)容 需求分析的任務(wù) 獲取需求的方法 需求建模與分析 需求規(guī)格說明及評(píng)審123ES2022-7-7蘭州大學(xué)信息學(xué)院3軟件需求 軟件需求：是指用戶對(duì)目標(biāo)軟件在功能、行為、性能、設(shè)計(jì)約束等方面的要求 通過對(duì)應(yīng)用問題及其韓靜的理解與分析，為問題涉及的信息、功能及系統(tǒng)行為建立模型，將用戶需求精確化、完全化，最終形成需求規(guī)格說明 構(gòu)成軟件開發(fā)生命周期的需求分析階段 需求分析介于系統(tǒng)分析和軟件設(shè)計(jì)階段之間 以系統(tǒng)規(guī)格說明和項(xiàng)目規(guī)劃作為分

2、析活動(dòng)的基本出發(fā)點(diǎn)，并從軟件角度對(duì)它們進(jìn)行檢查與調(diào)整 需求規(guī)格說明是軟件設(shè)計(jì)、實(shí)現(xiàn)、測試直至維護(hù)的主要基礎(chǔ) 良好的分析活動(dòng)有助于避免或盡早剔除早期錯(cuò)誤，提高軟件生產(chǎn)率，降低開發(fā)成本，改進(jìn)軟件質(zhì)量123ES2022-7-7蘭州大學(xué)信息學(xué)院4軟件需求 用戶對(duì)應(yīng)用問題的理解、描述亦即他們對(duì)目標(biāo)軟件的要求往往具有片面性、模糊性，甚至不一致性 問題的規(guī)模較大時(shí)，對(duì)這些特征的處置非常棘手 大中型軟件項(xiàng)目的需求分析階段，必須使用系統(tǒng)的方法學(xué)，并借助一些行之有效的技術(shù)和工具123ES2022-7-7蘭州大學(xué)信息學(xué)院5軟件需求 需求的分類： 功能性需求：業(yè)務(wù)功能及操作對(duì)象 非功能性需求：性能約束等 其他約束：開

3、發(fā)、運(yùn)行環(huán)境等123ES2022-7-7蘭州大學(xué)信息學(xué)院6需求分析與軟件過程系統(tǒng)工程需求分析軟件設(shè)計(jì)需求規(guī)格說明書評(píng)審系統(tǒng)架構(gòu)設(shè)計(jì)開發(fā)計(jì)劃修訂需求質(zhì)量保證需求獲取驗(yàn)證方法其他文檔：需求定義用戶使用手冊系統(tǒng)架構(gòu)設(shè)計(jì)開發(fā)計(jì)劃123ES2022-7-7蘭州大學(xué)信息學(xué)院7需求來源123ES2022-7-7蘭州大學(xué)信息學(xué)院8需求過程123ES2022-7-7蘭州大學(xué)信息學(xué)院9需求的層次ProblemSolution SpaceProblem SpaceNeedsFeaturesSoftwareRequirementsThe Product to Be BuiltTraceability123ES2022

4、-7-7蘭州大學(xué)信息學(xué)院101 需求分析的任務(wù)與原則需求分析分為問題分析、需求描述及需求評(píng)審3個(gè)階段問題分析：獲取并理解、分析、綜合問題定義，剔除初始需求的模糊、歧義、不一致等，并形成需求定義文檔。需求描述：以計(jì)算機(jī)軟件技術(shù)描述需求定義，并形成需求規(guī)格說明書需求評(píng)審：對(duì)需求的工作進(jìn)行審核。需求分析目標(biāo)：完整、準(zhǔn)確、充分地定義問題。問題分析需求描述規(guī)格說明需求評(píng)審123ES2022-7-7蘭州大學(xué)信息學(xué)院11問題分析階段分析人員通過對(duì)問題及其環(huán)境的理解、分析和綜合，清除用戶需求的模糊性、歧義性和不一致性，并在用戶幫助下對(duì)相互沖突的需求進(jìn)行折衷分析人員應(yīng)將自己對(duì)原始問題的理解與軟件開發(fā)經(jīng)驗(yàn)結(jié)合起來

5、，以發(fā)現(xiàn)由于用戶的片面性或短期行為所導(dǎo)致的不合理要求，以及用戶尚未提出但具有真正價(jià)值的潛在需求用戶群體中的各個(gè)用戶往往會(huì)從不同的角度、在不同的抽象級(jí)別上闡述他們對(duì)原始問題的理解和對(duì)目標(biāo)軟件的需求，因此，有必要為原始問題及其軟件解建立模型123ES2022-7-7蘭州大學(xué)信息學(xué)院12問題分析階段該模型一方面用于精確地記錄用戶從各個(gè)視點(diǎn)、在不同抽象級(jí)別上對(duì)原始問題及目標(biāo)軟件的描述另一方面，它也將幫助分析人員發(fā)現(xiàn)用戶需求中的不一致性，排成不合理的部分，挖掘潛在的用戶需求該模型可視為分析人員關(guān)于原始問題及其軟件解的一種只是結(jié)構(gòu)，包含問題及其環(huán)境所涉及的信息流、處理功能、用戶界面、行為模型及設(shè)計(jì)約束是形

6、成需求規(guī)格說明、進(jìn)行軟件設(shè)計(jì)與實(shí)現(xiàn)的主要基礎(chǔ)123ES2022-7-7蘭州大學(xué)信息學(xué)院13需求描述階段 主要任務(wù)是以需求模型為基礎(chǔ)，考慮到問題的軟件可解性，生成需求規(guī)格說明和初步的用戶手冊 需求規(guī)格說明包含對(duì)目標(biāo)軟件系統(tǒng)外部行為的完整描述、需求驗(yàn)證標(biāo)準(zhǔn)以及用戶在性能、質(zhì)量、可維護(hù)性等方面的要求 用戶手冊則包括用戶界面描述以及有關(guān)目標(biāo)軟件使用方法的初步構(gòu)想 生成這兩個(gè)文檔過程中，分析人員應(yīng)該嚴(yán)格遵循既定規(guī)范，做到內(nèi)容全面、結(jié)構(gòu)清晰、措辭準(zhǔn)確、格式嚴(yán)謹(jǐn) 將初步的用戶手冊作為分析文檔之一有助于分析人員從用戶的角度考慮軟件需求，并鼓勵(lì)用戶盡早開始對(duì)軟件開發(fā)活動(dòng)進(jìn)行檢查和評(píng)估123ES2022-7-7蘭

7、州大學(xué)信息學(xué)院14需求評(píng)審階段 分析人員要在用戶和軟件設(shè)計(jì)人員的配合下對(duì)自己生成的需求規(guī)格說明和初步的用戶手冊進(jìn)行復(fù)核，以確保軟件需求的全面性、精確性和一致性，并使用戶和軟件設(shè)計(jì)人員對(duì)需求規(guī)格說明及用戶手冊的理解達(dá)成一致 一旦發(fā)現(xiàn)遺漏或模糊點(diǎn)，必須盡快更正，再行檢查 需求規(guī)格說明得到用戶和軟件開發(fā)方的一致確認(rèn)后，應(yīng)成為用戶方與軟件開發(fā)方之間的合同，任何增刪或改動(dòng)都將引起開發(fā)規(guī)劃及成本的變化，應(yīng)由提出方承擔(dān)經(jīng)濟(jì)責(zé)任 分析活動(dòng)并不一定在時(shí)序上嚴(yán)格遵循上述3個(gè)步驟123ES2022-7-7蘭州大學(xué)信息學(xué)院15原則 必須深層次地挖掘用戶的潛在需求 剔除不合理、不切實(shí)際的需求 定義需求的優(yōu)先級(jí) 一般需要

8、建立大量人機(jī)交互原型 避免定性的描述需求123ES2022-7-7蘭州大學(xué)信息學(xué)院162 需求獲取技術(shù) 訪談與會(huì)議 觀察用戶工作流程 由用戶參加的聯(lián)合小組 咨詢領(lǐng)域?qū)＜椰F(xiàn)場觀察同類項(xiàng)目研究走訪調(diào)查問卷需求獲取技術(shù)現(xiàn)行系統(tǒng)分析聯(lián)合團(tuán)隊(duì)小型會(huì)議123ES2022-7-7蘭州大學(xué)信息學(xué)院17需求獲取技術(shù) 為了完成分析任務(wù)，分析人員必須掌握一些基本技術(shù) 初步需求獲取技術(shù) 需求建模技術(shù) 問題抽象與分解技術(shù) 多視點(diǎn)分析技術(shù) 快速原型技術(shù)123ES2022-7-7蘭州大學(xué)信息學(xué)院18初步需求獲取技術(shù) 分析階段初期，分析人員對(duì)問題知之甚少，用戶對(duì)問題的描述、對(duì)目標(biāo)軟件的要求通常相當(dāng)凌亂、模糊 分析人員與用戶共

9、同的只是領(lǐng)域不多，造成相互理解方面的問題123ES2022-7-7蘭州大學(xué)信息學(xué)院19初步需求獲取技術(shù) 訪談與會(huì)議 分析人員以個(gè)別訪談或小組會(huì)議的形式與用戶溝通 訪談或會(huì)議前，分析人員按以下原則精心準(zhǔn)備一系列問題，通過用戶對(duì)問題的回答獲取有關(guān)問題及環(huán)境的知識(shí)，逐步理解用戶對(duì)目標(biāo)軟件的要求 問題應(yīng)該是循序漸進(jìn)的，首先關(guān)心一般性、整體性問題，然后討論細(xì)節(jié)性問題 所提問題不應(yīng)限制用戶在回答過程中進(jìn)行自由發(fā)揮，要求分析人員組織問題時(shí)盡量客觀、公正 逐步提出的問題在匯總后應(yīng)能反應(yīng)應(yīng)用問題或其子問題的全貌，并覆蓋用戶對(duì)目標(biāo)軟件或其子系統(tǒng)在功能、行為、性能諸方面的要求 細(xì)節(jié)問題可以留待以后解決123ES20

10、22-7-7蘭州大學(xué)信息學(xué)院20觀察用戶工作流程 實(shí)際觀察用戶的手工操作過程是一種行之有效的需求獲取方法 觀察過程中，分析人員應(yīng)注意 軟件系統(tǒng)不只是模擬手工操作 更好的經(jīng)濟(jì)效益 最快的處理速度 最合理的操作流程 最友好的用戶界面 分析人員不僅要被動(dòng)地接受用戶關(guān)于應(yīng)用問題及背景知識(shí)，而且還要結(jié)合自己的軟件開發(fā)和軟件應(yīng)用經(jīng)驗(yàn)，主動(dòng)剔除不合理的的用戶需求，從軟件角度改進(jìn)操作流程或規(guī)范，提出新的潛在用戶需求123ES2022-7-7蘭州大學(xué)信息學(xué)院21用戶和開發(fā)人員共同組成聯(lián)合小組 分析階段的初期，用戶和分析人員彼此陌生，知識(shí)領(lǐng)域好工作側(cè)重各不相同 分析人員和用戶通過問答和文檔進(jìn)行溝通，但有可能抑制了

11、用戶在分析過程中的主動(dòng)性，阻礙了良好的協(xié)同工作關(guān)系，容易導(dǎo)致誤解和遺漏 有必要建立有軟件開發(fā)方和用戶共同組成的聯(lián)合小組，參加小組的用戶也屬于分析人員，他們對(duì)分析的成功負(fù)有同等重要的責(zé)任 聯(lián)合小組要制定自己的工作計(jì)劃，確定專門的記錄員并另設(shè)專人負(fù)責(zé)會(huì)議的議程和資料的綜合、整理 必須選定一種易于理解并盡可能簡潔、精確地表示機(jī)制作為共同語言，例如輔以文字說明的流程圖123ES2022-7-7蘭州大學(xué)信息學(xué)院223 需求建模 目標(biāo)軟件系統(tǒng)的模型用來刻劃系統(tǒng)所涉及的信息、處理功能及實(shí)際運(yùn)行時(shí)的外部行為 分析階段建造的模型不應(yīng)涉及軟件實(shí)現(xiàn)細(xì)節(jié)，以免分散分析人員的注意力，限制軟件設(shè)計(jì)人員為提高軟件的質(zhì)量和效

12、率而選擇實(shí)現(xiàn)方法的自由度 分析人員應(yīng)選定一些圖形記號(hào)分別表示信息流、處理功能及系統(tǒng)行為，并利用受限的自然語言給出用戶需求的描述 為了處理大型問題，模型的表示機(jī)制還應(yīng)具備良好的結(jié)構(gòu)化能力123ES2022-7-7蘭州大學(xué)信息學(xué)院23需求建模 立軟件模型是分析活動(dòng)的焦點(diǎn) 模型以簡潔、準(zhǔn)確、結(jié)構(gòu)清晰的方式系統(tǒng)地描述軟件需求，便于分析人員剔除用戶描述中的模糊性和不一致性，并使軟件需求趨于完全 分析過程實(shí)對(duì)軟件模型的建造和不斷完善 分析的初期，開發(fā)方和用戶方的聯(lián)合小組通過訪談、會(huì)議及實(shí)際觀察為構(gòu)筑模型收集素材，也利用初步模型作為小組內(nèi)部相互溝通的需求表示機(jī)制 此后，分析人員利用面向數(shù)據(jù)流的分析方法、面向

13、對(duì)象的分析方法、面向數(shù)據(jù)的分析方法和形式化方法對(duì)模型進(jìn)行精確化、一致化、完全化，最終的軟件模型既是生成需求規(guī)格說明的基礎(chǔ)，又是軟件設(shè)計(jì)和實(shí)現(xiàn)的基礎(chǔ)123ES2022-7-7蘭州大學(xué)信息學(xué)院244 問題抽象、問題分解、多視點(diǎn)分析 抽象抽象方法要求分析人員在分析過程中善于捕捉用戶描述或問題本身所固有的一般-特殊關(guān)系：首先關(guān)注一般問題的解決途徑，進(jìn)而指導(dǎo)特殊問題的求解 分析人員應(yīng)該注意用戶描述所處的不同抽象級(jí)別，以從雜亂零散中建立清晰的思路123ES2022-7-7蘭州大學(xué)信息學(xué)院254 問題抽象、問題分解、多視點(diǎn)分析 問題分解問題分解是普遍適用于分析個(gè)階段的一般性方法 由于問題的規(guī)模好復(fù)雜度，往往

14、需要通過對(duì)各個(gè)子問題的理解和分析來實(shí)現(xiàn)對(duì)整個(gè)問題的理解 在分析階段，可將問題分解為數(shù)個(gè)子問題，并分別針對(duì)子問題展開分析活動(dòng) 分解可以逐級(jí)進(jìn)行，直至子問題的規(guī)模將之合適程度 在子問題的整合過程中，則要自底向上建立各個(gè)子問題之間的聯(lián)系，但聯(lián)系不宜過分復(fù)雜 分解原則：各個(gè)子問題具有較強(qiáng)的獨(dú)立性，子問題之間具有松耦合性123ES2022-7-7蘭州大學(xué)信息學(xué)院26問題抽象、問題分解、多視點(diǎn)分析 多視點(diǎn)分析多視點(diǎn)分析 分析初期，從全局觀點(diǎn)整體地把我一個(gè)大型問題的軟件需求叫困難 有必要從各個(gè)角度分別對(duì)問題進(jìn) 行理解和分析，然后綜合成為全 面理解 分析人員在整理用戶描述的過程 中應(yīng)注意用戶視角的變化，表明

15、由于視角不全而引起的需求遺漏 可用的視點(diǎn) 系統(tǒng)觀點(diǎn) 用戶觀點(diǎn) 信息觀點(diǎn) 功能觀點(diǎn) 行為觀點(diǎn)123ES2022-7-7蘭州大學(xué)信息學(xué)院275 快速原型技術(shù) 在軟件開發(fā)早期，快速建立目標(biāo) 軟件系統(tǒng)的原型，讓用戶對(duì)原型 進(jìn)行評(píng)估并提出修改意見 當(dāng)原型經(jīng)過改進(jìn)最終確定，將由 軟件設(shè)計(jì)和編碼階段演化為軟件 產(chǎn)品 設(shè)計(jì)和編碼人員根據(jù)原型所確立 的外部特征實(shí)現(xiàn)軟件產(chǎn)品123ES2022-7-7蘭州大學(xué)信息學(xué)院28步驟 利用各種分析技術(shù)、方法，生成一個(gè)簡化的需求規(guī)格說明 對(duì)需求規(guī)格說明進(jìn)行檢查、修訂，生成設(shè)計(jì)規(guī)格說明：只關(guān)心軟件的總體結(jié)構(gòu)、用戶界面和數(shù)據(jù)設(shè)計(jì)，不注重過程內(nèi)部的控制流程 在現(xiàn)有工具或環(huán)境的幫助下

16、快速生成可運(yùn)行的軟件原型并進(jìn)行測試、改進(jìn) 將原型提交用戶評(píng)估并收集用戶的改進(jìn)意見 上述過程反復(fù)進(jìn)行，知道用戶完全認(rèn)可123ES2022-7-7蘭州大學(xué)信息學(xué)院296 需求規(guī)格說明和評(píng)審 需求規(guī)格說明書的目標(biāo) 便于用戶、分析人員和軟件設(shè)計(jì)人員進(jìn)行理解和交流 支持目標(biāo)軟件系統(tǒng)的確認(rèn) 控制系統(tǒng)的演進(jìn)過程 注意： 描述方法要與建模方法相對(duì)應(yīng) 可以多種描述方法相結(jié)合 描述的抽象層次要一致 描述一定要精確、準(zhǔn)確 單一123ES2022-7-7蘭州大學(xué)信息學(xué)院30需求規(guī)格說明書(Co.)引言需求規(guī)格說明書的目的軟件產(chǎn)品的作用范圍定義、同義詞和縮略語參考文獻(xiàn)需求規(guī)格說明書概覽一般性描述產(chǎn)品與其環(huán)境之間的關(guān)系產(chǎn)

17、品功能用戶特征限制與約束假設(shè)與前提條件需求描述功能需求N 引言 輸入 處理 輸出外部界面需求N 用戶界面 硬件界面 軟件界面性能需求N設(shè)計(jì)約束N 標(biāo)準(zhǔn)化約束 硬件約束 屬性 可用性 可靠性 安全性 可移植性 其他需求 數(shù)據(jù)庫需求 用戶操作需求 用戶場地需求 17123ES2022-7-7蘭州大學(xué)信息學(xué)院31需求評(píng)審 評(píng)審標(biāo)準(zhǔn) 正確性：正確性：功能、行為、性能描述與用戶對(duì)目標(biāo)軟件的期望一致 無歧義性：無歧義性：使用標(biāo)準(zhǔn)化術(shù)語 完全性：完全性：無遺漏 可驗(yàn)證性：可驗(yàn)證性：技術(shù)、經(jīng)濟(jì)上可行的首段進(jìn)行驗(yàn)證 一致性：一致性：無相互矛盾 可理解性：可理解性：不宜用過多的專業(yè)化詞匯 可修改性：可修改性：容易接納后續(xù)的增、刪和修改 可追蹤性：可追蹤性：與原始需求聯(lián)系123ES2022-7-7蘭州大學(xué)信息學(xué)院32小結(jié) 明確需求的概念與任務(wù)、過程、方法 問題的抽象與抽象層次 成果：軟件需求規(guī)格說明書123ES2022-7-7蘭州大學(xué)信息學(xué)院33需求的重要性 The top factors are: Incomplete requirements (13.1%) x Lack of user involvement (12.4%) x Lack of resources (10.6%) Unrealistic expectations (9.9%) x Lack of executive sup