基礎與框架
第一章 動機
一熙掺、軟件密集型系統(tǒng)
- 定義：一個系統(tǒng)的功能和（或）質(zhì)量的核心部分是通過軟件實現(xiàn)的
信息系統(tǒng)：對信息或數(shù)據(jù)進行收集、存儲、轉換悠鞍、處理。
嵌入式軟件密集型系統(tǒng)：軟件和硬件密切地集成在一起模燥。
- 面臨的問題：
基于軟件的創(chuàng)新
日益增加的復雜性
降低成本的壓力
更短的開發(fā)時間
更高的質(zhì)量要求
二咖祭、需求工程的意義
- 需求缺陷
e.g 倫敦救護車服務計算機輔助調(diào)度系統(tǒng)（LAS）
在開發(fā)后期一處需求缺陷的成本很高
- 組織上下文中的需求工程
第二章 需求
一、需求的定義
IEEE 610.12-1990 標準將術語需求定義為：
用戶解決某個問題或者達到某個目標所需要的條件或能力
一個系統(tǒng)或系統(tǒng)組建為了實現(xiàn)某個契約蔫骂、不標準心肪、規(guī)格說明或其他需要遵循的文件而必須滿足的條件或擁有的能力
對上述條件或能力的文檔化表示
文檔化的需求被稱為“需求制品”
二、需求類型
- 功能性需求
系統(tǒng)應該向用戶提供的功能纠吴。
功能性需求通常使用三個互補但部分重疊的視圖進行文檔化：數(shù)據(jù)視圖硬鞍、功能視圖和行為視圖。
- 質(zhì)量需求
質(zhì)量需求定義了一個系統(tǒng)或組件戴已、服務或功能的質(zhì)量特性固该。
（1）類型
用戶關心：
可用性
效率
靈活性
完整性
互操作性
可靠性
健壯性
易用性
開發(fā)者關心：
可維護性
可移植性
可復用性
可測試性
（2）非功能性需求
非功能性需求很多時候在描述不明確的功能性需求，或者一個質(zhì)量需求糖儡。
非功能性需求經(jīng)常掩蓋不明確的功能性需求伐坏，并導致了對所期望的系統(tǒng)屬性做不明確的解讀。
- 約束
約束是一種限制了系統(tǒng)開發(fā)方式的組織或技術要求握联。
影響系統(tǒng)的約束：
C1：市消防部門要求門市部終端的尺寸不能超過120cm（長）×90cm（寬）× 20cm（深）桦沉。
影響開發(fā)過程的約束：
C2：系統(tǒng)必須使用Rational 統(tǒng)一進行開發(fā)。
三金闽、問題和解決方案
整體的系統(tǒng)設想→做什么纯露？
詳細的需求過程→怎么做？
雙高峰模型：說明了需求定義和體系結構設計之間的雙向交互作用代芜。
需求工程和體系結構設計之間的交互作用
雙高峰模型將需求求工程和體系結構設計之間的交互關系描述為需求和體系結構的螺旋過程埠褪，并伴隨著粗粒度制品逐漸轉化為更細粒度的制品。
高抽象層次上的需求制品被用來定義初始的系統(tǒng)體系結構挤庇。體系結構設計決策引發(fā)對初始的粗粒度需求的修改和精化钞速。這又一次導致了對系統(tǒng)體系結構的修改和精化。
結論：大部分需求在描述的時候都伴隨著腦海中考慮的解決方案嫡秕。
第三章 持續(xù)的需求工程
一渴语、系統(tǒng)分析
系統(tǒng)分析：對一個現(xiàn)有系統(tǒng)或者過程進行分析的基礎上定義一個新系統(tǒng)需求的各種不同的方法。
傳統(tǒng)系統(tǒng)分析：功能昆咽、數(shù)據(jù)驾凶、行為來定義屠升。這三種試圖互補且互相重疊。
分析方法：結構化分析方法（structured analysis,SA）狭郑、本質(zhì)系統(tǒng)分析（Essential Systems Analysis）腹暖、現(xiàn)代結構化分析（Modern Structured Analysis）
- 結構化分析方法
結構化分析使用數(shù)據(jù)流圖來描述系統(tǒng)功能以及每個功能的輸入和輸出數(shù)據(jù)流。
當前狀態(tài)分析：記錄+文檔化
期望狀態(tài)定義：指出潛在改進翰萨。
- 本質(zhì)系統(tǒng)分析
本質(zhì)（essence）：
系統(tǒng)的本質(zhì)
真實需求是系統(tǒng)必須擁有以滿足其目標的一種特征或能力脏答，無論系統(tǒng)如何實現(xiàn)。我們將一個系統(tǒng)真實需求的完整集合稱為系統(tǒng)本質(zhì)或本質(zhì)需求亩鬼。
實現(xiàn)系統(tǒng)的技術由兩種部件類型組成：
執(zhí)行活動的處理器
存儲并為處理器提供數(shù)據(jù)的容器
系統(tǒng)對應物（Incarnation of a system）：
所有用來實現(xiàn)系統(tǒng)的本質(zhì)活動和存儲器的事物的總和就是系統(tǒng)對應物.
本質(zhì)模型的優(yōu)勢：
更穩(wěn)定
更小
無設計限制
現(xiàn)有系統(tǒng)和新系統(tǒng)沒有明顯的不同
對系統(tǒng)本質(zhì)和對應物的區(qū)分的基本原則獨立于系統(tǒng)開發(fā)所使用的過程或方法殖告，因此可以應用于一般的開發(fā)過程和方法。例如：
V模型
V-Model XT
敏捷方法
Rational統(tǒng)一過程
二雳锋、需求工程的持續(xù)性
兩種持續(xù)的需求工程的質(zhì)量層次：
需求工程作為跨生存周期的活動
需求工程作為跨項目和跨產(chǎn)品的活動
第四章 需求工程框架
一黄绩、目標：在上下文中建立愿景
期望（vision）：精確地定義所期望的改變的本質(zhì)
清晰可定義的目標
二、框架
組成：
-
系統(tǒng)上下文
主體刻面
使用刻面
IT系統(tǒng)可免
開發(fā)刻面
-
三個核心需求工程活動
抽取
文檔化
協(xié)商
-
兩項橫切活動
確認活動
管理活動
-
需求制品
目標
場景
面向方案的需求
三玷过、四個上下文刻面
- 定義
主體刻面：包含了系統(tǒng)上下文中與系統(tǒng)相關的對象與事件爽丹。
換言之，與這些主體刻面中的對象和時間相關的信息必須在系統(tǒng)中加以表示辛蚊。
例子：測量車速的軟件衡量抽象對象“速度”
主體刻面包含了一些影響系統(tǒng)中對象和時間相關信息表示的方面粤蝎，力圖禁止或限制軟件密集型系統(tǒng)對某類數(shù)據(jù)進行記錄的法規(guī)，限制所記錄數(shù)據(jù)精確性或數(shù)據(jù)更新頻率的法規(guī)袋马。
使用刻面：一個軟件密集型系統(tǒng)由人或其他系統(tǒng)使用從而達成一個目標或完成某項具體任務初澎。包含了與人或其他系統(tǒng)對本系統(tǒng)的使用相關的所有方面。
例如：已存在的各種使用目標虑凛、期待的工作流碑宴、具有各種特性的不同用戶組、具有不同接口的各種交互模型桑谍，以及限制或影響系統(tǒng)使用的法規(guī)和標準延柠。
IT系統(tǒng)刻面：待開發(fā)的系統(tǒng)最終要被部署在現(xiàn)有IT基礎設施上。IT系統(tǒng)可免由運行與技術環(huán)境的所有方面構成霉囚，包括那些定義了如何使用各種技術與運行環(huán)境的約束或指南的仿真和策略捕仔。
例如匕积，通信協(xié)議盈罐，軟件平臺預定義的一組操作系統(tǒng)。
開發(fā)刻面：包含了與系統(tǒng)開發(fā)過程相關的上下文方面闪唆，包括過程準則與約束盅粪、開發(fā)工具、質(zhì)量保障方法悄蕾、成熟度模型票顾、質(zhì)量認證础浮，以及其他確保軟件密集型系統(tǒng)質(zhì)量（如安全性、保密性）的數(shù)段或技術奠骄。
例如：某項標準可能要求特定的測試準則豆同。
- 邏輯關系
軟件密集型系統(tǒng)需要現(xiàn)世界中對象（主體刻面）表示，系統(tǒng)使用現(xiàn)有的技術（IT系統(tǒng)刻面中）實現(xiàn)其數(shù)字化表示含鳞。
系統(tǒng)根據(jù)定義的功能處理所表示的信息影锈，通過某種接口將處理后結果展現(xiàn)給用戶體現(xiàn)了IT系統(tǒng)刻面的和使用刻面的關系。
系統(tǒng)用戶將對系統(tǒng)輸出進行解讀蝉绷，并將其與主體刻面中的現(xiàn)實世界對象聯(lián)系起來鸭廷。
開發(fā)刻面和其他三個刻面都存在關系。
四熔吗、三個核心活動
- 需求工程的三個維度
內(nèi)容維度：被用來理解所獲取的系統(tǒng)需求辆床。
共識維度：與相關涉眾就已知需求理解取得共識的程度相關。
-
文檔化維度：采用各種文檔化/規(guī)格說明格式對系統(tǒng)需求進行文檔化和規(guī)約描述桅狠。
筆記梗概讼载、即時陳述、手工繪圖→建模語言和模板
需求工程的目標：
需求工程是一個協(xié)作式的中跌、不斷迭代以及增量的過程维雇，旨在確保：
（1）所有相關的需求都在所需要的細節(jié)層次上得到了清晰的了解和理解。
（2）在相關涉眾見建立起對于系統(tǒng)需求的充分認識晒他。
（3）所有需求都依照文檔化/規(guī)格說明格式進行了文檔化和規(guī)約描述吱型。
- 核心活動
文檔化：依照文檔化/規(guī)格說明格式進行了文檔化和規(guī)約描述
幾類規(guī)范：
總體文檔規(guī)范：用于記錄所有信息，例如訪談陨仅、會議安排津滞、關于系統(tǒng)上下文的決策、原理信息
文檔規(guī)范：適用于需求工程過程的各個階段所定義的每一項需求灼伤，保證需求文檔質(zhì)量触徐。一般用于協(xié)商或者驗證。
規(guī)約規(guī)范：適用于軟件規(guī)格說明中所包含的所有需求狐赡。旨在保證需求規(guī)約描述的質(zhì)量撞鹉。
抽取：改進對需求的理解颖侄，在內(nèi)容維度上取得進展鸟雏。
協(xié)商：滿足不同涉眾的要求和期望。
五览祖、兩個橫切活動
- 確認
需求制品的確認：發(fā)現(xiàn)需求的缺陷孝鹊。
核心活動的確認：目的是檢查活動的執(zhí)行符合過程規(guī)約或者活動規(guī)約。
系統(tǒng)上下文考慮因素的確認：確認需求工程是否按照期望的方式對系統(tǒng)上下文進行了考慮展蒂。
- 管理
-
需求制品的管理
確定需求優(yōu)先級
需求的持久化保存
需求的配置管理
需求的變更管理
活動的管理：包含對需求工程活動的規(guī)劃和控制又活。
系統(tǒng)上下文的觀察：識別上下文變更苔咪。
- 五個活動之間的關系
互相影響：比如
附加需求的抽取
遺漏需求的發(fā)現(xiàn)
規(guī)格說明中需求的移除
六、三種需求制品
需求制品：被文檔化的需求柳骄。
- 目標
定義：關于系統(tǒng)的目的团赏、屬性或者使用的意圖。
含有指示性耐薯，表達了對于系統(tǒng)的期望和要求馆里。
G1：系統(tǒng)應該自動引導駕駛員到達指定地點。
G2：響應時間比先前系統(tǒng)至少降低20%可柿。
目標刻畫涉眾的意圖鸠踪，對系統(tǒng)愿景精化為系統(tǒng)將實現(xiàn)的目的。
目標和解決方案無關复斥。
- 場景
定義：場景描述了一個目標（或一組目標）被滿足或者未被滿足的具體實例营密。它提供一個或多個目標的具體細節(jié)。一個場景通常定義了一系列為滿足目標而執(zhí)行的交互步驟目锭，并將這些交互步驟和系統(tǒng)上下文聯(lián)系起來评汰。
自動剎車操作 場景
Carl正駕駛汽車以毎小時50英里的速度在高速公路上行駛。Peter駕駛另一輛車在Carl前方 行駛痢虹，Peter開始剎車減速被去，當Carl發(fā)現(xiàn)Peter在減速后，Carl也踩下了剎車踏扳奖唯。此時Carl的車 載系統(tǒng)檢測到與前方車輛的距離已不在安全距離內(nèi)惨缆，因此向駕駛員發(fā)出警告。接著丰捷，兩輛車的距 離繼續(xù)拉近坯墨。此時，為了幫助駕駛員病往，車載系統(tǒng)會啟動自動全剎車捣染，并通知Carl開啟了自動全 剎車。當兩輛車之間的距離停止減少后停巷，系統(tǒng)會中止全剎車動作耍攘。但是，系統(tǒng)會繼續(xù)控制Carl 車輛的速度畔勤，直到與前車之間的距離拉大到安全距離蕾各，然后終止此次動作并通知Carl。
- 面向方案的需求
定義了數(shù)據(jù)流圖硼被、功能視圖和行為視圖示损，此外還包括質(zhì)量需求以及約束。
