需求分析與誘導（Requirements elicitation and analysis）

1. 訪談 (Interviewing)

訪談是多數需求工程流程中的核心活動，開發團隊透過向利害關係人提問來獲取現有系統與未來新系統的相關需求。

• 封閉式訪談 (Closed interviews)： 讓利害關係人回答一組預先定義好的特定問題。
• 開放式訪談 (Open interviews)： 沒有預設議程，開發團隊與利害關係人針對各種議題進行探索性討論，以更深入了解他們的需求。
• 實務應用： 實務上通常會混合使用這兩種方式。訪談非常適合用來獲取對使用者工作內容的整體理解。然而，因為使用者很難憑空想像系統未來的樣貌，單靠訪談容易遺漏重要資訊，且領域專家經常使用特定術語（jargon），容易造成工程師的誤解，因此必須搭配其他技術使用。

2. 民族誌 / 觀察法 (Ethnography)

許多軟體系統失敗的原因在於其需求忽略了社會與組織因素的影響。民族誌是一種觀察技術，分析師會將自己沉浸在系統未來要運作的工作環境中，觀察人們日常的實際工作任務。

• 發掘隱性需求： 民族誌的價值在於能發掘出反映人們實際工作方式的「隱性」需求，而非僅僅依據組織定義的正式流程。例如，航空管制員可能會因為警報系統過於敏感而將其關閉，轉而依賴其他策略。
• 發掘協作需求： 它能敏銳捕捉到團隊合作與「感知他人活動」的需求（例如觀察同事的工作量來調整自己的策略）。
• 結合雛型設計： 民族誌經常與系統雛型設計（Prototyping）結合使用，透過觀察結果來引導雛型的開發，同時也能針對觀察中發現的問題在下一次的評估中進行驗證。

3. 故事與情境 (Stories and Scenarios)

人們通常難以直接說出抽象的系統功能需求，但很容易對真實生活中的互動例子產生共鳴。

• 故事 (Stories)： 以敘事文本的方式撰寫，提供系統使用的高階描述（Big picture）。它的優勢在於任何人都能輕易理解，非常適合作為引導討論的起點，甚至可以放在共享平台上讓廣泛的使用者群體提供回饋。
• 情境 (Scenarios)： 情境是從故事發展而來的具體互動範例。它通常是以結構化的方式呈現，內容包含：情境開始時的初始假設與狀態、正常的事件流程、可能發生的錯誤及其處理方式、其他同時進行的活動，以及情境結束時的系統狀態。
• 敏捷開發的應用： 在敏捷方法（如極限程式設計 XP）中，廣泛使用的使用者故事 (User stories) 即是情境的應用。客戶與開發團隊將需求寫在故事卡上，接著分解為具體的開發任務並進行優先排序。

4. 标杆法 (Benchmarking / 基准分析法)

标杆法是一种通过与行业内现有的、优秀的竞争对手或相似系统进行对比，从而获取和定义需求的方法。

• 核心概念：不要闭门造车。如果市场上已经有成熟的同类产品或最佳实践（Best Practices），开发团队应该系统性地分析这些“标杆”，了解它们的功能、性能指标和用户界面。
• 运作方式：
  • 识别标杆：找出市场上最受欢迎或评价最高的竞品（例如，如果您要开发一个电商系统，可以拿淘宝或亚马逊作为标杆）。
  • 评估与对比：系统性地测试这些标杆系统，记录它们的优点和缺点。
  • 提炼需求：将标杆系统中的优秀功能转化为新系统的基准需求（Base requirements），并针对标杆系统的不足之处提出改进或创新需求。
• 适用场景：适用于开发商业软件产品、SaaS 应用，或当客户的目标是“做一个比 XXX 更好的系统”时。它特别有助于明确非功能性需求（例如：系统响应时间必须比竞品快 20%）。

5. 学徒法 (Apprenticeship)

学徒法是情境访谈（Contextual Inquiry）中的一种核心技术。它重新定义了分析师与用户之间的关系。

• 核心概念：分析师（需求工程师）扮演“学徒”（Apprentice）的角色，而终端用户扮演“师傅”（Master）的角色。师傅在真实的工作环境中执行日常任务，学徒在旁边观察、学习并适时提问。
• 运作方式：
  • 在情境中学习：分析师不是在会议室里问“您平时怎么工作？”，而是直接坐在用户的办公桌旁，看用户如何操作现有的系统或处理业务。
  • 师徒互动：当用户执行某个特定动作（例如，在一个表格旁贴上便利贴）时，学徒会立刻提问：“师傅，您刚才为什么要把这个数据抄在纸上？” 师傅会基于当下发生的动作进行解释。
• 优点：
  • 发掘隐性知识（Tacit Knowledge）：用户往往对自己烂熟于心的工作流程习以为常，在传统会议访谈中根本想不起来提（正如参考资料中指出，领域专家经常觉得某些知识太基础而不值得一提，这容易导致需求遗漏）。学徒法能有效捕捉这些隐秘细节。
  • 避免脱离实际的假设：让分析师真正理解用户的痛点和实际工作环境。
• 与资料中“民族志/观察法”的联系：学徒法在理念上与参考资料中提到的**民族志/观察法（Ethnography）**非常相似。参考资料指出，民族志要求分析师“沉浸在系统未来要运作的工作环境中”，去发掘那些反映人们实际工作方式的“隐性”需求（例如空管员觉得警报太吵而关掉它）。学徒法可以看作是这种观察法的一种高度互动和结构化的具体实践形式。

学徒法在精神上高度契合资料中强调的沉浸式观察（Ethnography）和发掘隐性需求的理念。而标杆法则通常作为资料中提到的“软件发现与评估（Software discovery and evaluation）”或竞品分析过程的一个自然延伸。

6. 使用案例 (Use Cases)

使用案例是一種透過圖形模型與結構化文本來描述系統與其使用者（或其他系統）之間互動的方法，是統一塑模語言（UML）的基礎功能。

• 核心元素： 它能識別出參與互動的參與者（Actors，通常以火柴人表示，可為人類、外部硬體或其他系統）以及互動的任務（以橢圓形表示）。
• 細節補充： 每個使用案例都代表一個獨立的外部互動，通常會附上詳細的文字描述。為了補充更詳細的流程，設計師會搭配 UML 的順序圖（Sequence diagrams）或狀態圖（State charts）來展示參與者與系統物件之間的具體訊息傳遞與互動序列。

7. 觀點分析 (Viewpoints)

大型系統會有非常多具有不同背景的利害關係人。為了簡化複雜的需求分析，可以將利害關係人的資訊進行分組與結構化。

• 運作方式： 將具有共同特徵的利害關係人（如終端使用者、管理者）或外部系統約束視為一個「觀點」（Viewpoint），並將相關的需求收集到該觀點中。這有助於明確辨識哪些人可以提供特定資訊，並更有系統地組織需求以進行分析。

8. 系統雛型設計 (System Prototyping)

雛型是軟體系統的早期可執行版本，主要用來展示概念、嘗試設計選項，並幫助利害關係人釐清問題。

• 引出與驗證需求： 透過讓使用者直接與雛型系統互動，他們可以發現系統的優缺點，並提出原本沒想到的新需求；同時，這也能揭露原始需求規格中的錯誤或遺漏。雛型設計是一種有效「預期變更」的策略，能大幅減少系統交付後才提出的修改要求。

需求分析過程中的常見挑戰： 在使用上述方法時，分析人員必須意識到需求分析是一個充滿挑戰的過程。利害關係人往往不知道自己真正需要什麼，或者會提出不切實際的要求；他們容易使用特定領域的行話；不同部門的利害關係人可能會提出相互衝突的需求；甚至組織內部的政治因素或權力鬥爭也會干預需求的制定。因此，需求分析通常需要召開跨部門會議來進行優先排序與妥協協商（Requirements prioritization and negotiation），才能產出最終的需求文件。