八 我們應當怎樣做需求調研 需求捕獲(下)

2021-07-02 17:30:19 字數 1482 閱讀 6352

前面我們討論了,需求分析工作是乙個迭代的過程:需求捕獲->需求整理->需求驗證->再需求捕獲······需求捕獲是這個迭代過程的開始,也是整個需求分析工作中最重要的部分。沒有捕獲哪來後面的整理與驗證工作?但是,非常遺憾,按照我以往的經驗,需求捕獲是我們最薄弱的環節。前面我提到的許許多多專案開發的問題都可以歸結為需求分析的問題,而許許多多需求分析的問題又都可以歸結為需求捕獲不完整的問題。需求捕獲是整個需求分析工作中最難把握的乙個部分,它不僅僅是乙個技術的問題,還涉及到人際交往、溝通、知識理解,以及心理學等一系列問題。但更讓我感到遺憾的是,在我讀過的許許多多關於需求分析的書籍中,討論需求分析與建模的書很多,但討論需求捕獲的書籍卻寥寥無幾。確實,要討論這部分內容,真的已經遠遠超出了軟體開發這個知識領域。 

那麼,在軟體需求捕獲過程中,最根本、最容易犯錯的問題是什麼呢?我認為是乙個態度的問題,是採用主動態度去捕獲需求,還是採用被動的態度去捕獲需求。如果需求分析人員總是諾諾諾,客戶說什麼,我們就記什麼。客戶處於非常強勢的地位,給我們提出了非常多**、技術難於實現的需求,而我們的需求分析人員卻成為記錄員,埋頭記錄客戶說的每一句話,不加分析地就直接扔給了開發人員。這就是採用被動的態度去捕獲業務需求的方式。毫無疑問,這樣的需求分析必然將給專案開發的後期帶來巨大的風險。 

為什麼會出現這樣的情況呢?經過深入分析我們會發現,從客戶嘴中說出來的需求,只是整個軟體需求中的冰山一角,還有兩類需求需要我們自己去挖掘:客戶嘴中沒有說出來的需求,和客戶壓根兒就沒有想到的需求。 

什麼是客戶嘴中沒有說出來的需求,並不是客戶故意賣弄官子不願說出來,而是在客戶所在業務領域已經約定俗稱,在他們看來已經是天經地義,根本就不用說出來的業務規則。然而,作為剛剛涉足該領域的需求人員,他們是不了解這些規則的。如果採用被動的方式去僅僅記錄客戶說出來的需求,毫無疑問會遺失這部分需求,這就是為什麼直到專案後期,軟體被研發出來即將交付使用,客戶才提出說這不是我想要的軟體,並提出大量變更需求的原因。這時,我們常常問客戶,你們為什麼不早說呢?而客戶卻十分委屈,這麼簡單的道理還需要我說出來嗎? 

舉例說明吧:在我從事的稅務行業中,對納稅人徵收的稅種包括增值稅、企業所得稅。增值稅通常是按月徵收的,而企業所得稅是按季或者按年徵收的。就拿增值稅來說吧,稅款所屬期是開票日期的上個月,為什麼呢?納稅人往往是在上個月產生銷售收入,然後在下個月完成申報和繳納稅款。這些知識對於稅務人員來說是太基本的常識了,所以在他們看來就是天經地義而不需要說出來的業務規則。但作為軟體開發人員的我們卻常常因為不知道而將業務弄錯。 

如何破解這樣的問題呢?那就是要求我們在需求分析的整個過程,不斷進行業務領域知識的學習。在我做需求訪談的初期,我往往不是跟客戶談需求,而是先跟客戶談業務。你們是怎樣操作的?都經過些什麼流程?誰來完成這些操作的?為什麼這樣操作?注意,在所有這些問題中,最後乙個問題是最重要的。客戶業務領域中的所有操作、所有流程都是有它存在的意義的,它體現了其內部的原因與作用。多問為什麼,可以讓我們深入地理解這些領域知識,站在客戶的視角去思考問題,進而深入地理解客戶為什麼要提出他們的那些業務需求。當乙個需求分析員能達到這樣的水平,客戶嘴中沒有說出來的需求就會被源源不斷地被發掘出來,最終做出來的需求分析才是完整的、準確的。

我們應當怎樣做需求調研 初識

很多需求分析的工作是從需求調研開始的,我們就從這裡說起吧。需求調研是需求分析最重要的一環,也最集中地體現了需求分析的特點 既是乙份體力活兒,更是乙份技術活兒。它既要求我們具有一種理解能力 設計能力,更要求我們具有一種與人交往 溝通的能力。在乙個陽光明媚的下午,專案經理帶領著專案組成員,參加了客戶組織...

七 我們應當怎樣做需求調研 需求捕獲(上)

前面我們討論了,需求分析工作是乙個迭代的過程 需求捕獲 需求整理 需求驗證 再需求捕獲 需求捕獲是這個迭代過程的開始,也是整個需求分析工作中最重要的部分。沒有捕獲哪來後面的整理與驗證工作?但是,非常遺憾,按照我以往的經驗,需求捕獲是我們最薄弱的環節。前面我提到的許許多多專案開發的問題都可以歸結為需求...

我們應當怎樣做需求確認 需求列表

需求分析是乙個我們與客戶不斷溝通的過程,這個過程就如同我們與老闆的一次對話。老闆把你叫去,給你交待了一大堆任務。我們首先是仔細聆聽任務的內容,然後整理個一二三四。然後我們複述一遍老闆的意思 老闆,我複述一遍,您看看我理解得對不對。首先,您要求我 然後 最後 老闆 恩,就是這意思,你照著辦吧。之後,我...