《軟體需求工程》筆記

2021-10-14 00:11:53 字數 2607 閱讀 3698

1.什麼叫客戶?

——直接或間接從產品中獲得利益的個人或組織。

2.什麼是軟體客戶?

——提出要求、支付款項、選擇、具體說明或使用軟體產品的專案風險承擔者或是獲得產品所產生的結果的人。

(ps:那麼文縐縐,誰給錢不就是客戶??)

3.完成的軟體存在的問題可能有:

對軟體的開發成本和進度的估計不準確;

使用者對已完成的系統不滿意

軟體的質量不可靠

軟體的可維護程度較低

軟體沒有適當的文件資料

軟體的成本不斷提高

軟體開發生產的效率較低

4.熟記在心:「對問題和目標的正確認識是解決任何問題的前提和出發點。」

這句話非常理性,而且看起來也很普通,但是我們卻值得我們去思考,我們遇到困難和麻煩的時候,是否做到這句話所說的「對問題和目標」有正確的認識呢?

5.需求敗因:

不完整的需求

缺乏使用者參與

不切實際的使用者期望

需求變更頻繁

提供了不再需要的需求

6.資訊系統的分類:

聯機事務處理系統(oltp)

管理資訊系統(mis)

主管資訊系統(eis)

決策支援系統(dss)

專家系統

辦公自動化系統(oa)

7.嵌入式系統(嵌入式計算機系統)

——部署在受限裝置上的嵌入式系統。

——以應用為中心,以計算機技術為基礎,能夠滿足應用對功能、效能、體積、成本、功耗等方面要求的專用系統。

(ps:說這麼多,就是一塊板子,小,但是有用,且只能專用)

(1)首要功能不是計算,而是受嵌入其中的計算機所控制的乙個系統,嵌入性和專用性的特點

(2)由軟體和硬體兩部分組成,可以面向直接使用者、面向特定的裝置以及綜合應用。

8.需求的定義

反映使用者解決問題所需要的條件,滿足類似正式規定文件的條件的一類文件說明(自己概括的)

定義「系統做什麼"而不是怎麼做

優秀需求特性:完整/正確/無歧義/可行/有優先順序/必要/可驗證性

9.魚骨圖&帕累託圖

帕累託圖,又稱排列圖、主次圖,按照發生頻率大小順序繪製的直方圖

10.軟體需求的層次:業務/使用者/功能需求

分類:功能/非功能需求、設計約束

1.需求工程:

(1)re,提供一種適當的機制,以了解使用者想要什麼、分析需求、評估可行性、協商合理的解決方案、無歧義地規約解決方案、確認規約以及在開發過程中管理這些被確認的需求規約。

(ps:太麻煩了,搞不懂)

(2)乙個不斷反覆的需求定義、文件記錄、需求演進的過程

2.需求獲取:

——涉及團隊之間的溝通、識別需要的過程。

專案範圍確定

使用者確定

用例確定

系統事件和響應

獲取方法:面向目標、面向視點、面向方面、基於場景、基於知識的方法

——需求獲取技術:問卷調查、會議討論、介面原型、可執行原型系統

3.需求分析

——需求分析是業務分析。是對問題域進行研究、提煉整合、規格化活動。

——問題域:與問題相關的部分現實世界。

——業務建模:商業建模,沒有明確定義。看作問題域吧。

任務:背景分析

確定系統邊界

需求建模:er圖、dfd圖、狀態轉換圖、類圖

需求細化

確定優先順序

需求協商

繪製關聯圖:確定系統和外部的互動,劃分了系統的範圍和界限,構建系統的對外介面(專案人員不必考慮太多細節,關注系統的介面:輸入/出)

原型開發:通過原型,讓所有涉眾對開發的專案由乙個初步的印象,同時提供對需求的檢驗。這一階段可以構建「使用者介面原型」

資料字典建立:使每個人都使用統一的定義。看作乙個共享的資料倉儲,有組織的表示每個資料物件和控制項的特性。

子系統:將需求分配到各個子系統和模組中。

4.編寫規格說明書

(1)任務:定製文件模板和編寫文件

(2)具體包含:採用軟體需求規格說明模板,為每項需求注上標號、記錄業務規範、建立需求跟蹤能力矩陣。

(3)特性:共享+更新

5.傳統的開發過程如瀑布模型

線性順序模型,開始下乙個階段的工作之前,必須完成前乙個階段的所有細節

6.敏捷開發

——」在需求難以完善/明確的情況下,由快速分析構造乙個小的原型系統,該原型系統滿足使用者的某些要求,並在使用者的使用過程中給使用者以啟發,從而逐步確定使用者的各種需求。由此產生敏捷方**。「

(1)適應使用者需求的快速變化,軟體勝過文件,輕量級的過程。

(2)xp極限程式設計:需求——測試——編碼——設計過程

(3)增量模型:當且僅當真正需要的時候才做需求工作。非整體開發模型,每個增量只完成能夠保證進入下乙個增量的工作,剩餘的細節之後完成。風險會按指數遞減。

——依賴資料建模和流建模,分別對資料、功能和行為進行建模,核心是資料字典。

——子模型:資料模型、功能模型、行為模型

1.資料建模(資料物件、屬性、關係、實體-關係圖)

2.功能建模

矩形-外部實體;

圓圈-加工/變換;

箭頭-表示乙個或多個資料項/物件;所有箭頭都應該被標記

雙線-資料儲存。

未完待續

end.

軟體需求工程 課堂筆記2

本文擷取了上課的一部分內容 ieee的需求定義 ieee1990 1 使用者為了解決問題或達到某些目標所需要的條件或能力 2 系統或系統部件為了滿足合同 標準 規範或其它正式文件所規定的要求而需要具備的條件或能力 3 對 1 或 2 中的乙個條件或一種能力的一種文件化表述。此處只講少部分的內容,或者...

軟體需求工程 課堂筆記4

本文主要來自ppt,會有一部分省略,省略的是我看不懂的地方或者覺得比較晦澀的地方 由於世界是複雜的,不同職業的人看待同一項事物,會看到不同的結果。為了保證專案涉眾以符合專案需要的角度描述現實世界,可以採取以下的做法 所有的涉眾都從共同認同的專案前景出發,理解和描述問題域及 需求 範圍內的事物和事件是...

軟體需求工程 課堂筆記9

由於出去比賽,沒有去上課,因此這份課堂筆記是我自己對照ppt腦補出來的 過程建模是結構化建模的核心方法 dfd data flow diagram 資料流圖 過程資料流 資料儲存 1.建立上下文圖 2.發現並建立dfd片斷 3.根據dfd片斷組合產生0層圖 4.對0層圖的過程進行功能分解,產生n層圖...