沙漏之喻
軟件工程——其實是人們希望從工程領域中學習經驗、借鑒理論來幫助解決在復雜系統和軟件開發中遇到的問題。然而，隨著軟件工程的實踐，越來越多的人認識到軟件的生產和造橋鋪路等工程項目的最大不同就是在于開發過程中人的靈活性和創造性�，F在軟件工程的發展趨勢也重視和體現到這一點，既需要包含和鼓勵個體的靈活和創造，但同時也希望從工程的角度對活動進行規范，對創造的過程和結果進行很好的保存和展現。產品/ 項目研發中的需求活動貫穿整個生命周期，前期的市場部門的靈活溝通，廣泛收集的活動到后期研發團隊緊扣需求、巧妙分析、嚴格設計的過程不僅反映了工程的力量，也體現了“藝術”的技巧。但如何將客戶的凌亂的需求和最后的嚴謹的解決方案聯系起來，如何將人的活動和工程的工作平衡起來， 如何在更高的層次分析和分配需求都是系統工程的重點，也是實際工作的難點。
上大學時非常喜歡哲學課，它能一個簡單的問題通過辯證復雜化，可把一個復雜的問題通過統一簡單化。這篇文章無意嘩眾取寵地追求哲學上的高度， 只是想通過以沙漏為模型，以需求為主線，除去細枝末節，更深刻地來認識此間的概念和問題。隨著討論的展開，我們可以看到需求活動的沙漏之喻是如何幫助解答實際工作中的困惑和問題。
從“問題”到“答案”
沙漏是一種古代的計時工具，以它的式樣來刻畫需求的過程顯得非常恰當。圖1中沙漏的上端對應需求捕獲的過程，沙漏的下面是需求開發找到答案的過程。在需求捕獲的過程中，我們需要盡可能的擴展我們的思路，爭取能收集所有可能對最后系統或產品產生影響的信息。然而，當沙漏的口開得很大的時候，收集的信息是高度分散的、凌亂的和非結構化的，有些需要還可能是互相矛盾和沖突的。因此，我們需要沙漏的篩選：對要求解決的問題進行梳理，對系統的范圍做出決定，選擇那些合適的，現實的需求，需求就得到了精煉。這時候問題陳述就是對系統要解決問題的陳述，而不是所有問題的陳述。通過這樣一個漏斗的過程，漏下來的需求就是我們系統要滿足的需求，這個時候的需求是一個正式的結構化的信息以交付給開發團隊。在這個基礎上，就可以設計解決方案。
怎么來做需求精煉和篩選，下文會有更詳細地討論。在這里，我想要談的是區分問題領域和解決方案領域，這也是Jeremy Dick 給我們的忠告之一。經常遇到這樣的情形，客戶抱怨花了錢沒有得到有用的產品，而開發團隊也會覺得很郁悶因為擁有這么多而好的功能的系統客戶卻不懂得“欣賞”，不愿接受。有用和既多且好的功能，這看似統一的表述在這里卻成了矛盾。什么對客戶來說是有用的?其實很簡單，能幫助他解決問題是有用的。而那些擁有很多強大功能的系統和產品如果做不到這一點，矛盾就不可避免。很多團隊負責需求收集的人員有著很強的技術背景，習慣將思考的出發點放在系統應該有什么樣的功能， 怎么實現這些功能。也就是說，他們往往在沒有深入理解客戶問題的情況下直接進入解決方案，而不是首先定義獨立于解決方案的全面而真實需求集合。
那么，如何有效地區分問題領域和解決方案領域呢?其實，從需求的原始陳述開始，到最后的系統實現，整個過程是連續的：體現了從問題到解決方案的持續演化;同時也是離散的，各個階段的需求信息之間應有明顯的差異。最關鍵的區分在涉眾需求和系統需求之間。涉眾需求描述相關涉眾、用戶的想要解決的問題，期望達到的效果;而系統功能需求則是刻畫為了要解決提出的問題，相關的產品和系統應該具有怎樣的功能。通過下表的對比，我們可以清楚地看到兩者之間的差別，特別是在最后一項，兩者在文字描述的差異上更顯示出立足點的不同。
由此可知，我們只有在充分理解用戶想解決的問題的基礎上，才能正確地分析出系統應該提供哪些功能。首先，研發團隊一定要注意對涉眾真實需求的收集和理解。更進一步看，在涉眾需求的收集和定義階段，風險主要存在于定義了錯誤的需要解決的問題;相對去后續階段的設計而言，在定義系統需求階段，系統工程師應該只是抽象地描述解決方案，這個階段的風險存在于不必要地帶入過多地設計約束，影響詳細方案的可能選擇。
可能有讀者會抱怨或懷疑這個思想是不是太理想了:用戶常常就告訴開發團隊他關于解決方案的設計和想法，這時候怎么辦?這就更要求我們的需求捕獲人員有清晰的思路，首先，“用戶可能自己也不知道自己需要什么”，這是常常發生的事情，我們需要適當地提出“為什么”來引導客戶;其次，假定客戶知道自己想要的，那么客戶提出關于實現的想法也反映了他的潛在目標，也就成為了我們設計時的約束。
市場和研發的平衡
在很多上了一定規模的公司中，有兩個團隊是一定存在且非常重要的：市場部和研發部。市場團隊主要和“人”打交道，進行市場的調研和需求的獲取，這處在圖2中沙漏的上半部分。在沙漏的下半部分是工程領域，也就是開發隊伍工作的領域。對開發人員來說，他們很少有機會真正地面對客戶，他們工作的基礎就是需求。對一個項目或產品的成功， 這兩個團隊必須緊密合作，扮演好自己的角色。一旦此間的平衡被打破，團隊就會遇到麻煩。很多公司里市場部門“坐大”，為了贏得客戶的定單，或不深入理解客戶的要求，或是直接“指示”研發部門按照自己對系統實現的理解進行開發。這都違反了上文中提及的需求捕獲的關鍵原則。當另一方面，我也遇到這樣一些公司，它們是由研發起家， 整個研發部門在公司中占有比較多的“話語權”。會有這樣的開發經理或人員，可能是出于追求技術領先或完美的熱情， 在滿足用戶需求的同時，也會增加設計/ 實現其他“多余”的功能點。這些功能點其實是“無源之水”，并沒有實際的市場和用戶需求與之相對應。
需求將市場部和研發部緊密地聯系起來，讓兩者之間的有效連接并維護平衡的角色就是團隊中的需求專家。市場部和直接的用戶，以及相關系統的投資方、監管方、維護方等等進行交流，我們不能保證他們能夠提供準確的清晰的需求描述，因為他們只是在提出他們的問題和對結果的期望，而且要求我們的客戶去學習什么是好的需求和如何提需求是不現實的�，F實的是團隊中有這么一些人，熟悉領域且受到過需求管理方面的指導和培訓，他們知道應該怎么去收集、分析和總結需求。例如在西門子， 負責捕獲客戶需求的工作主要由市場部人員去做，但并不是直接將這些需求轉給開發部。有一個需求管理小組，隸屬于研發中心，主要職責則相當于市場部和開發部的一個接口。需求工程師對從市場部那里獲取的零散和龐大的需求文檔進行整理和分類，然后提交給開發部。開發人員不需要和市場部爭論哪些事情做得到還是做不到，而是由需求工程師來做。這是一個很好的做法，需求工程師可以是一個職位，也可以是一個角色。單獨的職位可能在小的團隊中不太實際，但擁有這個角色的人自己必須很清楚自己的位置：是處在市場和研發中間，需要維護好平衡，做好接口的工作。
文章來源于領測軟件測試網 http://www.kjueaiud.com/