# 技術文件相關工作內容

## Pre-sales
>流著業務員血液的工程師，負責與客戶溝通了解需求

1. 抽象需求轉為具象需求
了解產品主要核心概念與需求，撰寫RPF(Request For Proposal)需求建議書，這份RFP通常也會伴隨合約成為合約的一部分，**基本上有了RFP才能報價**！

#### RFP格式範例：

|大類|子類|功能|說明
|-|-|-|-|
|播放器|暫停|按下後暫停|按下暫停鍵後停止播放內容，切換為播放圖示，再次按下播放圖示，恢復播放並切換為可暫停圖示。

## SA（System Architecture）
- 太深了，暫略
## System Analysis 系統分析
### Use Case Diagram 用例 User Story ?
Use Case Diagram主要是描述一個系統或類別提供給外界之交互作用者的功能。簡單來說就是說明一個系統的功能及其使用者。[參考資料](https://dotblogs.com.tw/jimmyyu/archive/2010/01/18/use-case-diagram.aspx)
* Actor 角色定義與描述。
* Use Case：使用案例描述系統要完成的成果，而不是如何進行，通常Use Case是一個動作，例如：儲存資料、加入會員等等
* Use Case 不做的事情
1. Implementation details：不要描述實作細節，只講概要功能就好，例如不要說明資料將被存到Oracle資料庫，而說資料將被儲存就好。
2. GUI Information：不要講UI上的內容，例如按下『存檔』按鈕，避免到時候畫面作多國語言時，我們還要將Use Case改成多語內容。
3. Internal processing unrelated to a stakeholder request：不要講與使用者無關的系統內部作業，這一點跟第一項很像，就是不用講過多的邏輯內容在裡頭。
4. Non-functional requirements：不要講非功能性需求，例如系統每個操作要在2秒內回應，同時上線人數要達3000人等。

### UML（Unified Modeling Language）
- 太深了，暫略

### Mockup（視覺稿)
[Prototype、Wireframe、Mockup ](https://blog.akanelee.me/posts/276909-beginners-of-prototype/)

## SD (System Design)
### 1. Testing Plan
一個測試計劃應包括：產品基本情況調研、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審、結果.. 等。
測試計劃是整個測試的流程，不是一個很細項的東西，而是一個大概的流程，從測試環境的配置，測試的目的，要測哪些功能，方向等，都先記錄下來，已便以後回來再來看這些資訊。
1. 測試範圍
2. 時間表
3. 測試方法
4. 資源
5. 風險和突發事件
6. 誰來測試
7. 質量
… 等。

[如何制定 Test plan](https://kkboxsqa.wordpress.com/2013/10/08/%E5%A6%82%E4%BD%95%E5%88%B6%E5%AE%9A-test-plan/)
### 2. Issue Tracking

[為什麼必須使用 Issue Tracking System 管理專案？](http://blog.xdite.net/posts/2012/03/26/issue-tracking-project-management-agile)
Issue Tracking system ，顧名思義就是紀錄、追蹤 問題的系統。
* 一個地方可以透明的列出所有需要被執行的項目 (Issue List)
* 一個地方可以列出階段內需要被執行的項目 ( Issue Milestone )
* 一個可以記載 內容，狀態、分派者、執行者，且讓大家可以討論執行項目細節的地方。(Issue Ticket)

> * 主題
> * 內容
> * 狀態 (新建立、已指派、已解決、已回應、已結束、已擱置…etc)
> * 優先權 (正常、重要、緊急、輕微、會擋路…etc.)
> * 發生日期
> * 希望解決日期
> * 實際解決日期
> * 被分派給誰
> * 附件
> * 觀察者
>
### 3. DB Schema
- 略

### 4. Front-End / Backend-End 定義