03軟件需求工程(文件)
【正文】 建模法 ? 面向?qū)ο蟮姆治龇椒? (OOA) 36 功能分解方法 將系統(tǒng)看作若干功能模塊的集合 ， 每個功能又可以分解為子功能 ,子功能還可繼續(xù)分解 ,分解的結(jié)果即是系統(tǒng)的雛形 。它適合于分析大型的數(shù)據(jù)處理系統(tǒng)，特別是企事業(yè)管理系統(tǒng)。 是由實(shí)體 、 屬性和關(guān)系組成的網(wǎng)絡(luò)圖 。 DFD中每個功能的描述包含在加工規(guī)約 (小說明 )。 3．如果被開發(fā)軟件只是一個基于計算機(jī)的系統(tǒng)中的一個元素，那么整個大系統(tǒng)也包括在規(guī)格說明的描述之中。 7．規(guī)約必須允許不完備性并允許擴(kuò)充。 51 需求規(guī)約 IEEE/ANSI8301993 簡化大綱 Ⅰ . 引言 Ⅱ . 信息描述 ： ⅰ 數(shù)據(jù)流 ⅱ 控制流 Ⅲ . 功能描述 ： ⅰ 處理說明 ⅱ 限制 ∕局限 ⅲ 性能需求 ⅳ 設(shè)計約束 ⅴ 支撐圖 ⅰ 控制規(guī)約 ⅱ 設(shè)計約束 Ⅳ . 行為描述 Ⅴ . 檢驗(yàn)標(biāo)準(zhǔn) Ⅵ . 參考書目 Ⅶ . 附錄 52 ? 引言： 陳述軟件目標(biāo)，在基于計算機(jī)的系統(tǒng)語境內(nèi)進(jìn)行描述。 ? 行為描述： 描述作為外部事件和內(nèi)部產(chǎn)生的控制特征的軟件操作。 ? 參考書目： 包含了對所有和該軟件相關(guān)的文檔的引用，其中包括其他的軟件工程文檔、技術(shù)參考文獻(xiàn)、廠商文獻(xiàn)以及標(biāo)準(zhǔn)。 二 ) 需求驗(yàn)證的內(nèi)容 — 指功能需求是否符合用戶所提出的需求 。 54 需求開發(fā)過程 可行性研究 需求獲取 和分析 需求描述 需求有效性 驗(yàn)證 可行性報告 系統(tǒng)模型 用戶需求和 系統(tǒng)需求 需求文擋 55 二、需求管理 ?需求管理是一組用于幫助項(xiàng)目組在項(xiàng)目進(jìn)展中的任何時候去標(biāo)識、控制和跟蹤需求的活動 ?需求管理 的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。 ? 同時從個人素質(zhì)上，分析師應(yīng)善于從原始材料中抽象出邏輯概念，將其重新整理之后成為各種邏輯成分，并根據(jù)各種邏輯成分綜合出問題的解決辦法，并善于用模型說話； ? 能從沖突或者混淆中吸取恰當(dāng)事實(shí)的能力； ? 能弄清用戶環(huán)境的能力； ? 能為用戶系統(tǒng)恰當(dāng)配置軟硬件的能力 ? 能較好地用書面和口頭形式進(jìn)行溝通的能力 ? 有 “ 從樹木見森林 ” 的能力。 本階段常用的有 SA法 ， OOA法 等 。 在開發(fā)者一方 ， 參與工作的主要 角色 是系統(tǒng)分析員和系統(tǒng)工程師等 ， 負(fù)責(zé)溝通用戶和開發(fā)人員的認(rèn)識和見解 ， 起著橋梁作用 。 需求狀態(tài)跟蹤 ? 定義需求狀態(tài) ? 跟蹤所有需求狀態(tài) 56 需求管理的所有活動中，最重要的是 需求變更管理，包括 : 問題分析和變更描述 變更分析和成本計算 變更實(shí)現(xiàn) 修正后的需求 識別出的問題 需求管理過程需要 CASE (Computer Aided Software Engineering) 工具支持 。 — 是否包含所有系統(tǒng)用戶的需求和 約束 。 53 (四 )、需求的有效性驗(yàn)證 需求驗(yàn)證目的是要檢驗(yàn)需求是否能夠反映用戶的意愿 一 ) 需求驗(yàn)證的重要性 １ . 由于需求分析是軟件開發(fā)的第一階段，直接影響后面各階段的開發(fā)。即對系統(tǒng)進(jìn)行什么樣的測試，得到什么樣的結(jié)果，就表示系統(tǒng)已經(jīng)成功實(shí)現(xiàn)了。 ? 功能描述： 描述解決問題所需的每個功能。它所包括的信息必須局部化，這樣當(dāng)信息被修改時，只要修改某個單個的段落（理想情況）。 50 需求規(guī)約的原則 (續(xù) ) 5．規(guī)約必須是一個認(rèn)識模型，而不是設(shè)計或?qū)崿F(xiàn)的模型。 48 (三 )需求規(guī)格說明 (需求規(guī)約 ) ? 采用原始模板，在你的組織中要為編寫軟件需求文檔定義一種標(biāo)準(zhǔn)模板 ? 指明需求的來源 ? 為每項(xiàng)需求注上標(biāo)號制定一種慣例來為每項(xiàng)需求提供一個獨(dú)立的可識別的標(biāo)號或記號 ? 記錄業(yè)務(wù)規(guī)范 49 需求規(guī)約的原則 1．從現(xiàn)實(shí)中分離功能，即描述要 “ 做什么 ” 而不是 “ 怎樣實(shí)現(xiàn) ” 。 41 需求協(xié)商 ? 協(xié)商的過程就是討論需求沖突，找出每個人都滿意的折衷方案 ? 協(xié)商不是簡單的邏輯或技術(shù)上的爭論 ? 要注意組織和行政方面的因素 ①不一致的目標(biāo) ②責(zé)任的喪失或轉(zhuǎn)移 ③組織文化 ④組織管理態(tài)度和士氣 ⑤部門差異 42 ? 通常會議是解決沖突最快的方式 – 參加者應(yīng)該包括發(fā)現(xiàn)沖突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的項(xiàng)目相關(guān)人員 – 會議應(yīng)該討論那些非正式討論不能解決的問題 – 通常會議分為三個階段： ? 敘述階段 ? 討論階段 ? 決策階段 43 需求建模 ? 在軟件需求分析階段，所創(chuàng)建的模型，要著重于描述系統(tǒng)要 做什么 ，而不是 如何去做 ? 目標(biāo)軟件的模型不應(yīng)涉及軟件實(shí)現(xiàn)細(xì)節(jié) 典型分析建模方法 ?結(jié)構(gòu)化分析 (傳統(tǒng)建模方法 ) ?面向?qū)ο蠓治? 44 計算機(jī)世界 現(xiàn)實(shí)世界 結(jié) 構(gòu) 化 開 發(fā) 方 法 結(jié)構(gòu)化 分析 結(jié)構(gòu)化 設(shè)計
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1