【軟件工程】第2章-需求分析&PKU慕課測試
文章目錄
1.需求分析的目標和方法
數據字典
2.數據流圖（系統邏輯功能）
3.E-R圖-數據模型
4.狀態轉移圖-行為模型
5.用例圖
6.面向對象建模
7.UML
8.需求規格說明
9.PKU慕課小測試
1.需求分析的目標和方法
數據字典
數據字典的四要素：
數據流、數據流分量（數據元素）、數據存儲、處理。
數據字典：關于數據的信息的集合，即對數據流圖中包含的所有元素的定義的集合。
數據元素組成數據的方法：
（1）順序 即以確定次序連接兩個或多個分量
（2）選擇 即從兩個或多個可能的元素中選取一個
（3）重復 即把指定的分量重復零次或多次
（4）可選 即一個分量是可有可無的（重復零次或一次）
2.數據流圖（系統邏輯功能）
3.E-R圖-數據模型
4.狀態轉移圖-行為模型
5.用例圖
6.面向對象建模
面向對象方法最基本的原則：
按照人們習慣的思維方式，用面向對象觀點建立問題域的模型，開發出盡可能自然地表現求解方法的軟件。
用面向對象方法開發軟件，通常需要建立3種形式的建模，它們分別是描述系統數據結構的 對象模
型，描述系統控制結構的動態模型和描述系統功能的功能模型。
一個典型的軟件系統組合了上述3個方面內容：
它使用數據結構（對象模型），執行操作（動態模型），并完成數據值的變化（功能模型）。
簡述面向對象分析設計的三個模型。
（1）
對象模型
：描述系統數據結構，表示靜態的、結構化的系統的“數據”性質。
——對象模型描述系統的靜態結構，包括類和對象，它們的屬性和操作，以及它們之間的關系。
對象模型用包含對象及對象的關系圖表示。
（2）
動態模型
：動態模型表示瞬時的、行為化的系統的“控制”性質。
——動態模型著重于系統的控制邏輯，考察在任何時候對象及其關系的改變，描述這些涉及時序和改變的狀態。動態模型包括狀態圖和事件跟蹤圖。
狀態圖是一個狀態和事件的網絡，側重于描述每一類對象的動態行為。
事件跟蹤圖則側重于說明系統執行過程中的一個特點“場景”，也叫做腳本(scenarios)，是完成系統某個功能的一個事件序列。腳本通常起始于一個系統外部的輸入事件，結束于一個系統外部的輸出事件。
（3）
功能模型
：功能模型表示變化的系統的“功能”性質，它指明了系統應該“做什么”，因此更直接地反映了用戶對目標系統的需求。
——功能模型著重于系統內部數據的傳送和處理。
功能模型表明，通過計算，從輸出數據能得到什么樣的輸出數據，但不考慮參加計算的數據按什么時序執行。功能模型由多個數據流圖組成，它們指明從外部輸出，通過操作和內部存儲，直到外部輸出的整個數據流情況。功能模型還包括了對象模型內部數據間的限制。功能模型中的數據流圖往往形成一個層次結構，一個數據流圖的過程可以由下一層的數據流圖作進一步的說明。
7.UML
統一建模語言(Unified Modeling Language，UML)是一種為面向對象系統的產品進行說明、可視化和編制文檔的一種標準語言.
（1）UML 里面有哪些圖？
UML 圖包括九種：使用案例圖、類圖、對象圖、構件圖、部署圖、活動圖、協作圖、狀態圖、序列圖。
在這些圖中使用
案例圖、類圖、序列圖
是最有用的。
1、需求
采用用例圖描述需求。
2、 分析
采用類圖描述靜態結構
采用順序圖、合作圖、活動圖、狀態圖描述動態行為
3、設計
采用類圖、包，對類的接口進行設計
4、 實現
將類用某現象對象語言實現
5、繼承與交付
構件圖、包、部署圖
6、 測試
單元測試——類圖和類的說明書
8.需求規格說明
9.PKU慕課小測試
第二周：軟件需求
需求的作用
1、判斷題：相比硬件而言，軟件更容易被修改，而且更容易被正確地進行修改。×
2、單選題：與軟件工程不同，（A）是系統工程所追求的目標。
A.
最優化
B.系統化
C.一體化
D.情境化
3、判斷題：任何軟件開發過程必須從軟件需求入手。√
4、判斷題：采用瀑布模型的開發過程是一種自頂向下的開發方法，而軟件構件復用的開發過程是一種自底向上的開發方法。√
需求的定義
1、判斷題：軟件需求是待開發產品或系統的功能描述。×
2、單選題：下面不屬于需求的基本性質是（D）
A.必要性
B.無歧義性
C.可測性
D.
可擴展性
3、多選題：下列哪些陳述可以作為軟件需求（BD）
A.系統應支持大規模并發用戶訪問
B.
用戶需憑用戶名和密碼登陸之后才可使用系統
C.系統界面要美觀大方
D.
當用戶登錄失敗時，應彈窗提示失敗原因
需求的分類
1、判斷題：
非功能需求必須依附于功能需求而存在
。√
2、單選題：下列需求屬于性能需求的是（A）
A.
并發訪問數
B.網絡協議
C.異常響應
D.用戶友好
3、單選題：下列需求屬于外部接口需求的是（A）
A.
第三方插件
B.安全隱私
C.編程語言
D.字體字號
4、單選題：下列需求屬于設計約束的是（B）
A.響應時間
B.
運行平臺
C.錯誤處理
D.可維護
5、填空題：與其他類型的非功能需求不同，（
設計約束
）是必須予以滿足的，且對項目規劃、所需的附加成本和工作產生直接影響。
6、判斷題：
質量屬性必須要給出量化的測量指標
。√
需求發現
1、單選題：當無法與用戶進行直接交流時，可采用（A）的需求發現方式。
A.
自悟
B.提煉
C.小組會
D.思考
2、多選題：下列哪些是觀察這一需求發現的方法可能帶來的問題。（BC）
A.無法全面了解需求
B.
被客戶抵觸
C.讓客戶誤以為開發者已經熟悉了業務
D.消耗過多的時間
3、判斷題：小組會和交流這兩種需求發現方式的區別在于參加人員的多少。×
4、判斷題：需求發現常采用多種方式聯合進行，但具體某一項需求常采用某一種具體的方式去捕獲。×
5、單選題：下述情況分別最適合采取哪種需求發現的方式（A）
① 為解決生活中遇到的麻煩事而開發的軟件
② 有較多繁瑣環節的社區醫保系統的開發
③ 某小型團體組織開發其內部人員管理系統
④ 某大型連鎖集團開發集團人員管理系統
⑤ 某專業化軟件外包公司接手爛尾的軟件開發項目 //爛尾項目已經有部分需求文檔，適合用提煉
A.①-自悟；②-觀察；③-交流；④-小組會；⑤-提煉
B.①-觀察；②-自悟；③-小組會；④-交流；⑤-提煉
C.①-自悟；②-交流；③-觀察；④-提煉；⑤-小組會
D.①-提煉；②-自悟；③-交流；④-觀察；⑤-小組會
需求規約的概念和格式
1、單選題：需求規約是一個軟件產品/系統的（C）
A.開發模型
B.框架模型
C.
概念模型
D.功能模型
2、判斷題：需求規約是一個軟件產品所有需求陳述的正式文檔，它是不能被修改的。×
3、多選題：下列哪些是需求規約的性質。（ABD）
A.
完整性
B.
一致性
C.不可修改性
D.
穩定性
需求規約的作用
1、多選題：基于需求規約會產生下述哪兩個文檔。（AC）
A.
初始測試計劃
B.系統測試計劃
C.
用戶系統操作描述
D.軟件可行性分析報告
2、單選題：在需求分析階段會形成（C）的測試計劃。
A.單元測試
B.集成測試
C
確認測試
D.系統測試
3、判斷題：
需求規約是軟件開發組織和用戶之間的技術合同書，只有當需求規約完成后才能開始產品的設計
。√
4、判斷題：需求規約對于項目的大多數工作是一個管理控制點，因此需求規約中要給出軟件項目的進度和規劃。×
5、判斷題：需求規約作為設計的一個正式的、受控的起始點，它事實上給出了一份初步的設計文檔。×
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。
相關文章
