系統公告
個人檔案
個人圖檔
ID:yun89
暱稱:小芭樂

熱情贊助
輕旅行
人氣指數
當日人次:
累積人次:
好時光貼曆
我推薦誰
目前無名單
誰推薦我
誰來我家
熱情贊助
RSS 訂閱
RSS2
ATOM
其它資訊
本部落所刊登之內容,皆由作者個人所提供,不代表 yam天空部落 本身立場。
POWERED BY
POWERED BY
會員登入免費註冊
February 18, 2005

最近看了一份系統的需求規格書,開發廠商非常專業,也遵照標準格式製作了一份非常詳細的需求規格書。

MsoNormal" style="MARGIN: 0cm 0cm 0pt">理論上需求規格書是開發廠商完成使用者需求訪談後所必須產出的文件,做為雙方需求確認的依據,之後開發廠商必須依據此規格書開發系統,途中雙方若沒有協議變動的話,需求規格書內容也是日後雙方驗收系統的依據,是一份非常重要的文件,所以不僅開發廠商重視,委託業者對於內容也必須加以審視。

MsoNormal" style="MARGIN: 0cm 0cm 0pt">但是現在遇到一個大問題。因為需求規格書必須詳細記載當初所談定的各項需求,所以一份需求規格書的份量真的非常驚人,看的真是讓人頭暈眼花,這樣的狀況下委託業者有辦法確實完成規格書的審查嗎?是否會因為這樣造成日後雙方的爭議?

s="MsoNormal" style="MARGIN: 0cm 0cm 0pt">雖然近期系統開發上已發展許多方法論,在系統設計、系統開發上已制定許多文件格式,做為系統開發、後續維護的溝通工具,在與使用者(需求者)間的溝通也有UML做為工具,但是除了UML圖形外,文字上的說明輔助也是必要的;但是與使用者間的溝通工具這樣是否可行?畢竟UML也是由系統開發人員角度出發的。

MsoNormal" style="MARGIN: 0cm 0cm 0pt">當然對方如果同樣是資訊人員的話,這樣的溝通工具或許可行,但一般來說,在非軟體公司中提出系統需求的通常不是資訊部門,一般公司型態中,需求部門可能是業務單位、財務單位等不具資訊技術能力的部門,雖然該公司中的資訊部門在計畫中也會扮演協助諮詢角色,但提到要審核需求規格,還是必須由最先提出需求的部門負責,因此這樣的工具對一般人員來說是否太過複雜?

s="MsoNormal" style="MARGIN: 0cm 0cm 0pt">雖然終於把那份份量驚人的需求規格書看完了,但是我實在無法肯定是否有任何遺漏?是否有其他工具可以達到這樣的效果?








引用 (你可以針對此文寫一篇屬於自己的blog/想法,並給作者一個通告)
引用
留言 (0筆) (登入後, 即可開始發表留言)
檢視行動版網頁  |  檢視正常版網頁