應用開發的思考2
我發現多數需求分析說明書編寫得毫無價值,多數公司的做法是寫完該需求說明書之后,就把它扔一邊,埋頭苦干寫程序了.一方面這和公司對需求分析的認識不夠有關,另一方面,也和需求分析編寫方式不盡合理,以至它的價值難以體現有關.
軟件程序,從最終的抽象意義而言,是計算機系統對自然語言的翻譯.而需求分析充當了翻譯任務的急先鋒.很難想象,如果沒有一份好的需求說明書,針對客戶含糊不清的自然語言描述,開發者能做出一個符合要求的優秀軟件.然而,什么是好的需求說明書?應具備什么樣的特點?我認為好的需求說明書應有由如下三個階段,經多次循環反饋而逐漸形成:
1 調研階段:
客戶和需求分析師討論系統該具有的功能.客戶希望系統能做什么,達到什么樣的效果.需求分析師的責任是認真聽取客戶的原始言語,通過討論,語言的提煉和客戶達成共識,最終得到確切的需求--客戶希望系統能做什么.這一過程運用的是自然語言,需求分析師必須具備良好的溝通能力,文字表達能力,并且必須具備客戶領域內的相關業務知識,不使用用戶不懂的計算機專業詞匯.
參與人員:需求分析師,客戶,系統設計師.
運用工具:自然語言.
階段成果:調研記錄書.
2 確定功能結構和設計系統原型:
需求分析師和系統設計師討論客戶的需求.需求分析師針對調研階段的記錄,逐點提出客戶需求,并用uml的用例概念,和系統設計師進行討論.系統設計師根據這些需求,運用他的技術,知識和經驗,將之分解總結為系統的功能結構.(此處僅針對應用系統而言,對于其他系統,可能還要總結進程結構或部署結構)得到功能結構之后,系統設計師還要構建系統原型,該原型用于和客戶進行更好的交流.
在這一階段之后,由于得到了功能分解表和系統原型,需求分析師和系統設計師已明白系統的雛形,該成果將作為開發者和客戶繼續進行討論的基礎.
參與人員:需求分析師,系統設計師(或該設計師領導的相關團隊).
運用工具:uml,構建原型的相關工具技術.
階段成果:功能分解表,系統原型.(大致的業務流程圖)
3 編寫需求分析說明書
在參照功能分解表和系統原型的基礎上,需求分析師和系統設計師編寫系統的需求分析說明書.該需求分析說明書作為客戶和系統開發者的橋梁,既表達了客戶想要系統做什么的愿望,又反映了系統開發者針對此需求得到的努力成果(功能分解表和系統原型).通過該說明書,對系統具有的功能和最終可能的形態,客戶和開發者達成共識.
有可能經過多次的1,2階段的反復,最終才得到需求分析說明書.各階段的成果應妥善保存.
參與人員:需求分析師,系統設計師,客戶.
運用工具:自然語言,功能分解表,系統原型.
階段成果:改進的功能分解表,系統原型,(業務流程圖),需求分析說明書.
第1階段,是開發者得到自然語言需求的階段.該階段的重要性不言而喻.
第2階段,是需求分析編寫的核心階段.很多公司會有意無意忽略該階段.確實,該階段耗費的人力和時間挺多,但這個階段決不能馬虎的進行,甚至忽略.只有詳盡的將自然語言翻譯成功能需求表,并為此構建原型,開發者對系統究竟能做什么和未來該怎么做的認識才會逐漸加深.并且,對應的功能界面,能夠讓客戶大致認識到最終的系統會是什么樣子.他能夠據此提出自己的滿意度,修改或者增加需求.
我主張在構建功能分解表的時候,將界面的相關控件,字段,標簽都一一列出,并且和原型的界面相對應.這樣在功能分解表/需求分析說明書確定之后,開發者就有可能根據這些控件/字段/標簽確立業務層的接口和數據庫系統的表結構,減少了概要設計階段所作的工作量.
以下是一個分解功能的例子:
功能:修改我的資料
功能簡述:用戶可以更新個人資料
界面控件:姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本框(輸入確認密碼),所屬組別選擇框 (輸入所屬組別),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
界面:見圖(修改我的資料)
只有經過詳盡完備的1,2階段后,我們才可能進行第3階段,將1,2階段的成果綜合起來,和客戶進一步討論需求.客戶可能會對功能分解不滿意,對原型有異議.這樣我們必須返回到1,2階段,再次分解功能,修改原型.直到客戶滿意為止.
在這個基礎上,我們才可能編寫最終的需求說明分析書.我認為,嚴格按照上述流程進行編寫的需求說明書,就是好的.它的特點總結如下:
1)經歷過反復功能分解和原型構建.客戶因原型而清楚認識到自己想要系統的形態,開發者經多次反饋明確了系統所具備的功能.
2)編寫良好的功能分解表,能夠幫助開發者進一步設計業務接口.
3)構建成型的原型,有助于開發者設計數據庫系統.
4)*明確的業務流程圖,能夠協助開發者構建系統的業務流.
用戶的需求永遠在變化,沒錯.但如果我們按照上述步驟努力在分析階段弄清楚客戶的需求,以后的開發維護階段就能將需求變更的代價降到最低.只有對事物認識越深刻,才越有可能認識到事物可能存在的變化.這條哲學法則在需求分析階段同樣適用.
經過以上討論,我們就可以看到為什么多數公司的需求分析書難以達到預期要求.它們沒有功能分解階段,沒有原型構建階段,沒有反饋認識再加深的階段....這樣的需求分析書,僅僅為構建而構建,對系統的開發毫無幫助.(我還看到過有人用三天寫完一個系統的需求分析書)接踵下去的軟件開發階段,如何進行?這樣做出來的軟件,能好到哪里去?
一點淺見,貽笑方家. :-)
1 引言
1.1 編寫目的
本說明書是客戶與軟件系統開發者的溝通橋梁.客戶根據需求說明書提出需求,闡述系統能做什么.軟件系統開發者根據此需求,闡述需求實現的功能與界面,并將之清晰明白的反映到本說明書中,以供客戶審閱.
本說明書的預期讀者為客戶,業務需求分析人員,系統設計人員,項目管理人員,軟件開發人員等系統開發的相干參與者.
1.2 項目背景
軟件開發過程中無可避免的存在源碼缺陷(以下簡稱BUG).在軟件系統的開發維護階段階段,對BUG的修復管理工作必不可少.本系統提供了bug的管理功能.客戶可應用本系統簡單有效的管理BUG,以協助軟件系統的開發維護工作.
1.3 定義,縮寫詞和符號
BUG:軟件系統在功能或界面方面所產生的缺陷.
2 系統運行環境
2.1 硬件環境
2.1.1 一臺586微機,建議CPU主頻在500MHZ以上,內存大于512MB.
2.2 軟件環境
2.2.1 WINDOWS 或類 LINUX 操作系統.該操作系統應能正常運行JAVA虛擬機.
2.2.2 安裝IE6或FIREFOX1.5瀏覽器
2.2.3 安裝J2SDK,要求版本在1.4以上.
2.2.4 安裝TOMCAT或其他支持SERVLET 2.3 的WEB 服務器.
2.2.5 安裝MYSQL數據庫.要求版本在5.0以上.
3 系統用例說明
3.1 系統用例說明
3.1.1 用例名稱:用戶查看BUG列表
用例編號:1
用例說明:用戶點擊"查看我的BUG"標簽,查看屬于自己的BUG列表.或者點擊"查看所有BUG"標簽,查看所有BUG列表.并能根據自定 義的條件過濾器,查看符合特定條件的BUG.
前置條件:用戶已登錄系統.
3.1.2 用例名稱:用戶查看BUG詳情
用例編號:2
用例說明:在BUG列表上存在HTML鏈接,用戶點擊該鏈接,可以看到BUG的詳細情況.并且用戶可以修改BUG的狀態,修改時間.
前置條件:用戶已登錄系統
3.1.3 用例名稱:用戶增加新BUG
用例編號:3
用例說明:用戶點擊"增加新的BUG"界面,進入增加新BUG界面.可以增加新的BUG到系統.
前置條件:用戶已登錄系統
3.1.4 用例名稱:用戶管理BUG列表過濾器
用例編號:4
用例說明:用戶可以增刪改BUG條件過濾器.在BUG列表中,可以通過選取過濾器查看符合特定條件的BUG(請參照用例1).
前置條件:用戶已登錄系統.
3.1.5 用例名稱:用戶修改個人資料
用例編號:5
用例說明:用戶可以修改個人資料,例如修改EMAIL,住址等.
前置條件:用戶已登錄系統.
3.1.6 用例名稱:用戶管理帳號
用例編號:6
用例說明:系統管理員可以增刪改新的用戶.
前置條件:用戶已登錄系統,且該用戶必須是系統管理員.
3.1.7 用例名稱:用戶管理開發組
用例編號:7
用例說明:系統管理員可以增刪改開發組.在增加新BUG界面,該組名用于劃分BUG的歸屬.
前置條件:用戶已登錄系統,且該用戶必須是系統管理員.
3.2 簡單的用例圖
見圖:
4 系統功能分解
4.1 BUG管理
4.1.1 列出我的BUG
功能簡述:以分頁的列表方式列出指派給我的bug,可以選擇某條記錄進行修改,可以彈出框形式查看bug詳情.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改)
界面標簽(指Label):可選項,序號,概述,緊急程度,狀態,所有人,發現時間.
HTML鏈接:序號
4.1.2 查看所有bug
功能簡述:以分頁的列表方式列出所有bug,可以選擇某條記錄進行修改,可以彈出框形式查看bug詳情.可以按過濾器查看符合該 過濾器條件的bug.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),過濾器選擇框(選擇某個過濾器).
界面標簽(指Label):可選項,序號,概述,緊急程度,狀態,所有人,發現時間.
HTML鏈接:序號
4.1.3 增加新的bug
功能簡述:用戶可以增加新的bug
界面控件:所屬模塊選擇框(設定bug的所屬模塊),發現時間日期控件(確定bug的發現時間),發現者選擇框(確定bug的發現者),狀 態選擇框(確定bug的狀態),截止期限日期控件(確定bug的建議修改時間),指派給選擇框(選擇bug的所有人),描述文本域(輸入 bug的描述),附件一(文件選擇框),附件二(文件選擇框),附件三(文件選擇框).提交按鈕.
界面標簽(指Label):根據界面控件描述進行配對.如所屬模塊選擇框的標簽是"所屬模塊".不再贅述.
4.2 個人資料
4.2.1 修改我的資料
功能簡述:用戶可以更新個人資料
界面控件:姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本框(輸入確認密碼),所屬組別選 擇框(輸入所屬組別),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
4.3 過濾器配置
4.3.1 列出過濾器
功能簡述:列表方式列出該用戶所增加的過濾器,可以選擇某條記錄進行修改,可以彈出框形式查看過濾器詳情,可以刪除某條記 錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,序號,過濾器名稱.
4.3.2 增加新過濾器
功能簡述:用戶可以增加新的過濾器.每個用戶只能有最多10個過濾器.
界面控件:過濾器名稱文本框(輸入過濾器名稱),狀態選擇框(選擇狀態),所屬模塊選擇框(選擇模塊),發現者選擇框(選擇發現者 ),指派給選擇框(選擇bug的所有人),發現時間段時間選擇框(選擇發現起始時間),發現時間段時間選擇框(選擇發現終止時間 ),截止時間段時間選擇框(選擇截止起始時間),截止時間段時間選擇框(選擇截止終止時間).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如過濾器名稱文本框的標簽是"過濾器名稱".不再贅述.
4.4 系統管理
4.4.1 用戶列表
功能簡述:列表方式列出所有用戶,可以選擇某條記錄進行修改,可以彈出框形式查看某用戶詳情,可以刪除某條記錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,登錄ID,Email,電話,職位
4.4.2 增加新用戶
功能簡述:增加新用戶
界面控件:登錄ID文本框(輸入用戶帳號),姓名文本框(輸入姓名),郵箱文本框(輸入郵箱),密碼文本框(輸入文本),確認密碼文本 框(輸入確認密碼),是否管理員選擇框(設定是否管理員),地址文本域(輸入地址),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):根據界面控件描述進行配對.如姓名文本框的標簽是"姓名".不再贅述.
4.4.3 開發組列表
功能簡述:列表方式列出所有開發組,可以選擇某條記錄進行修改,可以彈出框形式查看某記錄詳情,可以刪除某條記錄.
界面控件:序號Radio(可以選擇某條記錄),修改按鈕(對記錄進行修改),刪除按鈕(對某條記錄進行刪除)
界面標簽(Label):可選項,開發組名稱,描述.
4.4.4 增加新開發組
功能簡述:增加新開發組.
界面控件:組名稱文本框(輸入開發組名稱),備注文本域(輸入備注).提交按鈕.
界面標簽(Label):組名稱,備注.
4.4.5 日志列表
功能簡述:分頁列出系統日志.用戶刪除某條記錄,可以彈出框形式查看某條記錄詳情.
界面控件:刪除按鈕.
界面標簽(Label):可選項,日志時間,用戶ID,操作概述.