原文連結:要件定義~システム設計ができる人材になれる記事 - Qiita
本篇介紹的主題是「需求定義到系統設計」,從為什麼需要需求定義,到如何進行這段流程,再接著說明基本設計的三個步驟,透過一步步解說,到最後完成系統設計圖。
文章架構如下:
- 需求定義的必要性
- 需求定義的目的
- 確定需求定義的過程
- 在需求定義中決定的事項
- 基本設計(畫面設計・功能設計・資料設計)的作法
- 畫面設計(UI 設計)
- 功能設計
- 資料設計
- 資料的具體內容
- 資料庫設計
- 資料的流向(Data Flow)
- 進一步推進基本設計
以下正文開始。
由於收到許多詢問,這裡提供需求評估~設計相關 Udemy 課程的 Coupon。
歡迎多多利用&給予評價 m(_ _)m
■入門編:
【入門】システム要件定義と基本設計(実践ワークで理解する上流工程の進め方)
■應用編:
【超実践】ビジネス要件分析・基本設計・詳細設計をやり抜く実践ワーク講座
前言
這是由 DEGISAKU 株式會社提供的程式設計文章。
這次要討論的是與需求定義・系統設計相關的主題。
在學習程式設計時,是否曾經有過這樣的經驗呢?
「即使學習也做不出產品」
「到底開發是怎麼進行?」
「需求定義是什麼?」
為了解決這些困擾,首先讓我們瞭解開發過程的整體概念。
請參考下圖的「軟體開發過程」,
我們平常在學習程式設計的階段,將對應到 「實作」的部分。
換句話說,在展現程式設計能力之前,還存在四道壁壘需要克服。
軟體開發過程,由左至右分別是:
- 企劃 > 業務設計 > 需求定義 > 設計 > 實作(程式設計) > 測試 > 發布 > 維護
因此,本文將針對開始實作(程式設計)之前,必須進行的「企劃 > 設計」過程依序做介紹。
內容將特別著重於,工程師必須理解的「需求定義」和「設計」階段。
此外,據說在整個開發過程中,大約有二到三成的時間用於實作(程式設計);另一方面,需求定義和設計等上游流程,約占總時間的五成。
這意味著,擁有需求定義和設計能力的人,必然能提高對開發專案的貢獻度。藉由這個機會,讓我們好好學習這些技能,來擴大發展的機會吧。
本文的章節安排如下:
- 需求定義的必要性
- 确定需求定義的過程
- 在需求定義中決定的事項
- 基本設計的建立方式
- 進一步推進基本設計
- 總結
※ 我在 SNS 上也有分享各種訊息,若閱讀本文感覺不錯,也歡迎關注 Twitter 帳號「Saku731」 。
需求定義的必要性
需求定義的目的
在系統開發專案中,通常分成兩類主要參與者:
- 「製作」系統的人(開發者)
- 「使用」系統的人(委託者)
如果是建立自己想要的系統,那麼在腦海中應該已經有了完整概念,因此不會有太大問題。但在更多情況下,開發工作會是透過「委託者⇒開發者」來委託完成。
而在這種情況,如果不明確化委託者腦中的想法,開發者將不知道該從何做起。因此,需求定義的目的就是為了能夠與委託者溝通。
試著用日常生活中的例子來思考看看。
當覺得口渴時,您是否會提出「幫我買飲料來!」的要求?
如果沒有表達「幫我買杯咖啡」,或更具體的「幫我買杯微糖熱咖啡,不要罐裝,要瓶裝的!」,可能無法如願得到想要的咖啡。
系統開發也是如此。
需求定義的目標,就是為了明確達成「該做什麼才能滿足需求?」的共識。
也就是說,需求定義 = 在交付時可以明確確認「這樣 OK!」的具體先決條件,請務必理解這點。
確定需求定義的過程
瞭解需求定義的目的之後,接下來,讓我們來理解完成需求定義的三個階段:
- 要望(ようぼう):「如果有這樣的系統就好了」的想法
- 要求(ようきゅう):希望在系統實現的粗略功能清單
- 要件(ようけん):雙方都同意的具體功能清單與實作方法
「要望」>「要求」>「要件」分別表示不同程度或類型的需求。
可參考下圖,由外到內依序代表:
- 要望:比較隨意的願望或期望
- 「如果有這樣的系統就好了」
- 要求:強制性、正式的需求
- 「希望實現這樣的功能」
- 要件:特定的條件、規格或要求
- 「來實現這個功能吧」
這三個階段的過程,需要透過「審查」和「建議」來溝通,按照順序整理如下:
- ①要望(期望):需要解決的問題(委託者的任務)
- 現有的問題
- 目標(本應達到的狀態)
- 現況與目標之間的差距(需要解決的問題)
- ②要求(正式需求):想要在系統中實現的功能(委託者的任務)
- 專案背景(需要解決的問題)
- 解決問題所需的系統概述
- 具體想要實現的功能清單
- ③評估:思考實現需求的可行性(開發者的任務)
- 開發在技術上是否可行?
- 預算大約需要多少?
- 交付期限差不多是何時?
- ④提議:將討論結果反饋給委託者(開發者的任務)
- 可以實現的功能
- 請求金額
- 可以交付的日期
- ⑤要件(特定條件的需求):雙方達成共識的決策事項(委託者・開發者協商決定)
- 在系統中實現的功能清單
- 交付期限、收費金額的參考資訊也可能包含在其中
在需求定義中決定的事項
在瞭解流程之後,接下來將粗略介紹需求定義中決定的事項。
這裡使用 3W(Why・What・How)來整理排列,將有助於清楚理解:
- Why:系統開發目的(要望)
- 現有的問題
- 目標(本應達到的狀態)
- 現況與目標之間的差距(需要解決的問題)
- What:需要解決什麼問題
- 系統導入後的業務流程
- 功能需求
- 想要實現的功能清單
- 非功能需求
- 處理速度、安全性等
- How:具體的使用難易度與實作方法(類似系統設計的任務)
- 基本設計
- 畫面設計(UI 設計)
- 功能設計
- 資料設計
- 詳細設計
- 類別圖(Class Diagram)、序列圖(Sequence Diagram)
- 系統架構(Systems architecture)
- 實現各部位的技術等
- 基本設計
基本設計(畫面設計・功能設計・資料設計)的作法
對於在需求定義中決定的事項,可能因此產生繁雜的印象,但請不用擔心。
在 What 部分(業務流程、功能需求和非功能需求),通常是由開發團隊中的「業務人員」或「銷售工程師」來處理。
因此,我們將深入探討工程師在 How(設計)方面發揮其能力。其中,扮演關鍵角色的基本設計,將是本文的討論重點。
如上所述,基本設計包括「畫面、功能和資料」的設計,只有當這些內容都到位後,程式設計師才能開始著手軟體開發。
- 畫面設計(UI 設計)
- 可以在各畫面做什麼?
- 顯示資訊(文字、圖像等)和佈局
- 將上述內容統整到畫面轉換圖(Screen transition diagram)
- 功能設計
- 背後執行(功能名稱和處理內容)
- 處理需要的資料、資料的取得來源(從畫面輸入、從 DB 取得等)
- 將處理後的資料傳送目的地(畫面顯示、儲存到 DB 等)
- 資料設計
- 資料的具體內容
- 資料庫設計
- 資料的流向(Data Flow)
畫面設計(UI 設計)
首先,必須優先決定的部分是畫面設計(UI 設計)。
使用者透過畫面(UI)來使用軟體,因此在「畫面的易用性」這點意見一致,將是通往專案成功的捷徑。
如前面所述,畫面設計包含以下項目:
- 可以在各畫面做什麼?
- 顯示資訊(文字、圖像等)和佈局
- 將上述內容統整到畫面轉換圖(Screen transition diagram)
)
當整理到這一步時,即可想像出系統的具體成品,這就是為什麼要先進行畫面設計的原因。
功能設計
完成畫面設計(UI 設計)後,接著將設計系統要實現的功能。
功能設計是確定「背後執行的流程和所需資料」的階段。
需要決定的事項,如前面所述:
- 背後執行(功能名稱和處理內容)
- 處理需要的資料、資料的取得來源(從畫面輸入、從 DB 取得等)
- 將處理後的資料傳送目的地(畫面顯示、儲存到 DB 等)
接下來,試著粗略設計畫面轉換圖中出現的各頁面功能。
透過這個方式,無論是誰都能夠藉此想像應該寫什麼樣的程式。構成系統的各個部分也變得清晰,能更容易在團隊內部進行分工。
作為功能設計的最後一步,便是將畫面設計和功能設計連接起來。藉此可視化使用者操作與背後執行的處理,在畫面之間的關係。
全部統整後如下圖所示。
※ 這部分資料量較大,因此可放大感興趣的部分查閱。
資料設計
最後是資料設計。
準備工作到這一步,終於要開始進行資料設計。
如上所述,需要決定的事項有三個:
- 資料的具體內容
- 資料庫設計
- 資料的流向(Data Flow)
資料大致上可分為四種類型。
接下來,將要設計這四種資料類型,在系統內的流向是如何。
- 在程式「輸入」資料(參數)
- 使用者在 Web 畫面輸入資料
- 從資料庫讀取資料
- 從程式「返回」資料(返回值)
- 在 Web 畫面顯示的資料
- 在資料庫儲存的資料
資料的具體內容
在這個階段,將會具體化之前抽象定義的資料,例如 「會員資訊」 等。
此外,如果要達到實務水平,就必須瞭解 「正規化」 的相關知識。
※ 如果感興趣,可參考相關文章:**正規化の要点を理解する**。
- 會員資訊
- 姓名
- 姓名的片假名讀音
- 電子郵件地址
- 密碼
- 商品資訊
- 商品名稱
- 詳細説明
- 商品圖像 URL
- 類型
- 製造商
- 價格
- 評價
- 購買紀錄
- 會員 ID
- 商品 ID
- 購買日期
- 購買數量
資料庫設計
在明確資料內容之後,再來將進行資料庫設計。
首先要記住的是,到目前為止,我們雖然稱資料為「會員訊息」、「商品訊息」、「購買歷史紀錄」等,但在資料庫設計中,將會用「Table(表格)」來表示。
※ 例如:「會員訊息表格」、「商品訊息表格」、「購買紀錄表格」。
在資料庫設計中,需要執行三項任務:
- 區分表格的角色為「主表格」和「紀錄表格」
- 整理表格之間的參考關係
- 將參考關係繪製成 ER 圖(Entity-Relation Model = 實體關係圖)
※(註)「主表格」和「紀錄表格」等稱呼是作者自身觀點。
接下來,按照以下標準來區分每個表格的角色:
- 主表格:包含基本訊息(其他表格會參照的資料)
- 會員訊息表格(以下簡稱為「會員主表格」)
- 商品訊息表格(以下簡稱為「商品主表格」)
- 紀錄表格:包含系統在運行中累積的資料
- 購買紀錄表格
下一步,使用箭頭表示參考來源與參考目標,整理「表格之間的參考關係」。
同時,也明確標明是「根據使用者操作產生的資料」,將有助於理解資料流動,而不易有所遺漏。
※ 有時也會透過網路從外部引入資料,如:天氣預報 API 等。
最後,完成的 ER 圖即為資料庫設計圖。
※ 有關繪製 ER 圖的詳細內容,可參考這篇文章:若手プログラマー必読!5分で理解できるER図の書き方5ステップ
資料的流向(Data Flow)
最後,將 「資料庫與畫面轉移圖之間的關係」整理完成後,即可看到系統整體面貌「畫面設計×功能設計×資料設計」。
每個程式都將基於這份設計圖來撰寫。
透過反覆練習這段過程,將能夠清楚呈現整體面貌。
進一步推進基本設計
若能夠理解以上內容,即可進行基本設計,並且已足夠開發自己的產品。遇到不理解的部分,可以在查詢資料的同時,繼續進行編程。
開發完成後,如何設定伺服器為公開,Qiita 上已經有發表許多相關文章,這篇文章可供參考:**【20分でデプロイ】AWS EC2にDjango+PostgreSQL+Nginx環境を構築してササッと公開**
另外,在實際的開發現場,若是不進行詳細設計,將無法向程式設計師提出明確的要求。
在充分理解本文內容後,請先學習以下內容:
- 建立類別圖和序列圖
- 決定系統架構
- 決定實現架構各部位的技術
儘管如此,最近技術變革非常迅速,在詳細設計過程中可能已出現新技術的情況發生。
根據敏捷開發的方式,即可透過「在詳細設計過程中做出決策」來繼續進行。
※ 根據公司內部的開發方針進行即可。
最後
在團隊開發現場,角色分工是前提。
確實描繪整體樣貌,明確訂出「是誰、要做什麼」,以便開發順利進行。
若是覺得這篇文章有所幫助,也歡迎關注我的 Twitter 帳號「Saku731」 。
(後記)
我撰寫了一篇,關於使用 Python 進行系統開發所需技能的文章。可參考以下內容:
- 瞭解系統開發所需技能的整體概況:Pythonでゼロからでもサービス開発・公開できる学習ロードマップ
- 使用 Django 進行系統開發的一系列步驟:Django(Python)でシステム開発できるようになる記事_入門編
15th鐵人賽目錄傳送門:https://ithelp.ithome.com.tw/users/20135558/ironman/6290