應用開發的思考2
我發現多數需求分析說明書編寫得毫無價值,多數公司的做法是寫完該需求說明書之后,就把它扔一邊,埋頭苦干寫程序了.一方面這和公司對需求分析的認識不夠有關,另一方面,也和需求分析編寫方式不盡合理,以至它的價值難以體現有關.
軟件程序,從最終的抽象意義而言,是計算機系統對自然語言的翻譯.而需求分析充當了翻譯任務的急先鋒.很難想象,如果沒有一份好的需求說明書,針對客戶含糊不清的自然語言描述,開發者能做出一個符合要求的優秀軟件.然而,什么是好的需求說明書?應具備什么樣的特點?我認為好的需求說明書應有由如下三個階段,經多次循環反饋而逐漸形成:
1 調研階段:
客戶和需求分析師討論系統該具有的功能.客戶希望系統能做什么,達到什么樣的效果.需求分析師的責任是認真聽取客戶的原始言語,通過討論,語言的提煉和客戶達成共識,最終得到確切的需求--客戶希望系統能做什么.這一過程運用的是自然語言,需求分析師必須具備良好的溝通能力,文字表達能力,并且必須具備客戶領域內的相關業務知識,不使用用戶不懂的計算機專業詞匯.
參與人員:需求分析師,客戶,系統設計師.
運用工具:自然語言.
階段成果:調研記錄書.
2 確定功能結構和設計系統原型:
需求分析師和系統設計師討論客戶的需求.需求分析師針對調研階段的記錄,逐點提出客戶需求,并用uml的用例概念,和系統設計師進行討論.系統設計師根據這些需求,運用他的技術,知識和經驗,將之分解總結為系統的功能結構.(此處僅針對應用系統而言,對于其他系統,可能還要總結進程結構或部署結構)得到功能結構之后,系統設計師還要構建系統原型,該原型用于和客戶進行更好的交流.
在這一階段之后,由于得到了功能分解表和系統原型,需求分析師和系統設計師已明白系統的雛形,該成果將作為開發者和客戶繼續進行討論的基礎.
參與人員:需求分析師,系統設計師(或該設計師領導的相關團隊).
運用工具:uml,構建原型的相關工具技術.
階段成果:功能分解表,系統原型.(大致的業務流程圖)
3 編寫需求分析說明書
在參照功能分解表和系統原型的基礎上,需求分析師和系統設計師編寫系統的需求分析說明書.該需求分析說明書作為客戶和系統開發者的橋梁,既表達了客戶想要系統做什么的愿望,又反映了系統開發者針對此需求得到的努力成果(功能分解表和系統原型).通過該說明書,對系統具有的功能和最終可能的形態,客戶和開發者達成共識.
有可能經過多次的1,2階段的反復,最終才得到需求分析說明書.各階段的成果應妥善保存.
參與人員:需求分析師,系統設計師,客戶.
運用工具:自然語言,功能分解表,系統原型.
階段成果:改進的功能分解表,系統原型,(業務流程圖),需求分析說明書.
第1階段,是開發者得到自然語言需求的階段.該階段的重要性不言而喻.
第2階段,是需求分析編寫的核心階段.很多公司會有意無意忽略該階段.確實,該階段耗費的人力和時間挺多,但這個階段決不能馬虎的進行,甚至忽略.只有詳盡的將自然語言翻譯成功能需求表,并為此構建原型,開發者對系統究竟能做什么和未來該怎么做的認識才會逐漸加深.并且,對應的功能界面,能夠讓客戶大致認識到最終的系統會是什么樣子.他能夠據此提出自己的滿意度,修改或者增加需求.
我主張在構建功能分解表的時候,將界面的相關控件,字段,標簽都一一列出,并且和原型的界面相對應.這樣在功能分解表/需求分析說明書確定之后,開發者就有可能根據這些控件/字段/標簽確立業務層的接口和數據庫系統的表結構,減少了概要設計階段所作的工作量.
以下是一個分解功能的例子:
功能:修改我的資料
功能簡述:用戶可以更新個人資料
界面控件:姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本框(輸入確認密碼),所屬組別選擇框 (輸入所屬組別),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
界面:見圖(修改我的資料)
只有經過詳盡完備的1,2階段后,我們才可能進行第3階段,將1,2階段的成果綜合起來,和客戶進一步討論需求.客戶可能會對功能分解不滿意,對原型有異議.這樣我們必須返回到1,2階段,再次分解功能,修改原型.直到客戶滿意為止.
在這個基礎上,我們才可能編寫最終的需求說明分析書.我認為,嚴格按照上述流程進行編寫的需求說明書,就是好的.它的特點總結如下:
1)經歷過反復功能分解和原型構建.客戶因原型而清楚認識到自己想要系統的形態,開發者經多次反饋明確了系統所具備的功能.
2)編寫良好的功能分解表,能夠幫助開發者進一步設計業務接口.
3)構建成型的原型,有助于開發者設計數據庫系統.
4)*明確的業務流程圖,能夠協助開發者構建系統的業務流.
用戶的需求永遠在變化,沒錯.但如果我們按照上述步驟努力在分析階段弄清楚客戶的需求,以后的開發維護階段就能將需求變更的代價降到最低.只有對事物認識越深刻,才越有可能認識到事物可能存在的變化.這條哲學法則在需求分析階段同樣適用.
經過以上討論,我們就可以看到為什么多數公司的需求分析書難以達到預期要求.它們沒有功能分解階段,沒有原型構建階段,沒有反饋認識再加深的階段....這樣的需求分析書,僅僅為構建而構建,對系統的開發毫無幫助.(我還看到過有人用三天寫完一個系統的需求分析書)接踵下去的軟件開發階段,如何進行?這樣做出來的軟件,能好到哪里去?
一點淺見,貽笑方家. :-)