資料結構
網路
關係型資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C 程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝設計
法律研究敏捷開發中的使用者需求和使用者故事
需求指的是你想要從產品中獲得什麼，而使用者故事則指的是產品將如何幫助你。換句話說，需求指的是產品應該做什麼，而使用者故事指的是使用者如何從產品中獲得他/她想要的東西。
即使需求和使用者故事聽起來很相似，並且在沒有區別的情況下似乎令人困惑，但根據它們的視角，兩者仍然是不同的。在本文中，我們將詳細解釋使用者故事和需求。讓我們開始吧。
什麼是使用者故事？
使用者故事用於描述專案如何為終端使用者創造價值。目前，編寫滿足使用者故事需求的程式碼的責任在於開發團隊。在理想情況下，開發人員會與業務所有者和利益相關者密切合作，以解決程式碼建立的細節。
用例和技術需求文件不能替代使用者故事。相反，產品開發人員可以建立使用者故事來幫助組織將在專案時間線上部署的功能。使用者故事可以被認為是對話的開始，該對話定義了對產品的真正需求。
什麼是需求？
軟體需求解釋了程式應該具有的行為。它們包括對目標系統功能和能力的描述。業務分析師、產品經理或產品負責人編寫需求。技術負責人和將在功能或升級上工作的工程師也經常參與其中。
需求示例
您可以使用欄位名稱、姓氏、電子郵件、自由文字和提交按鈕來建立使用者聯絡表單。單擊提交按鈕時，客戶服務團隊會收到一封電子郵件。
軟體元件定義了應用程式必須具有的功能。它們包含對目標平臺的功能和能力的描述。需求由產品經理、產品負責人或業務分析師準備。首席技術官和從事功能或更新工作的工程師也經常參與其中。
與經典的瀑布方法中的需求文件相比，使用者故事通常在敏捷技術中更頻繁地使用。
使用者旅程（使用產品的人想要能夠做什麼）是使用者故事的主要焦點。功能性（或產品應該能夠完成什麼）是需求的傳統焦點。
使用者故事和需求之間的主要區別
使用者故事通常在敏捷技術中更頻繁地使用，而需求文件通常與傳統方法相關聯。
由於使用者故事的輕量級，因此它們鼓勵比需求文件更多的對話和參與。
根據正式的需求規範實施軟體時，實際需求可能已經發生變化。在使用使用者故事時，任何人都可以在任何時候對使用者故事積壓工作做出貢獻。這可能是開發人員提出有關技術債務的問題，客戶要求新功能，或測試人員發現使用者體驗問題。由於積壓工作是共同努力的結果，因此它確保正在完成的工作符合客戶的需求。
需求到使用者故事
如果需求包含未說明的假設，則可能難以實現。例如，郵件伺服器是否可用？如果不是，開發需求可能需要更長的時間。其他時候，設計可能會阻止找到更簡單的解決方案來做同樣的事情。
另一方面，使用者故事描述了使用者聯絡我們的支援團隊的情況。如果傳送郵件不切實際或成本過高，我們可以立即提出替代解決方案。例如，我們可以寫入資料庫，透過 Google Docs 使用表單，或者只使用電子郵件地址而不是表單。對於需求來說，這很難實現，但是對於故事和在場的營銷專家來說，這很容易。
敏捷性
因此，每當我們有需求時，我們通常會嘗試預測這些需求，表達我們的信念，並確保一切順利進行。因此，在這種情況下，可能存在預先計劃以確保郵件伺服器存在的其他需求。
這使我們想到了需求和故事之間的另一個重要區別，即層次結構。正如我在上面演示的那樣，需求本質上必須以某種自然層次結構排列，以便滿足依賴關係。另一方面，故事是目標驅動的，沒有這些限制。
這似乎是故意的，因為在敏捷中，在專案過程中根據需要新增、刪除、推遲和更改故事至關重要。雖然有時可以更改或刪除需求，但由於所有依賴關係，移動它們通常非常困難。簡而言之，它並不經常發生。如果您使用規範工作，那麼您的快速部署將受到影響，或者它在能夠接受更改的意義上不會非常敏捷。
結論
總之，從終端使用者的角度編寫的軟體功能的非結構化一般解釋稱為使用者故事。其目的是解釋軟體功能對使用者如何有用。人們很容易認為使用者故事只是軟體系統的規範。使用者需求階段側重於識別使用者目標和需求，以便技術能夠輕鬆滿足這些需求。
251 次瀏覽
