敏捷開發框架下的軟體工程/第二次迭代/功能需求
要點：功能需求進一步定義 時間：2 小時
輸入：來自客戶討論的筆記、研究筆記、ERD。過程證據：功能需求草案列表。客戶：討論 
在第一次迭代中，我們使用計劃遊戲識別了一些系統的高階需求。這些需求隨後被用來定義系統的範圍（隱喻），進行道德分析，並作為首次釋出的基礎。它們為與客戶和開發團隊討論專案提供了一個溝通工具。
敏捷運動對需求的處理方法是雙重的：1. 需求總是會發生變化 2. 在專案開始時不可能定義所有需求
重要的是要理解，需求不是一個神奇的、定義好的實體。沒有人知道所有的需求是什麼。每個使用者都會有自己的觀點，所有觀點都可能是正確的。我們將需求確定階段描述為“探險”。Cohn（2005）擴充套件了這個隱喻，解釋說“不同的網可以捕獲不同大小的需求”（第 43 頁）。我們的初始計劃遊戲是第一遍，捕獲了最大和最明顯的需求。在這次迭代中，我們將使用更小的網眼尺寸，以“捕獲”更小的需求。
此外，Cohn 解釋說“需求就像魚一樣，會成熟，也有可能死亡”（第 43 頁）。在第一次迭代中定義的需求可能會變得多餘，因為其他需求被定義，或者似乎是次要需求的可能成為專案的重要組成部分。（這些是最初為“如果系統也能……，那該多好啊？”的對話中出現的需求。）
最後，在關於捕魚的主題中，雖然你在拖網探險中不會捕獲所有需求，你可能會撈上來一些無關的藻類或螃蟹，但熟練的需求拖網者會使用最佳技術來使探險變得高效。
需求規格說明書傳統的軟體開發方法使用需求規格說明書來定義專案的範圍。這種方法假設我們可以“第一次就獲得正確、完整、簡潔和清晰的需求”。http://satc.gsfc.nasa.gov/support/STC_APR98/do_reqmnt/do_reqmnt.pdf
許多大型開發組織釋出了需求標準，供應商需要在投標時遵守這些標準。看看 NASA 網站，你會發現這些標準的絕佳來源。需求規格說明書可以非常龐大，並將需求定義到最小的細節。這項需求分析工作可能需要花費幾個月甚至幾年時間。
例如，用於火星著陸器的 ASPERA-3 處理和歸檔設施的需求規格說明中包含以下需求：“應向所有 ASPERA-3 合作者提供 ASPERA-3 和 MEX OA IDFS 資料以及任何 APAF 生成的 ASPERA-3 和 MEX OA 清理後的遙測中間檔案。”（摘自 www.aspera-3.org/idfs/APAF_SRS_V1.0.pdf）
這些檔案是結構化方法（通常是瀑布模型）的結果。它們是試圖在專案失敗率居高不下的情況下，為軟體開發過程帶來一定確定性的合理嘗試。它們還為開發提供了法律和合同基礎。這種方法的財務合理性源於一種觀點，即專案中的變更是一件壞事，而且一旦我們能夠就“正確”的需求達成一致，就可以繼續進行設計和構建階段。
變更成本曲線在敏捷論壇中，變更成本曲線備受爭議。傳統觀點（這裡我們談論的是瀑布模型中產品的單個釋出）認為，在開發週期的早期階段發生的變更需求的實現成本很低，因為專案投入很少。在設計階段更改需求將涉及重新分析和設計，成本也會更高。一旦開始程式設計，成本就會開始上升，組織可能會抵制修復損壞所需的工作。（“沒關係，我們可以在下一個版本中新增該功能”。）產品釋出後，更改的實現成本高得令人望而卻步，涉及新版本軟體、更新的使用者文件以及對開發者聲譽的損害。
敏捷版本建議，可以解決這種變更成本問題。透過確保縮短反饋迴圈，並在實現每個需求（使用者故事）之前對其進行測試和驗證，可以獲得更平坦的敏捷曲線。任何增量或迭代方法都將改善變更曲線，因為它們可以防止對有缺陷的程式碼進行投資。
需求的規則第一條：需求會發生變化。為了遵循極限程式設計的敏捷原則，我們需要擁抱變化，並與利益相關者溝通，以確保我們對需求的理解足以滿足開發過程的要求。Boehm 和 Turner（2004）指出，“成功的、可持續的軟體開發既需要紀律，也需要敏捷”（第 23 頁）。眾所周知，敏捷方法最適合客戶易於訪問、需求可能會發生變化的較小專案。雖然對於大多數專案來說，200 頁的需求文件的開銷並不是必需的，但記錄需求對於確保與客戶就清晰理解達成一致還是很有幫助的，尤其是在較大或任務關鍵型專案中。編寫良好的需求是一項有用的技能，可以提高開發團隊對專案的理解。
“敏捷者會建立高價值文件”（Ambler，2006）。我們將使用計劃遊戲來引出更深入、更詳細的需求。在第二次迭代中，我們需要了解使用者的觀點——使用者需要系統執行哪些操作？我們將製作一份需求文件草案，該草案將成為您在第二次迭代中進行開發的基礎。有勇氣在您對專案的理解發生變化時更改您的需求。在開發過程中的任何時間都可以新增、刪除或編輯需求。（您需要為這些決定提供理由！）編寫良好的需求。
常見問題語言在所有需求中，對同一個專案使用相同的術語。每個需求通常可以寫成以下格式：系統應提供 ........ 系統應能夠 ........（使用“應”來描述需求，“將”來描述事實陳述，“應該”來描述目標是行業慣例。）
需求的語言很重要。如果您發現自己使用“是”、“為”、“曾”，那麼您可能是在描述系統而不是它的功能。例如，“系統正在儲存學生資料”。更可取的是“系統應儲存學生資料”。
避免使用不必要的詞語，如“必須”、“支援”（如“系統將支援備份”）、“但不限於”、“等等”、“和/或”以及列表。這些詞語難以定義，會導致不確定性，併為多種解釋留下了空間。如果需求不可定義，則可能需要將其退回給使用者以進一步澄清。
避免使用弱語，如：最小化/最大化、快速、使用者友好、簡單、足夠、充足、快捷。最好定義系統的實際限制。例如，不要使用“系統應快速為學生註冊”，而是使用“系統應在 24 小時內處理每個學生註冊”。
如果可用資訊不足——編寫出來的需求質量就會很差，因為開發人員會對缺失的資訊做出假設。解決方法是經常進行清晰的溝通。
避免在需求中描述實現。您需要專注於“什麼”，而不是“如何”。例如，“提供一個數據庫”。更可取的是：“提供儲存、顯示和排序客戶資料的功能”。這可能是資料庫，但也允許其他可能性，例如 XML 檔案。
避免描述系統的使用方式。例如，“系統應允許使用者開啟對話方塊並輸入資料”。更可取的是：“系統應允許資料輸入”。
優先順序排序
第一組需求/使用者故事通常是願望清單，其中包含許多“希望有”的功能。在專案的過程中，會進行細化和澄清，並在後續的迭代中定義需求/使用者故事。在對解決方案進行工程設計的過程中，會識別出額外的需求或對現有需求的更改。
誰應該參與需求/故事的優先順序排序？
客戶 開發人員 利益相關者
傳統方法將需求分為“基本”需求，這些需求必須包含在系統中；“有用”需求，這些需求如果省略會導致系統效率降低；“理想”需求，這些需求不是核心需求的一部分，但會使系統對使用者更具吸引力。
敏捷方法使用連續的迭代來識別最關鍵的需求。哪些需求或任務將在本迭代中實現？下一個迭代？Scrum 和極限程式設計方法都使用需求堆疊來對需求進行優先順序排序。故事卡片按順序排列，並在約定的級別新增新的卡片。卡片可以刪除或重新排序。在任何時候，開發人員都正在實現優先順序最高的那些需求。
總結編寫良好的需求和使用者故事是一項艱鉅的任務，需要仔細思考和分析，但這不是魔法。隨著經驗的積累，開發人員可以透過編寫有效且切合實際的需求來提高專案質量，最大限度地減少返工。
 案例研究 養老院管理系統 | |||
|
小組：Jason McBratney、John Hunt、Chris Morton 為 Leith Group
|
參考文獻
Cohn, M. 使用者故事
Boehm, B 和 Turner, R. 權衡敏捷性和紀律
http://www.agilemodeling.com/essays/changeManagement.htm
http://satc.gsfc.nasa.gov/support/STC_APR97/write/writert.html
http://www.agilemodeling.com/essays/costOfChange.htm
http://www.complianceautomation.com/papers/writingreqs.htm
http://www.reqexperts.com/media/papers/Managing_Requirements.pdf
http://www.reqexperts.com/media/papers/writing_good_requirements.htm
http://www.reqexperts.com/media/papers/A_Case_for_Priority.pdf