作業: 開發願景
這項作業說明如何開發系統的整體願景,這包括應解決的問題、主要的關係人、系統範圍/界線、系統的主要特性以及任何限制。
規範: 需求
目的

這項作業的目的如下:

  • 對待解決的問題取得同意。
  • 指出系統的關係人。
  • 定義系統的界線。
  • 說明系統的主要特性。
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
主要說明

開發「願景」時,請記得下列事項:

步驟
對要解決的問題取得同意

取得問題定義最簡單的一個方法,是將問題寫入,並看看是否每個人都同意。

詢問小組:有什麼問題?

  • 常見的情況是一股腦兒地鑽進定義解決方案,而沒有先花時間瞭解問題所在。寫下問題,並看看是否每一個人都同意其定義。

再度詢問小組:真正的問題是什麼?

  • 找出主要原因,或是問題後的問題。真正的問題通常是隱藏在被認為是問題的問題後面。

不要接受問題的第一個陳述。不斷地問「為什麼」?探討問題的本質。

有時候小組可以專注於建立解決方案的願景,但是這種願景卻使他們很難釐訂真正的基礎問題是什麼。在這種情況下,最好能探索解決方案的好處,然後再嘗試找出那些好處解決的問題。這時您就可以探索該問題是否為組織內的真問題。用來尋找問題後的問題的常用技術,包括集體研討魚骨圖 以及柏拉圖

識別關係人

視開發小組的領域專業,識別關係人也許是很平常,或不尋常的步驟。通常這個步驟只是和決策者、潛在的使用者及其他感興趣的人員進行面談。以下是一些有用的問題:

  • 誰是系統的使用者?
  • 誰是系統的財務採購員?
  • 誰會受系統產生的輸出影響?
  • 誰會在系統已分送和部署後,評估系統及守護系統?
  • 是否有其他內部或外部的系統使用者需求需要處理?
  • 誰會負責維護新的系統?
  • 還有別的人嗎?
  • 真的,還有別的人嗎?

開始開發系統的潛在(或實際)使用者設定檔。有關主要使用者以及他們的環境之起始資訊,應該記載在願景文件中。

定義系統界線

系統界限定義解決方案和環繞解決方案周圍的真實世界之間的邊界。換句話說,系統界限是在說明用於封裝解決方案系統的信封。輸入和輸出形式的資訊會在系統和 生活在系統外圍的使用者之間往返傳遞。系統和外部世界之間的所有互動,都是透過介面進行。

在許多情況下,系統的邊界極為明顯。例如,單一使用者、在 Microsoft Windows® 中執行的小型個人通訊管理程式等的邊界,就定義得很明確。因為這裡只有一名使用者和一個平台。存在使用者和應用程式之間的介面,會包含許多使用者介面對話框,可以讓使用者存取,以輸入資訊至系統,以及任何輸出報告和通訊途徑,供系統用來記載或傳輸結果資訊。

指出要在系統中實施的限制

這裡需要考慮許多不同來源的限制。以下是一份可能的來源和需要詢問的問題清單:

  • 政策方面:是否有任何內部或外部的政策問題會影響可能的解決方案?是否跨部門?
  • 經濟方面:是否適用任何財務或預算限制?是否有任何貨品銷售成本或產品計價注意事項? 是否有任何授權問題存在?
  • 環境方面:是否有任何環境或法規方面的限制存在?合法嗎?會受到其他標準的限制嗎?
  • 技術方面:在技術方面的選擇是否會受到限制?是否會受限於必須使用現有的平台或技術? 是否被禁止使用任何新的技術?
  • 可行性:是否已定義排程?是否受限於只能使用現有的資源? 可以使用外部人力?可以擴充資源嗎?暫時性的?永久性的?
  • 系統方面:解決方案是要建立在現有的系統上嗎?是否必須和現有的解決方案維持相容? 必須支援哪些作業系統和環境?
制定問題陳述

和整個小組一起合作,使用圖表掛板並針對您指出的每一個問題,填入下列範本:

<說明問題> 的問題影響
<受問題影響的關係人>。
其衝擊是 <問題的衝擊為何>。
成功的解決方案會 <列出成功的解決方案的一些主要優點>。

這個範本的目的是要協助您將解決方案/回答和問題/回答區分開來。

範例:

右列問題:未適時及不正確的客戶服務問題解決方案
影響:客戶、客戶支援中心代表及服務工程師。
其衝擊:客戶不滿意、被認為品質低落、員工士氣低及喪失收益。
成功的解決方案會:
提供支援代表即時存取疑難排解資料庫,並適時加速分派服務工程師至確實需要協助的地點。

定義系統特性

依據您的問題陳述中列出的好處,編撰一份您的系統需要的特性清單。摘要地說明特性,並提供一些屬性,以協助定義特性的一般狀態及在專案中的優先順序。

評估成果

您應該在這個階段檢查「願景」,確定您的工作是朝正確的方向進行,但不需要詳細審查。請考慮「願景」文件(核對清單:願景)。



詳細資訊