問題定義模板 元素
說明問題id
問題分類標識
問題描述存在的問題
影響該問題影響的部門或個體
結果影響的情況
解決方案
建議方案及優點
魚骨圖(定性分析):選擇問題→頭腦風暴→確定問題的型別→分配原因;
帕累託分析(定量分析):利用魚骨圖的結果和相關原因，確定並集中於主要的問題領域(因與果);
干係人/涉眾(stakeholder):
使用者:直接使用系統的人,實際上也屬於涉眾;
1.4.1環境描述
顧客需要買東西時會打**(或其他方式)給公司銷售人員,公司銷售人員根據**商的**資料向顧客**,並根據當前庫存情況確定能否響應使用者訂單;如果顧客接受該**,並且有足夠的庫存,銷售人員會認為使用者的訂單是有效訂單；1.4.2採用3號邊界信用人員將顧客的歷史交易資料以及信用卡的情況決定接受該訂單是否是安全的,然後就結果返回給銷售人員；
如果審核結果表明訂單是安全的,銷售人員將會記錄訂單;
進行下一步工作.
這時系統僅實現訂單記錄，意味著使用者必須手動完成接受訂單的工作，信用檢查的功能也不在本系統中實現，系統只起到一種電子化的工作。1.4.3採用2號邊界問題是：我要是使用者，付給你的錢可以很少。
系統不僅實現訂 單記錄，還會將該顧客的歷史交易記錄、提供信用卡檢查。1.4.4採用1號邊界
系統還將實現訂單接受的自動化，可能的解決方案是建立乙個呼叫中心，或者通過web服務**。邊界的選擇和使用者的投入(資金),進度,需求有關。開發商往往不能起決定性的作用。由使用者來確定比較好。但作為開發商重要的是能夠將不同的邊界說清楚。
實際操作中,無論是大型專案還是中小型專案,選擇哪個邊界不重要,重要的是邊界都在**.不同的邊界要做什麼事情需要清楚。
上下文圖
PMP 2 軟體需求與框架
1.1 軟體 程式 指令序列 資料 程式能正常操縱資訊的資料結構 文件 與程式開發維護和使用有關的 資料 1.2需求 以一種清晰 簡潔 一致且無二義性的方式對乙個待開發系統中各個有意義陳述方面的乙個集合。1.3需求分析 what to do,do what?1.4需求錯誤的高昂代價 2.1需求的三個...
專案需求 筆記3
團隊 組成 專案團隊 組 員的多少和比例要根據實際專案來決定。一般專案團隊 控制在5 7人。組建專案團隊 時首先需要定崗，就是確定專案需要完成什麼目標，完成這些目標需要哪些職能崗位，然後選擇合適人員組成。專案開發可能涉及到的職能崗位有很多，我們將在後面章節詳細介紹。這裡先提供乙個普通 專案常見職能和...
需求分析 3 實際應用
需求分析主線中所包含的關鍵步驟，可以概括為 三橫兩縱 兩縱 所謂 縱 指的是實踐中需要持續不斷地進行。所謂 橫 則是有先後之分的。1 第1步 明確系統目標 產品的 根 是系統的業務目標，我們要把業務目標寫入 願景文件 成為 願景文件 的關鍵部分。2 第2步 範圍 feature 上下文圖 在確定業務...