2. 使用使用者故事表達「願求」
3. 使用場景確認使用者故事
用例與使用者故事
描述「是什麼」，即需要解決的問題，組成需求說明的核心內容。需求說明定義了軟體產品需要做什麼，但不是「如何做」。很顯然，需求說明的內容遠不止「是什麼」，還會包含「是誰」， 闡明了針對哪些干係人和「為什麼」，將需求範圍的界定合理化。然而，目標仍然是為了詳細說明「是什麼」，以及任何應該支援最終目標的問題的答案。
干係人是指與軟體利益攸關，又不能直接參與軟體的構建過程的任何個人或群體。
在簡單世界中，只會有乙個干係人，他就是軟體專案的發起人。在真實世界裡很少發生這種情況，一般情況下，會有若干個干係人，他們的需求常常彼此衝突。這就是讓所有干係人都參與的原因，也是必須分辨出各個干係人所代表的角色對軟體功能影響的原因。
通過收集、合併干係人的「願求」，將關注點從解決方案的屬性轉移到干係人的「願求」上來，產生更多有價值的對話。也就是專注於需要什麼，而不是如何實現它。
用幾個詞語描述軟體產品需要實現的願景。這個簡短的、一行字的概況應該給所有人提供了關於乙個軟體產品最終必須是什麼樣子的共同的理解。乙個清楚的願景為整個開發周期提供了決策和承擔責任的依據。
為了建立乙個明確的一行字摘要，可以遵循高斯和溫伯格推廣的啟發式命名規範。
「首先提議乙個名字，接下來提供這個名字不十分恰當的三個原因，然後提議用另乙個名字來解決這些問題。」重複這三個步驟，直到找到乙個有用的描述。
乙個有意義的共同目標的概述，它清晰地從干係人的視角闡明了為什麼產品、功能有存在的必要。
雖然開發團隊知道如何構建軟體，但很少有人對軟體領域懂得很多，更少的人甚至不知道他們「為什麼」要做以及要做什麼。「為什麼」意味著驅動他們行動的動機，共同目標證明了軟體存在的必要。「為什麼」會幫組開發團隊理解干係人的動機，是軟體的共同目標清晰明了。
乙個使用者故事是用一段簡短的、表達一部分可演示的功能的日常用語來描述的。乙個使用者故事不應該有難懂的技術術語，它需要能夠被程式設計師和干係人都理解。在描述願望是，它更多的是在描述如何被使用，而不是看起來什麼樣子，或者將如何被實現。
乙個經典的格式描述：作為《使用者》，我想要《願望》，這樣我就可以《收益》。
一種角色必須有唯一的名字將它與其他使用者故事區別開。把任何能幫助將一種角色與其他角色區分出來的有用資訊都寫下來。
角色模型的目的是為了挖掘可能丟失的使用者故事，通過角色給使用者故事排序，每個干係人的願望都被強調了。
與之類似的，另一種挖掘可能丟失的使用者故事的技術是把重點放在語氣收益上。這種技術使用不同的模板來寫使用者故事，將《利益》朝前挪，以示強調。
為了《收益》，作為乙個《使用者》，我想要《願望》。
沒有直觀地描述使用者體驗，很難捕捉到需求的要點。從使用者使用介面的角度來說明需求，能夠幫組我們將無法描述的假設轉換成明確地資訊。每乙個使用者故事都可以使用故事板來加強理解。
最簡單的故事板製作技術是紙原型法，可以是建立草圖，甚至是隨手塗鴉，畫出使用者介面的一次性原型。原型模擬了所有的互動。使用這個原型同干係人溝通時，可以快速得到他們的反饋，知道哪些是有效的，哪些是無效的。
收集完關於使用者介面的想法後，需要將紙原型轉換為低保真的電腦版故事板。這個故事板可以被當成是使用者故事的視覺化**，由團隊分享。
不要使用軟體工具試圖使使用者介面跟最終產品一致，因為高保真工具要求對細節進行精密的、詳細的說明，這是很花時間的，也不是在收集需求階段的要求。
推薦軟體：
乙個場景是一種轉換演示，並從干係人的角度展示了因果關係。場景包含先決條件、乙個行動和結果。先決條件是軟體採取行動之前的當前狀態；行動是指完成場景所描述的行為的事務；結果是指行動的後果。
乙個場景無非是引起狀態裝換的行動。所有說明使用者故事的場景合起來構成常規的狀態機。詳細說明乙個問題的最大好處之一就是作為乙個有限狀態機，你可以完善問題的邏輯，也就是說，如果你能列舉狀態的先決條件和結果，以及行動，那麼描述出乙個使用者故事就是很簡單地為每個節點建立場景。
要注意，乙個場景應該只有乙個行動。觸發單個的行動對於保證狀態轉換的簡單些是至關重要的。乙個場景可以使用多個先決條件並且有多個結果。
有兩種指令碼技術，可以用來表達場景，同時也提供了建立自動化驗證的基礎。一種是被稱為繼承測試框架 (fit: framework of integrated test)的技術，另一種是被稱為行為驅動開發(bdd)的已知——當……時——那麼的句型結構。
使用**編寫場景是一種簡單有效的技術，這種技術的核心是fit**。這種**利用縱列從左到右直觀地表達了你能夠在乙個場景裡找到的先決條件和結果。
行動: buymonthlypass
消費者車票
**學生
月票￥76
老人月票
￥87標準
月票￥126
先決條件 結果
這個實踐的核心是，已知——當……時——那麼的句型結構，使用gherkin語法，組織干係人的期望行為的描述。它限定每個場景只能有一次轉換。
已知——當……時——那麼的句型結構表達如下：
已知 乙個先決條件
和 另乙個先決條件
當 乙個行為發生時
那麼 會有乙個結果和另乙個結果
已知——當……時——那麼句型比fit**更詳細。
用例和使用者故事是相似的，因為它們都是組織需求的方式。它們的不同之處在於它們的組織目的不同。
用例組織需求，形成使用者如何與系統相關和使用系統的敘述。因此，他們關注使用者目標以及與系統的互動如何滿足這些目標。
使用者故事（和類似的東西，通常被稱為特性）為了計畫的目的把需求分成塊。故事被明確地分解，直到它們可以作為發布計畫過程的一部分被估計為止。因為這些需求的使用是不同的，所以對於好的用例和使用者故事的啟發式方法將有所不同。
兩者之間有著複雜的關聯故事通常更細粒度，因為它們必須在乙個迭代中完全可構建。乙個小的用例可能完全對應於乙個故事；但是乙個故事可能是乙個用例中的乙個或多個場景，或者是乙個用例中的乙個或多個步驟。乙個故事甚至可能不會出現在用例描述中，比如在彈出列表中新增乙個新的資產折舊方法。
需求分析說明書
第一章 引言.1 1.1 編寫目的.1 1.2 專案背景.1 1.3 基本定義.1 第二章 產品概述.2 2.1 系統功能.2 2.2 執行環境.2 2.3 使用者的特點.2 2.3 條件與限制.2 第三章 功能需求.3 3.1 功能劃分.3 3.2 功能描述.3 4.3 軟體介面.4 4.4 故障...
需求分析說明書
iso軟體工程模板 4 需求說明書 1 引言 1.1編寫的目的 說明編寫這份需求說明書的目的,指出預期的讀者.1.2背景 a.待開發的系統的名稱 b.本專案的任務提出者 開發者 使用者 c.該系統同其他系統或其他機構的基本的相互來往關係。1.3定義 列出本檔案中用到的專門術語的定義和外文首字母組詞的...
需求分析階段 需求說明書
專案名稱 需求說明書 v1.0 版本號 擬 制 人 審 核 人 批 準 人 年月日 需求說明書 1 引言 1.1編寫的目的 說明編寫這份需求說明書的目的,指出預期的讀者.1.2背景 a.待開發的系統的名稱 b.本專案的任務提出者 開發者 使用者 c.該系統同其他系統或其他機構的基本的相互來往關係。1...