本文擷取了上課的一部分內容
ieee的需求定義[ieee1990]：此處只講少部分的內容，或者只說一些片段。這些部分是我比較容易理解或接受的。（1）使用者為了解決問題或達到某些目標所需要的條件或能力；
（2）系統或系統部件為了滿足合同、標準、規範或其它正式文件所規定的要求而需要具備的條件或能力；
（3）對（1）或（2）中的乙個條件或一種能力的一種文件化表述。
由於翻譯人員的不同，因此有兩種表述，在我院的課程中，規格說明使用較多，但是「規約」一詞使用更為廣泛。
[ieee1998]將需求分成下列類別：下面的內容可能會有一點亂：
模擬並操縱共享現象是軟體系統滿足需求最直接的方法，但有些情況下軟體系統也會使用間接的方法解決問題：軟體系統操縱共享現象影響問題域的一部分，然後利用問題域內在的規律性自動影響另一部分。例如，圖書管理員希望能夠督促那些超期的借書者盡快歸還圖書，直接的解決方式是軟體系統將借書者的****建模為表contact，並自動使用contact的資料完成督促告知（比如傳送郵件）。但是如果軟體系統中沒有儲存借書者的****contact，也就是說軟體系統的共享知識中沒有解決問題需要的資訊，就只能通過間接的方式來滿足需求了，這時軟體系統可以將超期者的名單告知圖書管理員，然後由圖書管理員逐一**進行督促歸還。 考慮問題解決和需求滿足的方法時，成本是重要的因素，如果成本能夠接受，就盡量使用直接的方式進行解決，如果成本太高，就可以折中使用間接方式進行解決。
在三個層次中，只有使用者需求在表述時在不可驗證性上要求較為寬鬆。因為使用者需求具有下面幾個特點：①模糊、不清晰。使用者需求允許適度使用形容詞和副詞，使得描述常常帶有模糊和不清晰的特性；②多特性混雜。在使用者進行需求描述時，常常將功能需求和非功能需求混雜在一起；③多邏輯混雜。使用者需求是對使用者任務的描述，而任務本身往往含有前後相繼的多個邏輯處理過程，即乙個任務需要進行多次的系統互動才能夠完成。
軟體需求工程 課堂筆記4
本文主要來自ppt，會有一部分省略，省略的是我看不懂的地方或者覺得比較晦澀的地方 由於世界是複雜的，不同職業的人看待同一項事物，會看到不同的結果。為了保證專案涉眾以符合專案需要的角度描述現實世界，可以採取以下的做法 所有的涉眾都從共同認同的專案前景出發，理解和描述問題域及 需求 範圍內的事物和事件是...
軟體需求工程 課堂筆記9
由於出去比賽，沒有去上課，因此這份課堂筆記是我自己對照ppt腦補出來的 過程建模是結構化建模的核心方法 dfd data flow diagram 資料流圖 過程資料流 資料儲存 1.建立上下文圖 2.發現並建立dfd片斷 3.根據dfd片斷組合產生0層圖 4.對0層圖的過程進行功能分解，產生n層圖...
《軟體需求工程》筆記
什麼叫客戶？直接或間接從產品中獲得利益的個人或組織。什麼是軟體客戶？提出要求 支付款項 選擇 具體說明或使用軟體產品的專案風險承擔者或是獲得產品所產生的結果的人。ps 那麼文縐縐，誰給錢不就是客戶？完成的軟體存在的問題可能有 對軟體的開發成本和進度的估計不準確 使用者對已完成的系統不滿意 軟體的質量...