軟體需求與功能規格書-以線上糕餅網站為例
  • 封面
  • 前言
  • 1. 系統開發文件的一二事
  • 2. 目標系統說明
  • 3. 需求取得
  • 4. 需求規格
    • 4.1 功能需求
    • 4.2 非功能需求
  • 5. 功能規格設計
    • 5.1 首頁
    • 5.2 註冊為會員
    • 5.3 會員驗證
    • 5.4 系統登入與登出
    • 5.5 忘記密碼
    • 5.6 最新消息
    • 5.7 產品介紹
    • 5.8 顯示購物車與結帳
    • 5.9 編輯基本資料
    • 5.10 變更密碼
    • 5.11 訂單查詢
    • 5.12 常見問題(FAQ)
    • 5.13 連絡我們
    • 5.14 管理者登入與首頁
    • 5.15 Dashboard畫面
    • 5.16 管理者訂單查詢
    • 5.17 會員資料管理
    • 5.18 編輯最新消息
    • 5.19 客戶意見管理
  • 6. API規格
    • 6.1 營業額
    • 6.2 訂單
  • 7. 測試案例分析
    • 7.1 測試案例設計邏輯
Powered by GitBook
On this page

1. 系統開發文件的一二事

最早的系統開發流程是瀑布模式,然後之後發展出螺旋式、RUP與extreme programming,近年來敏捷式開發則常被提到。每一種開發模式都有其優點與適用時機,過程中也都會產出相關的文件,下圖以瀑布模式說明軟體開發過程中會產出的文件。

缺圖

開發團隊成員使用這些文件進行溝通與討論,當文件的說明愈清楚與容易理解則造成誤解的機會就愈小,可節省大量的成本與時間。當誤解發生在軟體開發過程的前段時補救的成本較少;但是若愈晚發現錯誤則所需的補救成本則愈大,下表說明了這個現象。

缺表

在每種軟體開發的步驟中都有不同的角色負責相關的工作,專案經理負責與客戶溝通並產生需求,所需產生的文件為需求規格書;系統分析由系統分析師根據需求內容規劃出系統操作介面與資料庫設計,產生的文件為系統分析規格書;系統設計由系統設計師負責,產生的文件為系統設計規格書;程式撰寫由程式設計師負責,產生的文件為原始程式碼與可執行程式;測試工作則由測試團隊負責,產生的文件為測試計畫書、測試個案與測試報告書。

每種角色所產生的文件在給下一階段開發人員使用時需經由相關人員共同審查,確認規格書的內容足夠清楚與可被正確了解,可協助相關角色進行本身的工作。

軟體開發文件是給開發團隊使用的,因此文件內容需要持續修正,才有參考的價值,也才能做為團隊溝通的基礎。

最後,軟體系統開發文件內容並沒有固定的撰寫格式,只要能說明清楚即可,文本所撰寫的格式內容也是僅供參考。但還是建議參考一些標準組織所提出的建議範本,例如:

  • CMMI

  • ISO

Previous前言Next2. 目標系統說明

Last updated 6 years ago