1.軟體需求定義
需求是指系統必須實現什麼的規格說明。它描述了系統的行為、特性或屬性，是在開發過程中對系統的約束
2.需求工程的本質
需求工程可以看作把乙個定義不足的問題轉換為乙個定義充分的問題以便找出解決方案
3.問題域與解系統
問題域:被開發系統的應用領域
解系統:指可以在問題域內產生某種效果的系統
4.軟體需求分類
功能需求
效能需求 (非功能需求)
設計約束
商業約束
5.客戶/使用者/開發者的需求觀
6.不合格的需求派生的問題
1. 無足夠使用者參與
2. 使用者需求的不斷增加
3. 模稜兩可的需求說明
4. 不必要的特性
5. 過分精簡的規格說明
6. 忽略使用者分類
7. 不準確的計畫
7.高質量的需求帶來的好處
8.優秀需求所具有的特徵
8. 完整性(***plete)
9. 正確性(correct)
10. 可行性(feasible)
11. 必要性(necessary)
12. 與實現無關性(implementation independent)
13. 劃分優先順序 (prioritized, future and trade-offs)
14. 無二義性(unique)
15. 可驗證性(verifiable)
16. 正確的詳細層次(right level of details)
2. 需求規格說明的特徵
1. 完整性(***plete)
2. 一致性(consistent)
3. 簡潔明瞭(concise)
4. 可修改性(modifiable)
5. 可跟蹤性(traceable)
軟體需求工程定義
需求獲取
– 應當收集什麼資訊
問題域的描述
要求解決的問題列表(需求)
使用者對解系統的行為或結構施加的任何約束
– 有哪些資訊**
高層系統需求 system requirements
客戶(實際的和潛在的) customers
客戶的「規格說明書」 crs
原有解系統(即執行在問題域中，執行與預期的新的解系統相似功能的系統)及其文件
原有系統的使用者
競爭對手的產品
應用領域專家
定義了任何介面系統的特徵和行為的文件
相關的技術標準和法規
– 可能通過什麼機制或技術收集
面談 準備
詢問正確的問題
直接問題
原始的和派生的問題
總結性問題
集中精力傾聽
重複關鍵問題
記錄收集的資訊
調查表用例或場景分析
對客戶進行分類
業務需求
使用例項
功能需求
質量屬性
外部介面
限制 資料定義
解決思路
頭腦風暴
需求剪裁
– 確定需求開發過程
– 編寫專案檢視和範圍文件
業務需求
背景 業務機遇
業務目標
客戶需求
業務風險
專案視**決方案
範圍和侷限性
業務環境
產品成功的因素
基於專案檢視和範圍的管理
將使用者群分類並歸納各自特點
選擇每類使用者的產品代表
建立起典型使用者的核心隊伍
讓使用者代表確定使用者使用例項
召開應用程式開發聯絡會議(jad)
分析使用者工作流程
確定質量屬性和其它非功能需求
通過檢查當前系統的問題報告來進一步完善需求
跨專案重用需求
需求分析
– 繪製系統關聯圖
– 建立使用者介面原型
– 分析需求可行性
– 確定需求優先級別
– 為需求建立模型
– 建立資料字典
– 使用質量功能部署
– 結構化分析工具
dfd資料流圖、dd資料字典和pspec
cfd、cspec和std
e-r圖
– 物件導向分析工具
用例圖，類圖，物件圖
物件-關係圖
物件-行為圖
– 建模工具
資料流圖
實體關係圖
狀態轉換圖
對話圖類圖 petri ***
– 需求規格書
– 採用srs模板
– 指明需求的**
– 為專案需求注上標號
– 記錄業務規範
– 建立需求跟蹤能力矩陣
需求驗證
– 審查需求文件
– 以需求為依據編寫測試用例
– 編寫使用者手冊
– 確定合格的標準
確定需求變更控制過程
建立變更控制委員會
進行需求變更影響分析
跟蹤所有受需求變更影響的工作產品
建立需求基準版本和需求控制版本文件
維護需求變更的歷史記錄
跟蹤每項需求的狀態
衡量需求穩定性
使用需求管理工具
客戶的需求觀
需求知識技能獲取
– 培訓需求分析人員
熟練的需求分析員應具備以下特點：
耐心 思維條理性強
有良好的交際和溝通能力
理解產品應用領域
掌握豐富的需求工程技術
– 培訓軟體需求的使用者代表和管理人員
明白重視需求的意義
需求工作包括哪些活動
要提交什麼樣的結果
忽略需求過程會導致的風險
更加體諒軟體開發人員
– – 讓開發人員了解問題域(應用領域)的基本概念
– 編寫專案術語彙編
cmmi需求工程過程模型
需求分析的六個原則
（一）永遠不要顯得比客戶更聰明
總結一下需求分析第乙個原則的中心思想：
1、需求分析第乙個原則：永遠不要顯得比客戶更聰明。
聰明反被聰明誤，這樣的事情太多了，我們產品經理都是有智慧型的人，而不是耍小聰明的人。
2、原則第一點：了解需求，而不是去批評客戶。
產品經理不是批評家，心理上要重視客戶，行動上要尊重客戶，平等對待每乙個客戶。
3、原則第二點：客戶比你更熟悉業務的環境。
產品經理熟悉的僅僅是產品本身，但是，產品經理要做的卻不僅僅是產品本身。
4、原則第三點：真正的問題只有客戶知道，我們要做的就是讓客戶願意說出來。
客戶會給你反饋，但是這些反饋有些是真實的，有些是敷衍的，你希望真實還是敷衍，請參考原則第一點。
需求分析的六個原則（二）尊重使用者的現實選擇
總結一下需求分析第二個原則的中心思想：
1、需求分析第二個原則：尊重使用者的現實選擇。
產品是客觀的，使用者是客觀的，使用是客觀的，需求也是客觀的，一切都是現實的。
2、原則第一點：客戶永遠是對的。
客戶不是我們的敵人，客戶不會害我們，客戶提出的需求看似在為難我們，但本質上是為了讓客戶自己更好的使用產品，因此，客戶不會為難自己。
3、原則第二點：提供最合適的解決方案，而非最好或最貴的方案。
我們能夠做的不一定是最好的，我們不想做的有時候往往是客戶最需要的，找到最合適客戶的，而不是最合適我們的。
4、原則第三點：不要把客戶當傻瓜。
這個世界上沒有傻瓜，自以為對方是傻瓜的人才真的是傻瓜，不要忽悠客戶，不要欺騙客戶，如果非要在這個前面加上乙個期限的話，我希望是「永遠」。
需求分析的六個原則（三）轉述需求的人也是客戶
總結一下需求分析第三個原則的中心思想：
1、需求分析第三個原則：第三方也是我們的客戶。
只要是對我們的產品和業務提出需求，就是我們的客戶，應該一視同仁。
2、原則第一點：第三方一般會把自己想象成設計者。
他們對產品或許很熟悉，但是對整個業務可能不熟悉，因此，他們成不了設計者。
3、原則第二點：第三方可能會遺漏或補充一些額外的需求。
每個人都期望產品能做好，這種強烈的成功心理容易讓人們產生日暈心理，從而影響我們對需求的篩選。
4、原則第三點：對第三方的自由發揮不應抱怨和生氣，而是將其視為客戶。
客戶是第一位的，而他們又是我們的客戶，因此，我們應該心平氣和的對待他們的想法，無論這些想法是出於公還是出於私的。
需求分析的六個原則（四）客戶和使用者要區別對待
總結一下需求分析第四個原則的中心思想：
1、需求分析第四個原則：客戶和使用者要區別對待。
客戶是客戶，使用者是使用者，有時候一致，有時候分離，這是我們首先要搞清楚的。
2、原則第一點：產品為終端使用者設計，需求的功能轉換為終端使用者的使用要求而確定。
使用者決定產品，我們需求工作基於使用者，始於使用者，歸於使用者。
3、原則第二點：為客戶尋找價值上的需求。
客戶是多樣的，價值導向也是多樣的，我們的產品能否承載多樣化的客戶價值決定了產品能否實現最終的交換。
4、原則第三點：使用者的利益高於一切。
產品的最終價值是通過使用者來體現的，脫離了使用者的產品，就是「皮之不存，毛將焉附」。
需求分析的六個原則（五）用最簡單的文字工具記錄需求
總結一下需求分析第五個原則的中心思想：
1、需求分析第五個原則：用最簡單的文字工具記錄需求。
客戶並不麻煩，需求也不複雜，麻煩的是我們把一切做的太複雜了。
2、原則第一點：所有人都能懂的東西，最不容易出錯。
沒有人喜歡複雜的東西，需求也不例外。
3、原則第二點：不需要再學習的東西，最不容易出錯。
產品是需求的表現，沒有人喜歡複雜的產品，要做到這一點，就從需求開始吧。
4、原則第三點：不要希望客戶能花更多的時間來了解需求轉換後的原型。
我費些事，客戶就可以省些事，客戶省事了，我們最終也就省事了。
5、原則第四點：保持溝通的通暢，是了解需求的保障
要實現需求的清清楚楚，就要做到溝通的反反覆覆。
需求分析的六個原則（六）天下沒有免費的午餐
總結一下需求分析第六個原則的中心思想：
1、需求分析第六個原則：天下沒有免費的午餐。
要得到就一定要付出，付出的量並不一定和得到的量相等，作為產品經理來說，就是要讓客戶盡量少的付出，盡量多的得到，但永遠不會是免費的。
2、原則第一點：客戶從來沒有不合理的需求。
客戶的需求都是現實的，都是合理的，因為這些需求都是客觀的，但我們通常習慣於用主觀去看待客觀。
3、原則第二點：客戶的要求都是可以實現的。
沒有不可以實現的需求，只有我們了解的不夠深入的需求。
4、原則第三點：我們能做這事－這是所需的費用。
成本第一還是需求第一，客戶把這個問題交給了我們，我們就用用我們的智慧型去解決這個問題。
員工需求分析
員工需求之一 基本薪資和收入成長空間 基本薪資是員工普遍關注的需求。通過基本工資可以反映出以下問題 崗位高低及重要程度 一般企業在設定基本薪資的時候都會考慮職位 技術難度和崗位的重要程度等，因此基本薪資能夠反映崗位高低和重要程度，通過基本薪酬的區別員工可以找到自己的定位，同時也能通過這一點感受企業對...
需求分析報告
1.2.目錄需求分析的目的5 專案簡介5 1 2 3 4 專案商業目標5 專案所開發的系統的定義和用途5 專案的成本計畫5 開發期限5 3.專案可交付資料5 1 2 3 專案結束時客戶應接收到的資料5 專案結束時客戶不應接收到的資料5 滿足可交付資料所必需的產品6 4.系統使用者分析6 1 2 3 ...
需求分析報告
文件編號 no.001 版本號 1.0 文件名稱 需求規格說明書 專案名稱 c語言貪吃蛇 專案負責人 王阿海 編寫 王阿海 校對 車進輝 審核 車進輝 批准 車進輝 開發單位 北華大學計算機學院軟體工程 12 1 通過與多位軟體使用者進行全面深入地 和分析，並完成 貪吃蛇遊戲 市場的前期調查後，提出...