{需求.1004.05} 需求文件製作流程

{需求.1004.05} 需求文件製作

一、案例

  以下內文 純屬虛構, 如有雷同, 實屬巧同

案例一:

  Mark 和 Jerry 很開心的簽了合約及 SOW 並且寫明了要交付 需求報告書、系統設計書、測試報告書

  在經過無數的需求訪談人月後, Olga用以往的範本撰寫需求報告書並交付予使用者

  狀況一:

    Mary: 這是什麼, 我看不懂, 怎麼簽得下去.

    Olga 試圖解釋 Mary 還是不簽核, 限於時程壓力 Jerry 只好跟 Mark 討論並說: 保證上線前改好, 現在要快點動工開發.

    經過政治的手段和上級的施壓, 除非 Mary 找到新工作了, 不然一定簽下去, 而且找好未來脫罪的證據.

 

  狀況二:

    Mary因為很忙, 所以未經詳細的檢閱跟思考直接就簽核了. Mark信任Mary當然就簽核了.

 

結果呢不論狀況一或二, 其實都沒有把核心問題 "雙方的需求認知" 解決, 而是延後, 故當開發團隊花了很大的精力設計架構/套用模型/引用新技術, 一直到使用者測試當天

 

    Mary: 怎麼這樣呢? 我當初不是說 OOXX.

    Rita: 我們是依照確認的需求報告書做設計呀, 並沒有提到你說的 OOXX.

   Mary: < 一堆理由, 推卸責任及情緒用語出現  >

 

專案就開始為了需求修改付出了修改成本,不斷重新開會確認,然後要不就Terminate 要不就莫名其妙結案,至於狀況一的保證呢?永遠都不會實現。

 

案例二:

  Mark 和 Jerry 很開心的簽了合約及SOW 並且寫明了要交付 需求計劃書、需求報告書、系統設計書、測試報告書

  Kevin: 我們公司可是通過CMMI Level 3, 所有的文件都有標準, 請照我們提供的標準撰寫.

  Olga拿到後差點昏倒,照這樣標準寫,寫一年也寫不完,而且裡頭有些項目還真的不知道要填什麼進去...

  Jerry算了一下這樣的文件大概會讓成本上揚30%且會延遲結案日期,試著跟Mark溝通但未果,只好下幾點指示給Olga

  能夠reuse就reuse,前幾章寫細點,後面能偷雞就偷雞。

 

所以就會出現一種很有趣的現象,SOW copy 到需求計劃書 copy到報告書 copy 到系統設計書,常常有些章節不斷出現重覆的文字,而且沒有細節。

 

   Mary: 這是什麼, 我看不懂, 怎麼簽得下去.

   Olga: 這是你們公司的標準文件, 我是照著寫.

   Rita: 這什麼鬼東西, 我要怎麼設計

 

結果呢不僅沒有把核心問題 "雙方的需求認知" 解決, 而且把大家搞得一團亂, SA也不可能重寫,故僅以口頭與開發團隊溝通,然後做出四不像的東西,一直到使用者測試當天

 

    Mary: 怎麼這樣呢? 我當初不是說 OOXX.

    Rita: 因為之前 QQQ , 所以 EEE

    Mary: < 一堆理由, 推卸責任及情緒用語出現  >

 

專案就開始為了需求修改付出了修改成本,不斷重新開會確認,然後要不就Terminate 要不就莫名其妙結案,至於 CMMI 呢?早就不在考量的重點了。

 

從以上的案例來說甲方與乙方的立場是合作又對立的,甲乙方雙方都希望案子準時完成,但甲方認為文件越詳細,未來營運越順利越好,然而乙方思考點在如何在有限時間及成本中將文件交付,所以合約沒提的能不做就不做。所以一切都是"利益導向",畢竟公司請你,不是要你做公益或名聲的,不可能全然站在對手的立場想事,大部份時間是站在對手的痛處要他屈服。

 

二、如何知道要寫到什麼程度

對於需求文件的製作,有100個人就會有100種不同的看法跟結果,要把所有利害關係人的認知透過什麼手法或工具變為一致是不可能的,但在商業模式上常會因為這樣發生無法驗收或超出預期範圍...對專案有害的情形,所以文件要寫成什麼格式如何交付以及要寫到多細都要事前溝通,因為這跟要花多少工,花多少的金錢有關,至於細度要怎麼來預先溝通呢?最好的方式就是範例,而且不是只有骨架的範例,是有肉有內文的範例。

 

較佳的做法是甲方提供1~2份過往的需求文件,且該文件是符合其公司內部Benchmark,乙方亦提供1~2份,並於會議中討論。而參與的人員:甲方未來驗收檢核的人員、甲方未來營運的人員、乙方撰寫文件之人員、乙方檢核文件之人員,專案經理等。除確認項次及內容外,也需將檢核的點列出。如:文字錯誤、語意不清...

 

透過以上的一個溝通交流,雙方才會對交付的文件有那些項次,各項次中的描述那些內容及檢核標準都會有趨於一致的看法。

 

三、製作的流程

requirement_flow

在需求訪談後,系統分析師應該先針對需求做分類及文件化,並且要有可識別的ID,文字的撰寫需完全以客戶的商業語言進行撰寫。

在確認了需求報告書後,才會正式進行需求的分析/規劃/設計,才會開始撰寫所謂的使用者案例、功能列表... 等設計文件。

 

下期預告:

會議記錄的文件, 需求報告書 , 需求追蹤矩陣 文件實例

 

ps. 奇怪 只要在table 裡頭的文字加一些色調,粗斜體就會怪怪的, 我是用Live writer, 結果版面還全被亂掉, 最後用程式碼 + XML Spy 把一堆多的<strong /> 跟<em />殺掉, 總算完成.