---
# System prepended metadata

title: 深出淺入物件導向 <br /> 需求分析
tags: [需求分析, OO設計, OOA&D, 工程師心法, 深出淺入物件導向]

---

# 深出淺入物件導向 <br /> 需求分析

<center>
  <img src="https://i.imgur.com/0wECZOs.jpg" alt="Cowman" style="border-radius:5px; box-shadow:5px 5px 10px rgba(0, 0, 0, 0.4)" border="10"/>
</center>

<center> 
<font color"gray">
Photo by 
<a href="https://unsplash.com/@youxventures?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">You X Ventures</a>
on 
<a href="https://unsplash.com/">Unsplash</a>
</font>
</center>

<br/>

> *會讀這本書是因為一直想學好設計模式，大神給的方向是先從物件導向開始著手，先學會基本的再來學習設計模式。<br/>
這篇算是看書所寫出來的心得筆記，也是我第一次嘗試寫這種東西比起實作功能更注重於程式設計師的心法，有許多是從中節錄出來的～<br/>
每個人了解的可能略有出入，如果想了解更透徹歡迎透過下方資訊去購入此書。* 

<br/>

```
書名：深入淺出物件導向（Head First Object-Orient Analysis & Design）
ISBN：978-986779-499-4
```

## 前導
完整的需求分析在此書的2至4章內，整本書都是照著第一章成就偉大軟體的三步驟所進行的，第1章則是所有章節的濃縮，題外話想學怎麼閱讀可以去看**如何閱讀一本書**。

在你開始動手實作這個功能或是開發這程式時，先問你自己個問題對你來說**優秀的程式**應該具備怎麼樣的**特點**？

> - 是使用者以各種光怪陸離的操作行為使用你所設計的程式，卻能達到使用者的預期?
> - 具備OO特色，沒有一堆重複程式碼，物件運作得宜。
> - 使用廣泛使用流行的設計模式、原則，並保持物件鬆散耦合更易於重複使用，不必重複造車輪。


其實真正優秀的軟體理想上是達成使用者的目的，設計良好且易於擴展、維護及重複利用。

那想達成此成就的步驟就是書中所提到的，偉大軟體的三步驟。
> 1. 確認你的軟體做客戶要他做的事。
    <br/>-> 此步驟確保應用程式式做它應該先做的事，應多著力於收集需求與分析。
> 2. 應用基本OO原則，增加軟體的彈性。
    <br/>-> 找出任何重複的程式碼，並確認你在使用良好的OO編程技術。
> 3. 努力達成可維護、重利用的設計。
    <br/>-> 運用設計模式與OO原則確保今後幾年裡安全無事。

接著我們就照著此步驟看下去吧！

## 需求分析
### 那麼，什麼是需求呢？
> 需求是單一的需要，詳細說明特定產品或服務應做的事。你的系統必須正確動作且滿足特定的需求。

那談需求時，最好**讓客戶自己說**。仔細聆聽，注意系統需要做什麼；稍後再整理系統要如何做那些事，接著讓我們看下面對話例子吧！

- Andy：我想要回到家冷氣就自動打開。
- You：那麼是要離開時關閉冷氣嗎？
- Andy：是的我想要在我離開時關閉冷氣，這樣就不耗電了，非常完美！這就是我想要的智慧住宅。

### 接著建立需求清單

<center>
    <b> Andy智慧住宅需求清單 </b>
</center>

---
```
1. 冷氣預設25度，這恰好是人體最適合的溫度。
2. 門上要有距離感測器，距離有變化時冷氣是關的必須開啟，冷氣是開的必須關閉。
```

### 撰寫使用者案例

<center>
    <b>Andy 門做的事</b>
</center>

---
```
1. Andy開門。
2. 門感應到距離不一樣，觸發搖控器開關。
3. 冷氣開啟。
4. Andy進來房間。
5. Andy辦事。
6. Andy辦完事，開門。
7. 門感應到距離不一樣，觸發搖控器開關。
8. 冷氣關閉。
```

當你寫下這些步驟時，就是在撰寫**使用者案例（use case）**。

使用案例是捕捉新系統或軟體變更潛在需求的技術。使用案例，提供一個或多個**使用情境（scenario）**，傳達系統如何與終端使用者或其他系統**互動**，完成**特定目標**。

使用者案例目的不在於說明你如何撰寫程式碼通常是**步驟清單**，而**使用案例圖**則是**以視覺化的方式顯示使用者案例**。你還是得另外思考，如何將使用者案例付諸行動。
若你的使用案例把焦點放在程式碼層次的具體細節，對任何**非程式人員**是沒有用的。它應該是**簡單**、**日常的生活語言**所構成的。假如你使用太多編成術語或技術行話，你的使用案例可能會太過細節化而失去作用。

**一個好的使用案例，分成三個部分。**

1. **清楚的價值**
    - 假如使用者案例無助於客戶達成目標，這個使用者案例便沒有任何價值。
2. **起點與終點**
    - 每個使用案例都必須有明確的**起點**與**終點**，然後要有**條件**指名流程已完成。
3. **外部啟動者**
    - 每個使用案例由**外部啟動者**開啟，可能是系統外的任何事物。

**從第一步到最後一步通過使用案例的完整路徑，稱為使用情節。大部分的使用案例有一些不同的使用情節，但總是共有相同的使用者目標。**

## 總結
有時候，需求變更揭露出關於系統你所不知道的問題。也會因應不同需求而產生不同的使用情境而變更使用案例，所以任何時候你的使用案例改變時，你必須回頭去檢查你的需求。變更是常態，隨著你每次的實作系統總是隨之改善。
> 但...你我都知道，這是理想中的理想，有時需求變更總是伴隨著流星雨，你我在神的面前也只是個無力的渺小的存在。
> >引用 <a href="https://ithelp.ithome.com.tw/articles/10198394">隕石開發法</a>

###### tags: `OOA&D` `工程師心法` `需求分析` `OO設計` `深出淺入物件導向`
