作業: 導出關係人要求
這項作業說明如何從關係人引出他們希望系統提供的功能要求。
規範: 需求
目的

這項作業的目的如下:

  • 瞭解專案有哪些關係人。
  • 收集有關系統應該履行的要求。
  • 決定關係人的要求優先順序。
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
主要說明

「關係人需求」需要積極地設法取得並收集現有的來源,以取得專案的各個關係人 (客戶、使用者、產品支持者)預期或希望系統包含的「願望單」,以及專案對每項要求抱持的態度資訊。

步驟
決定需求的來源
目的 指出將會成為您的「擴充專案小組」關係人的個體。
決定及判定需求來源的優先順序。 

對於現有的系統而言,這項作業的第一組輸入是被延後的一組加強功能要求,這些要求是在產品生命週期中,收集作為正式的變更要求管理程序的一部分。這項資訊可以提供作為寶貴的開始點,以便收集資料並進一步修正 關係人需求集合。

收集好這項起始資訊之後,請尋求可以代表您的關係人之合作對象、使用者、客戶、領域專家和業界分析師等。請依據個體的知識、通訊技能、可用性和「重要性」等準則,決定您要和哪些個體合作,來收集資訊。這些個體將會成為您的正式專案,即「擴充專案小組」的關係人。一般來說,最好能維持小型的群組 (2-5 人),以便能持續專案的整個持續期間。此外,延伸小組中的人員愈多時,就需要花愈多時間來管理他們,以及確定您有效地使用他們的時間。這些人員並沒有把所有時間都投入專案 - 他們在初始階段和詳述階段,以及稍後的審查階段時,通常會參與一或多個需求收集研討會。

設法瞭解其他人是如何做您打算要做的事情。如果您是要開發軟體產品,這表示要收集競爭對手資訊。如果是要開發內部資訊系統的新版本,則需要排定現場訪察,查看現行系統的使用方式,並瞭解可以改進之處。

這裡可以使用的一個重要來源是使用系統的組織之現有說明。這些資訊可以包括 利用建立商業模型或重新設計商業流程所「產生」的商業模型,或任何其他形式的商業定義。  

收集資訊
目的 決定哪些問題需要取得回答。
收集及記載資訊。 

分鏡腳本作業

可以用來收集資訊的一項實用技術,是分鏡腳本作業,這種方式可以產生分鏡腳本。如需詳細資訊,請參閱準測:分鏡腳本作業

面談

有一種最有效的資訊收集方法是和一組選定的主要關係人進行面談。準則:面談中,有提供一些可以採用的樣本問題及技術。如需有關需要收集哪些資訊以記載關係人需求 的特定建議,請參閱針對工作成果:關係人需求提供的資訊。

問卷調查

這是一種廣泛使用的技術。在進行數次面談之後,您可能會發現某些相同的資訊不斷重現。這類資訊可以收集成為一組具有一些典型回答可以選擇的問題,以傳送給更廣泛的一組關係人。這個方法可以讓您輕易地收集對內含問題提供的回答之正式統計資料。不過,最主要的關鍵是所擬定的問題所取得的統計資料,要能確實提供關係人實際想要的結果。

關係人可能可以透過網際網路回答問題及傳送結果給您。這要比直接面談方式,可以延伸到更多人員,但是您比較無法控制結果。因為您不會在現場直接和回答問卷的人員溝通,以澄清任何問題或誤解。問卷調查可以是很有力的工具,但卻不能取代直接面談。此外,這種方式假設可以預先決定相關的問題,並且您可以將問題用您希望讀者讀到的方式呈現出來。

召開需求研討會
目的: 讓專案小組和專案關係人見面。
向專案關係人收集綜合性的「願望清單」。
依參與研討會的關係人為基礎,排定所收集的問題優先順序。 
準則:

評估成果
目的 比較不同的需求研討會之結果。
確定收集到的是正確資訊。 

如果您召開了多個需求研討會,專案小組更一定要查看所有結果,並且:

  • 確定指定每一個要求的優先順序。
  • 確定有記載要求的來源人員或事項資訊。
  • 記下以及澄清要求之間的不一致。

需求研討會的結果必須在面談或延續階段作業中,呈現給一組選定的客戶或使用者。在此階段作業中,您要指出是否有任何問題需要澄清,因而表示您要指出需要完成的作業,並指派負責那些作業的人員。

詳細資訊