如何避免「壞」的要求

Question

我經常聽到「X％的軟件項目由於不良要求而失敗」。該聲明中的X範圍在70到95之間。但是，我很少聽到要求如何變壞。事實上，聲明本身表明實際上有要求。

是什麼導致「壞」的要求？怎樣才能避免？

Answer 1

對於成功的需求獲取你需要

• 有客戶在現場，討論的要求，讓他來給您解釋
• 要求必須是可測試的，可覈查的。有了它們的列表，最後你應該能夠通過清單並直接驗證它們在最終產品上的正確實施。
• 他們應該有一個適當的細節水平。存在不同類型的需求（目標級別，領域級別，產品級別，設計級別）。要求應適當分類。

通常問題在於客戶和開發者之間缺乏溝通和理解。此外請記住，有時甚至顧客本身也不完全瞭解他想要的東西。因此討論，紙張原型等非常重要。

這PIC是我最喜歡的:)

Answer 2

首先，要求有效，它需要是可測試。否則，就不可能追蹤它，測量它，報告它......這是邪惡的根源。

如何避免這種情況？確保一個要求：

• 在時間&資源（例如$）

• 可測試爲界

否則，您正在使用的 「開環」 和我相信你可以欣賞後果。

備註有時需求會帶有「定性」特性：產品經理/團隊需要爲其定義「定量」定義。

Answer 3

我想你會發現，如果你把它解釋爲如下它會更有意義：

「軟件項目的X％失敗是由於需求不好定義」

有很多東西你可以做

• 確保您可以實際測試要求
• 確保分析師實際上了解用戶什麼真正 MEA納秒。用戶常常要求的不是他們真正想要的。
• 確保開發人員理解這一要求。如果開發人員得到了一個不好的規範，並且必須做出錯誤的假設，那麼當程序員必須糾正這個假設時，時間就會被浪費掉，除了常見的錯誤之外。
• 確保用戶確實測試了他們的需求已被滿足。比從未更好（發現）晚。

Answer 4

除了不可能/不切實際或無法驗證的要求之外，「不良」可能指的是錯誤地收集 - 它們的要求與實際需要的應用程序不匹配。其中一個原因是用戶經常不知道他們需要或想要什麼。

Answer 5

每當我看到這些統計數字，我都會想起昂貴的，頭重腳輕的瀑布式項目，第一個版本已經完成並呈現給客戶，他很快告訴項目，「這不是我想要的。 「

這就是爲什麼現在大多數成功的項目都是使用「迭代」模型完成的，客戶一直參與設計過程。

在這種情況下，「需求」更加鬆散地定義，並隨着項目的進展而有所變化。

Answer 6

敏捷開發方法的一大部分是接受需求會發生變化的事實。

因此，你不應該試圖與之對抗，而應該創建一個包含它的過程。

Answer 7

他們大概的意思是 「miscommunicated」 的要求。

如果你仔細想想，有很多方法可以錯誤地陳述需求，無論是有意或無意的。處理問題的一些方法：

• 意識到系統的要求可以不斷變化。否則，客戶會說：「是的，變了，沒有人告訴你？」

• 問幾個關鍵人物的要求 - 這還不足以問問首席執行官，同樣，只問實際使用系統的下級人員是不夠的。

• 確保少數人負責向您傳達需求 - 這些人（中型項目中不超過5人）應該有一個很大的動力來爲您提供成功實施的所有信息。如果你沒有這些人，你很可能會失敗，因爲每個人都忙於向你解釋事情，他們將有一種不鼓勵與你交談的動機，因爲你可以聲稱X人告訴你實施系統他們的方式你做。您需要管理層的支持來創建這組人員。

• 您需要驗證與其他人的假設。有時你需要用五種不同的方式提出同樣的問題。

• 害怕絕對......「銷售價格無法改變」有時意味着「我希望在需要改變當前客戶價格的情況下實施主管覆蓋。「

• 儘可能多地理解業務流程如果你正在編寫一個銀行業務應用程序，要求花一天的時間在銀行看看人們如何使用這個系統如果你提交了一個項目階段，事情：觀察正在使用的系統，並積極尋找洞。

• 識別什麼時候沒有足夠詳細的指定，並堅持要正確地做出來，做模型，手繪，流程圖，無論它需要做什麼確定要求的來源和您在同一頁上。

這些都只是來自經驗......我認爲「不良要求」真的意味着「客戶和執行者之間的不良通信」。

Answer 8

在敏捷中，我們使用縮寫INVEST。故事（它站在了要求）應爲：

• 我 - 獨立
• N - 元
• N - 價值
• ë - 估
• 的S - 小
• 筆 - 可測

要求不是從山頂上交給你的神器。它們是您和客戶（或其代理人）之間發現和對話流程的副產品。的壞要求

Answer 9

我的經驗表明下一個可能的來源：

• 用戶/客戶往往不知道自己想要什麼。 處理這種情況的可能方法要麼有好的業務分析員，他們可以執行必要的分析或者有適合該用戶（或不適用）的良好的現成產品。
• 分析師無法提供相應的質量要求。 是的，它發生了。聘請更好的分析師/技術專家，但之前失敗，而不是 後。測試要求，分析使用案例，儘早繪製狀態序列圖 以瞭解用戶案例的覆蓋範圍和 等。換言之，這與一般建模有關。
• 那麼，從市場需求/模型有可能翻譯成 技術規格。
• 設計質量問題（執行不能滿足要求）。

應該做些什麼來克服這些問題？讓我們允許工程師提供反饋，讓我們不要關閉需求並儘可能使其變得靈活。通常，即使通常具有良好的一致性要求，我們在實施階段仍面臨一些低級硬件限制，並且需要追蹤變化。從另一方面讓我們瞭解客戶，不僅是技術。我看到有大量工作被拋棄的項目數量僅僅是因爲它們對開發者而言看起來不錯，但對客戶來說卻不是那麼好。與客戶的溝通能力越低，就越有可能發生這種情況。

我的理解是過程中應允許在所有的階段，但是從另一面靈活需求的變化應該讓所有的工作的可跟蹤和限制範圍，需要最低限度。問題是要在所有這些之間取得平衡。至少我的建議是我們應該採取最短的開發週期來降低所有的風險。

Answer 10

其中最有價值的東西是一個發展組織可以做（但很少這樣做）是驗證的要求。儘可能快速且低成本地設計設計，並與客戶一起審覈。如果可能的話，以審查可以構建爲任務演練的方式進行，以便開發人員和用戶可以一起瀏覽用例，並決定建議的設計是否可以解決問題。然後，如有必要，請重新執行。

有一本關於收集和理解要求的優秀書，名爲JoAnn Hackos和Janice Redish的界面設計的用戶和任務分析。這是一本很大的書，但它非常易讀，充滿了實用的技巧和工具。

Answer 11

是什麼使一個不好的要求？一，這不是有

我在這裏看到了很多好的答案關於一個壞的要求是一個是miscommunicated或半生不熟。他們可能是正確的。

但對我來說，最糟糕的「不良要求」類型之一就是缺少的要求。我在系統中一次又一次地看到。用戶在上線後的第二天說，「哦，XYZ呢？我們真的需要這個。」項目團隊迴應：「XY是什麼？我們一直在爲這個項目工作一年，現在你告訴我們了嗎？」

爲什麼不好？

這是一個殺手，因爲現在每個人都必須爭搶和衝出一個解決方案，而不是普通開發人員需要任何幫助來促進半生產的生產，但你只知道它會拼湊大量的生產支持所有這些'解決方案'的窮人都交給維護人員......你知道，那些沒有獲得項目獎金的人。

同樣，這不是一個不好的要求，但一個是從來沒有要求以開頭。這並不意味着它是無效的;它肯定可能是至關重要的。但在急於完成任務和積極進行項目進度之間，以及我們都是人類而我們犯錯誤這一事實之間，這被忽視了。

你如何避免呢？

你可以花更多的時間在前面，希望大幅主題專家拿起失蹤的差距。一種更有效，更昂貴的方法是花時間參與所謂的「示範辦公室」階段。這就像一個系統測試，但旨在模擬真實的生活條件。測試人員不僅驗證系統是否爲1 + 1提供了正確的輸出，而且其所有部分都在業務流程的上下文中工作。

這當然很難賣。許多項目都會對業務進行分析和測試，以保持「按時和按預算」的全面指標。但是，如果您想要將這些缺失的要求擺脫掉，則必須讓用戶使用它。那麼他們會在口頭需求定義會話中認識到他們認爲理所當然的事情。敏捷專家會補充說，這項測試需要儘早並且儘可能經常地完成，以揭示這些風險，並讓項目團隊有時間確定其優先級並在需要時進行調整。