根據專家所說，需求管理通常在軟件開發過程中的痛點。很少有組織能夠做到良好的工作記錄、分析、跟蹤和優先考慮他們的應用需求—并且軟件項目也因此受到影響。但是，隨著組織開始考慮托管他們的公共云的應用，好的需求管理就變得至關重要。云端托管應用提供了許多操作上的好處，但是也增加了額外的一層復雜性，正確的需求就變得重要了。

“如果你全面的看需求管理——無論應用是被部署到私有云、公共云，前提還是在Web環境中——一般情況下，我們都做得不夠好，”voke公司創始人兼分析師Theresa Lanowitz說，“需求管理是軟件工程的致命弱點。”

在過去曾忽視過需求管理的組織會恍然醒悟，當他們開始將應用應用到公共云。將應用移動到云，可能會導致成本和運營成本節約，因為是在不需要采購和維護基礎設施的前提下。然而，這是非常有好處的—缺乏本地基礎設施——也放大了需求管理的重要性。這尤其適用于非功能需求。

“保證他們是正確的更加重要，因為你不能擁有基礎設施，”Lanowitz說，“應用不是裝在站點上的，站點上的你可以修改。”

Rice咨詢服務公司***顧問和培訓師Randy Rice同意Lanowitz的說法。非功能需求，如可靠性、可訪問性、安全性和性能“傳統上定義的不是很好，”他說，“(云)迫使利益相關者考慮他們所真正需要的。”

“我們要看看需求并且說，‘他們對我們的組織來說是戰略。’不關注這個，我們將繼續交付不好的軟件，”Lanowitz說“但是現在你部署到云，并且從一個需求視角來說，性能和安全性成為了兩個大問題。”

需求確認和應急計劃

定義非功能需求并且確立他們作為你的云提供者服務水平協議(SLA)的一部分，僅僅是一個開始。組織必須有一種方法來確認這些需求在應用部署到云后，不斷符合需求，Rice說。主要的云提供者不太可能同意審計。然而，一些有控制臺，能提供到應用可訪問性、性能和其他非功能需求的可見性。還有其他云提供商可能需要投資你自己的工具。

同樣，組織需要考慮需求不被滿足的可能性，并且將突發事件放在相應的地方。Rice解釋說，在公共云中，比你在私有云或者本地部署，硬件資源、軟件、數據庫等等你能控制的更少。

“想象這樣一個場景：你擁有一個基于公共云的銷售應用，能支持1000名銷售人員。如果某天應用宕機了，你就會失去很多銷售額。”Rice說，“因此，公司可能有來自不同提供者的另一個應急的銷售應用，它將主要網站的日常數據備份。它是冗余的，但當主要的問題出現時它也是很好的。當然，應急計劃的水平取決于風險的等級。”

回到需求管理的根本

組織可能會發現云的需求管理的前景有點勢不可擋。Lanowitz承認這一挑戰： “需求是非常困難的。他們是幾乎所有的失敗的根源，”她說道。

為了幫助緩解需求管理的過程，專家們建議回到根本。這始于聚集適當的利益相關者。Rice說“需求收集的黃金法則之一就是你必須在房間里有合適的人。”

當你在云中部署一個應用，你將需要涉及到比你在過去更廣泛的一群人。例如，你將接觸到終端業務用戶以及測試和數據中心的人們。“之前，IT和業務是分開的”Rice說“但是，現在希望云提供者能夠實現IT和業務處在相同的頁面上的需求”。

當在定義功能需求的時候，將終端用戶包含進來顯得尤為主要。Rice說：“我們更傾向于將我們的業務用戶當作是消費者，但是有了云你就會有更多的解決商務問題的選擇。”例如，云提供了擴展成不同環境的能力而不用考慮物理數據中心。Rice解釋道：“在過去，一個業務單元可能因為缺乏內部資源而被否定其可能擁有的需求和功能，有了云，業務單元的內部資源變得更加充沛，而且他們可能沒有意識到因為這種充沛的資源能使得他們能做些什么。”

如果這些需求沒有一個中央控制點，經過努力定義的需求也好不到哪里。這就需要一個工具。Rice說“這么多人定義需求，并且他們在文檔中分散的到處都是。多年來，它已經成為一個標準的***實踐來使用一個工具去監視他們。它有助于跟蹤和驗證他們。”

結論

盡管當管理基于云的應用的需求時，必須考慮到一些特殊的因素，做到這樣將導致更高性價比的應用。