1GB/TXXXXX—XXXX/ISO/IEC26551:2016系統與軟件工程產品線需求工程的工具和方法本文件在軟件與系統產品線需求工程的工具和方法的范圍內：——為軟件和系統產品線以及相關成員產品的需求工程提供特定的術語和定義；——定義過程組及在產品線需求工程中執行的過程（這些過程根據目的、輸入、任務和輸出進行描述）；——定義方法能力，以支持每個過程的定義任務；——定義工具能力，將任務或定義的方法能力自動化或半自動化。本文件關注的是產品族而不是單系統的需求工具和方法的過程和能力。本文件不適用于實物制品。相反，系統級制品和軟件生存周期制品，如需求文件、架構數據、驗證計劃、行為模型等，都使用本文件方法和工具生成。對于系統的軟件組件，本文件可用于處理產品線的系統要素和用于處理產品線的軟件要素（如有）。產品線過程在不同層次的產品中是遞歸的。2規范性引用文件本文件沒有規范性引用文件。3術語和定義下列術語和定義適用于本文件。3.1應用需求資產applicationassetsinrequirements在應用需求工程過程中產生的特定于應用的制品，例如應用需求規格說明（3.4）和應用需求模型。3.2應用需求獲取applicationrequirementselicitation識別與應用相關的利益相關方，獲取應用特定需求并綁定適當的變體的子過程。3.3應用需求分析applicationrequirementsanalysis理解所有應用特定需求（3.9）的子過程，通過建模來檢查不正確和不一致的應用需求，然后分析和協商不能通過領域需求來滿足的應用需求。3.4應用需求規格說明applicationrequirementsspecification文檔化應用特定需求（3.9）并將其與領域需求規格說明（3.13）集成的子過程，領域需求規格說明的變體被綁定。3.5應用需求驗證和確認applicationrequirementsverificationandvalidation確認應用特定需求（3.9）的一致性和可行性，并確保綁定的變體滿足特定產品的需求的子過程。2GB/TXXXXX—XXXX/ISO/IEC26551:20163.6應用需求管理applicationrequirementsmanagement管理應用需求的可追溯性和變更的子過程.3.7方面aspect在產品線工程過程組和任務中，能關聯專門方法和工具的特定因素。3.8資產建議assetproposal包括主要資產（功能域和所有應用的高層級通用與可變特征）的制品，這些資產可包含在產品線中，并具有量化的成本和收益，以及評估結果。3.9應用特定需求applicationspecificrequirements特定于應用的需求，或者領域需求中未涵蓋的需求。3.10領域需求資產domainassetsinrequirements在領域需求工程中產生的可重用制品，如資產建議（3.8）、領域需求規格說明（3.13）和領域需求模型。3.11領域需求獲取domainrequirementselicitation識別領域利益相關方對產品線的原始需求的子過程。3.12領域需求分析domainrequirementsanalysis對領域需求建模的子過程，以便分析和檢查需求中產品線的共性和可變性。3.13領域需求規格說明domainrequirementsspecification根據領域分析結果文檔化產品線領域需求的子過程。3.14領域需求驗證和確認domainrequirementsverificationandvalidation確認領域需求正確、一致和完整的子過程。3.15領域需求管理domainrequirementsmanagement管理領域需求及與其相關的領域和應用制品的可追溯性和變更的子過程。3.16功能域functionaldomain通常一起使用的分類功能。3.17產品計劃productionplan描述如何使用領域資產開發產品線成員產品。3.18需求可追溯性requirementstraceability領域和應用需求各自可追溯性以及它們之間的可追溯性。3.19構造texture3GB/TXXXXX—XXXX/ISO/IEC26551:2016架構性構造architecturaltexture實現產品線應用的通用開發規則和約束條件的集合。3.20需求可變性variabilityinrequirements需求工程的外部和內部可變性。4產品線需求工程參考模型產品線需求工程的方法和工具應支持領域和應用需求工程過程的系統管理和交互。還需要與其他產品線工程生存周期過程充分集成，以實現所有需求制品與相關的設計、實現和測試制品之間的可追溯性。產品線需求工程實踐、方法和工具按照聚焦于產品線需求工程的框架進行描述(見圖1)。產品線范圍界定通過與領域和應用需求工程的持續交互來創建和維護產品線范圍，從而引導和控制產品線的所有工作。領域需求工程用于：——將產品線范圍界定中定義的特征分解為原始需求和從利益相關方及領域專家獲取的其他需求和派生需求；——利用需求可變性分析領域需求；——對領域需求的靜態和行為結構進行建模和仿真；——文檔化領域需求規格說明，這些需求能夠被產品線的特定成員產品綁定。隨著產品線的復雜性增加，可變性的復雜性也相應增加。將可變性與領域需求工程分離可緩解這個問題。獨立定義需求可變性有助于清晰理解工具和方法所需的必要功能，并幫助選擇支持產品線需求工程的工具。應用需求工程用于：——識別領域特征和特定應用的特征之間的差距；——重用資產庫領域需求，并獲取應用特定需求；——通過綁定領域可變性模型并添加特定應用的可變性來定義應用可變性模型；——分析并文檔化應用特定需求；——為產品線范圍界定和領域需求工程提供反饋，以促進產品線的發展。圖1產品線需求工程參考模型劃分為五個過程：產品線范圍界定、領域需求工程、需求工程可變性管理、需求工程資產管理和應用需求工程。每個過程都劃分為子過程，以解決技術管理問題，每個子過程都根據以下屬性進行描述：——子過程的標題；——子過程的目的；——產生輸出的輸入；——獲得輸出的任務；——子過程的輸出。4GB/TXXXXX—XXXX/ISO/IEC26551:2016圖1產品線需求工框架產品線范圍界定定義了成員產品及主要（外部可見）特征、從經濟角度分析產品，并控制和計劃產品線及產品的生產。這一過程的主要結果是資產建議。資產建議包括產品線的主要資產（功能域和高層級通用和可變特征）及量化的成本和收益，以及產品線開發預期的投資回報率。可提出多個資產建議，以找出最優的產品和資產集合。領域和應用需求工程從資產建議中定義的特征開始。產品線范圍界定完成以下工作，并定義支持工具和方法的能力：——產品范圍界定，確定產品組合定義，并為向客戶或市場發布特定應用提供路線圖；——領域范圍界定，識別并限制功能域范圍，以提供足夠的重用潛力；——資產范圍界定，識別可重用資產，評估成本和效益以證明產品線啟動的合理性。領域需求工程從使用產品線范圍界定的結果開始。全面地獲取產品線的原始領域需求，并構建包括可變性模型的原始需求規格說明。向組織的業務管理過程組提供關于特征集和產品路線圖中所需變更的整體反饋。領域需求工程文檔化領域需求規格，以便之后在領域設計和應用需求工程中使用。領域需求工程完成以下工作，并定義支持工具和方法的能力：——領域需求獲取，獲取原始領域需求和這些需求的預期變化；——領域需求分析，識別功能性和非功能性需求以及這些需求的可變性；——領域需求規格說明，根據分析結果文檔化領域需求；——領域需求驗證和確認，確認領域需求是一致的、可行的，并且確保產品線所有產品需求都能被充分理解；——領域需求管理，為需求工程的雙重性質，即領域和應用需求工程，提供管理服務。需求工程可變性管理應與領域需求工程并行進行，因為可變性模型是隨著領域和應用需求一起逐漸澄清和修改的。可變性建模作為領域需求獲取的一部分開始，并在整個產品線生存周期中不斷發展。該過程負責明確地文檔化外部可變性的可變性模型。隨著領域需求工程活動的進行，一些額外的內部可變性可能會被添加到可變性模型中。需求工程可變性管理完成以下工作，并定義支持工具和方法的能力：5GB/TXXXXX—XXXX/ISO/IEC26551:2016——文本需求可變性，用自然語言表達和文檔化需求可變性，并使其明確；——需求模型可變性，用建模語言表達和文檔化需求可變性，并使其明確；——需求可變性機制，對將被作為需求一部分的可變性機制進行分類；——需求可變性和可變性模型之間的可追溯性，建立并維護文本需求、需求模型和可變性模型之間的鏈接。在需求工程的資產管理過程中，領域需求工程產生的需求制品被構建為領域資產。需求可變性和通用性都作為領域資產進行管理。此外，具有高重用潛力的應用需求制品被識別為潛在的領域資產。需求工程資產管理為需求資產添加或開發額外的細節和粘接器，以便有效和高效地使用。在這個過程域中，還應分析需求領域資產之間的關系，以便成功地重用或管理其更改。在資產庫中配置領域資產和管理領域資產的過程參考ISO/IEC26555的資產管理。需求工程資產管理完成以下工作，并定義支持工具和方法的能力：——領域需求制品，作為識別和開發領域資產的必要信息，以幫助應用工程師在應用開發中重用需求資產；——應用需求制品，作為識別和管理的應用需求資產被后續應用參考。應用需求工程為每一產品線成員識別特定的需求。它開始評估現有的通用和可變需求的可重用性，以充分利用產品線平臺。還可向領域需求工程提供反饋，從而決定是否將應用需求資產合并到領域資產中。應用需求工程完成以下工作，并定義支持工具和方法的能力。——應用需求獲取，識別領域特征與應用特定特征之間的差距，重用資產庫領域需求，并獲取應用特定需求。——應用需求分析，對應用特定需求進行抽象、組織和建模。這個子過程應確保應用的利益相關方的所有需求都被理解，并且應仔細檢查應用需求的正確性、完整性和一致性。——應用需求規格說明，將已分析的應用特定需求與領域需求規格的綁定部分一起文檔化。——應用需求驗證和確認，確認特定產品需求的一致性和可行性，并確保綁定的變體與特定產品需求相關。——應用需求管理，為成員產品需求的后續變更提供管理服務。注1：產品線需求工程過程與ISO/IEC12207和ISO/IEC/IEEE15288兼容，見附錄BISO/IEC12207、對產品線需求工程方面的識別和分析使組織能夠理解需求工程過程，并為成功地實施過程制定策略。產品線的需求工程過程應根據這些方面來定義，支持這些過程的工具和方法的能力應根據這些方面來確定。注2：附錄C描述了子過程、關鍵方面以及相關工具表1給出了產品線需求工程的各個特性的關鍵方面。表1識別產品線特定需求工程任務的關鍵方面——應用工程：重用領域需求，綁定特定應用的外部可變性。以此規定應用需求；——資產：領域需求工程通過資產庫向應用工程提供需求的通用部分（領域需求）。因此，需求工程和管理的領域資產是一個突出的方面；——綁定：需求工程綁定應考慮反映外部的可變性。因此，綁定是產品線開發的一個獨特方面；6GB/TXXXXX—XXXX/ISO/IEC26551:2016——協作：由于領域需求工程和應用需求工程可并行執行，因此工程團隊之間以及領域資產、可變性管理、產品管理、范圍確定等過程之間的協作是必要的。這使協作成為產品線開發環境一個重要方面；——配置：產品線需求工程的產品和制品的配置可是多維的，即存在于時間和空間中，保持這些維度的完整性是一個重要的方面；——領域架構：領域需求工程提供領域需求作為建立參考架構的主要輸入；——領域工程：領域需求工程過程不存在于單產品開發中。然而，這一過程對于產品線是必要的；——使能技術支持：實現產品線需求工程所需的技術是產品線實現的關鍵成功因素；——測量和跟蹤：在產品線需求工程中，數據收集、度量和跟蹤需要考慮領域工程、應用工程、產品管理和領域資產。這意味著產品線的度量是多維的，因此應考慮所需的活動、角色、過程、工具和方法；——平臺：平臺實現了在產品之間重用通用元素（例如：制品、組件、連接器等）。產品線需求工程制品是平臺的關鍵要素；——產品管理：需求工程應從可預見的產品線策略中處理產品線的可重用性。由于需求根據風險和機會不斷演化，產品管理應監控和支持需求的演化；——可重用性：需求工程過程中資產的可重用性與實現產品線的總體目標密切相關，實現整個產品線的可重用性是需求工程的一個不同的方面；——構造：產品線需求是建立構造的主要輸入。特別是對于功能和非功能需求的開發規則和具體細節，應建立相應的架構性構造；——可追溯性：在可變性和來自領域/應用需求工程的制品之間存在各種跟蹤鏈接。應開發一個追溯性方案來處理追溯問題；——驗證和確認：在產品線開發環境中，從不同的角度(如領域、應用、可變性、領域資產等)提供對需求進行驗證和確認的客觀證據是一個重要方面，因此需要提供單產品開發的差異化方案；——可變性：需求工程可變性主要處理與可重用性策略相關的外部可變性，單產品開發不關注可變性。5產品線范圍界定產品線組織需要確定哪些產品和特征構成產品線，然后該組織確定哪些特征是通過重用或改編遺留資產實現的，或者哪些是新開發的。通過客觀和定量的努力，該組織估計產品線的預期經濟效益，并根據經濟效益做出產品線啟動的決定。產品線范圍界定過程包括三個關鍵子過程：——產品范圍界定，根據市場輸入，確定潛在的成員產品和原始的通用和可變的特征；——領域范圍界定，將領域分解為子域（或功能域），并將產品范圍界定中確定的原始特征映射到子域；——資產范圍界定，確定可重用資產，計算成本/收益估計，以證明產品線啟動的合理性，并提供產品線的路線圖。上述三種類型的范圍界定可迭代。5.1產品范圍界定5.1.1目的產品范圍界定的目的是確定產品組合定義：7GB/TXXXXX—XXXX/ISO/IEC26551:2016a)產品線組織開發、生產、營銷、銷售的產品；b)產品提供的通用特征和可變特征，即滿足用戶需求，并實現產品線組織的長期和短期業務目標；c)產品推向市場的時間表。5.1.1.1輸入該子過程的輸入如下所述。——產品定義戰略：兩種主要類型是客戶驅動和生產者驅動的戰略。在客戶驅動的戰略中，產品線的成員產品是根據市場輸入，特別是根據客戶的需求和短缺來按需定義的，在生產者驅動的戰略中，產品線組織定義了產品。——市場信息：針對產品范圍界定階段，來自以下幾點:.細分市場、其特征和預期的未來演化；.客戶需求及預期演化；.技術及預期演化；.現有和潛在的競爭對手；.競爭產品及預期演變。——其他內部信息：為發展和保持對整個產品線組織的理解和控制所必需的信息。5.1.1.2輸出該子過程的輸出如下所述。——產品組合定義，即確立（原始）產品路線圖，包括產品、其外部可見的通用和可變特征集以及市場引入時間表。——定義高級產品計劃。5.1.1.3任務該子過程的任務如下所述。——結構化范圍界定信息。結構化市場信息、產品線的候選成員產品信息以及業務目標以便于為處理進一步范圍界定活動提供參考。——識別產品。進行潛在成員產品（包括現有成員產品和新成員產品）的識別以滿足市場需求和業務目標。識別和分析現有的產品、原型和其他可重用的資產。關于產品的信息可從內部（例如領域專家）和外部（例如組件供應商的外部專家）資源收集。——分析通用和可變特征。通過分析產品線內部或外部的特征，可對一組系統進行初步分析。——定義產品組合。確定構成產品線的成員產品和特征。產品組合的決策宜與組織的產品定義戰略（如客戶驅動或生產者驅動的戰略）相一致。5.1.2結構化范圍界定信息將用于范圍界定的信息提取和結構化，以便范圍界定參與者做出正確的決定。方法宜支持用于范圍界定的結構化信息，具有以下能力：——選擇用于范圍界定的信息；——提供用于將必要信息結構化的模板；——厘清所選信息集之間的關系及依據；——根據提供的模板重新組織信息。工具宜通過允許用戶執行以下操作來支持結構化范圍界定信息：8GB/TXXXXX—XXXX/ISO/IEC26551:2016——訪問用于范圍界定的信息（或提供訪問接口）；——允許使用模板進行文檔編制；——支持結構化信息的維護；——允許結構化信息的重用。5.1.3識別產品該任務的目標是找到產品線的成員產品、發布計劃及高級別特征。方法宜支持識別成員產品，具備以下能力：——識別現有的或未來可能在產品線中生產的成員產品；——生成潛在的成員產品列表；——分析所生成的潛在成員產品列表（使用目標、市場定義等）；——選擇并定義原始成員產品列表；——驗證所定義的原始成員產品列表。工具宜通過以下方式支持成員產品的識別：——支持團隊協作；——支持成員產品識別過程的文件編制。允許用戶執行以下操作：——收集產品線中現有和未來可能生產的產品信息；——聚類收集的候選產品信息；——管理聚類的候選產品信息；——可視化、建模并組織有關現有、未來和假設產品的信息，作為產品線候選產品。5.1.4分析通用特征和可變特征該任務中分析的通用和可變特征進行了抽象。這些通用的和可變的特征，包括產品質量，用于確認產品線是否滿足組織的期望，通過重用降低成本。方法宜支持分析通用和可變特征，具有以下能力：——分析描述產品線中表征產品的特征（高級）；——分析產品質量（可在領域需求工程中完善為質量屬性）；——區分通用特征和可變特征；——建模特征（使用適當的特征建模符號）；——評估通用和可變特征，以確保確定產品的主要特征被識別（通過研討班、頭腦風暴和分類等——提供文檔模板，用于文檔化通用和可變特征。工具宜支持分析通用和可變特征，允許用戶執行以下操作：——可視化通用/可變特征和產品質量；——允許使用模板進行文檔編制；——允許在進一步范圍界定和需求工程活動中引用分析結果；——支持文檔化與決策形成相關的全部理由，并使其在進一步的范圍界定和需求工程活動中被引5.1.5定義產品組合方法宜支持定義產品組合，具有以下能力：——結構化有關市場信息、原始產品清單及高級別特征的問題；——使用決策過程（例如頭腦風暴法、名義團體法、德爾菲法）做出決策；9GB/TXXXXX—XXXX/ISO/IEC26551:2016——驗證該決策；——提供檢查單以驗證決策。工具宜支持通過以下方式定義產品組合：——提供協助決策的模板；——文檔化已定義的產品組合。5.2領域范圍界定5.2.1目的領域范圍界定的目的是分解功能域并將原始功能映射到功能域，以降低復雜性并提高產品線的可重用性。5.2.1.1輸入該子過程的輸入如下所述：——產品組合定義；——從領域專家和現有產品經驗中收集的信息。5.2.1.2輸出該子過程的輸出如下所述：——建立領域范圍定義[包括功能（子功能）域及通用和可變特征]；——定義一組高級別特征；——產品組合的定義得到完善。5.2.1.3任務該子過程的任務如下所述。——確定功能域。查找、分析和分類功能，以最大限度地提高可重用性。功能域可通過將特征分組并分級派生出來（即包括子領域）。——將特征映射到功能域。將識別的特征分解到功能域。——定義領域范圍。評估并選擇最適合重用的功能域。5.2.2識別功能域功能域由對產品線產品具有足夠經驗和知識的專家確定和分類，驗證功能域和特征的技術可行性，并進一步完善特征。方法宜支持識別功能域，具有以下能力：——分析產品線各領域的功能（定義領域邊界方法示例：包含或排除的規則、結構圖、上下文關系圖等）；——對共同使用的功能進行分類；——文檔化和結構化已確定的功能域；——驗證分類后的功能域。工具宜支持識別功能域，具有以下能力：——支持團隊協作；——顯示分析和分類的結果。允許用戶執行以下操作：GB/TXXXXX—XXXX/ISO/IEC26551:2016——可持續地管理分析和分類的功能域；——文檔化功能域；——管理功能域和有關分析之間的關系。5.2.3將特征映射到功能域建立識別出的功能域、產品和特征的映射表，以表示它們之間的關系。方法宜支持將功能域映射到特征，具有以下能力：——分析功能域和特征之間的關系；——將特征映射到功能域；——完善功能域和特征；——驗證映射結果。工具宜支持將功能域映射到特征，具有以下能力：——顯示功能域和特征（例如由功能域列和特征行組成的excel工作表）；——允許對定義功能域的基本原理進行文檔化。允許用戶執行以下操作：——創建功能域和特征之間的關系；——管理功能域和特征之間的關系。5.2.4定義領域范圍定義領域范圍是為了說明功能域、產品和特征之間的關系。方法宜支持定義領域范圍，具有以下能力：——根據可變性和性能維度評估功能域；——使用適當的決策過程選擇功能域（例如頭腦風暴，名義組技術（NominalGroupTechnique，NGT），德爾菲）；——管理與功能域選擇有關的問題；——驗證定義的領域范圍。工具宜支持定義領域范圍，具有以下能力：——顯示領域范圍定義；——提供用于評審、評論和通信的協作環境。允許用戶執行以下操作：——評估、驗證和文檔化領域范圍定義；——提出并解決與領域范圍有關的問題。5.3資產范圍界定5.3.1目的資產范圍界定的目的是識別潛在的可重用資產，并估計重用建議資產的經濟效益。資產的評估是基于工程設計所需的工作量，使用從現有相關產品和領域專家收集的歷史數據中得出的工作量估計函數進行量化。5.3.1.1輸入該子過程的輸入如下所述：——領域范圍定義（包括功能域及通用和可變特征）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——估計模型和當前實踐的其他信息；——可用的測量數據（即相關領域的歷史數據）。5.3.1.2輸出該子過程的輸出如下所述：——提出資產建議（包括功能、特征和工作量估計）；——建立了量化的領域定義；——生成投資回報率（ReturnOnInves，ROI）估計；——提供現有資產清單。5.3.1.3任務該子過程的任務如下所述。——從現有的單產品中收集歷史數據。識別和收集有關現有產品的信息，以更好地理解該領域并識別潛在的可重用資產。——估計修改潛在資產所需的額外工作。估計使潛在資產適合產品線所需的額外工作。——在產品組合定義中估計新產品的預期開發成果。評估將新產品納入產品組合的成本、工作量和風險。該計算基于對現有相關產品、開發限制、系統/軟件屬性和市場屬性的學習。——估計重用建議資產的經濟效益。評估重用現有資產、重用新開發的領域資產以及減少由于質量改進而導致的返工和故障所帶來的經濟效益。——根據經濟評估結果得出資產方案。定義資產建議，包括資產（功能域和特征）及經濟評估結果。通過擴展域定義建立資產建議。為領域所有資產創建詳細和量化的工作量估計。5.3.2從現有單產品收集歷史數據工作量估算可根據歷史數據進行，如現有相關產品在特定時間段內累積的測量數據。方法宜支持從現有單產品中收集歷史數據，具有以下能力：——定義宜收集何種歷史數據；——整合各種來源的數據；——搜索數據；——驗證所收集數據的有效性。工具宜支持從現有單產品收集歷史數據，允許用戶執行以下操作：——允許文檔化從現有單產品收集歷史數據的結果；——從其他工具導入源；——提供對歷史數據的管理能力。5.3.3估計修改潛在資產所需的額外工作雖然有些資產可按原樣重用，但有些資產需在修改后重用。因此，領域資產開發之前應估計修改工作量，因為如果修改工作量太高，就難以預期從領域資產重用中獲益。方法宜支持估計修改潛在資產所需的額外工作，具有以下能力：——分析現有產品和新產品之間的關系；——分析新產品預期開發工作的因素；——定義新產品的工作量估計函數；——提供可用于工作估計的度量；——允許在必要時添加新的度量。GB/TXXXXX—XXXX/ISO/IEC26551:2016工具宜支持估計修改潛在資產所需的預期額外工作，具有以下能力：——展示資產、功能域、特征、產品之間的關系及對經濟效益的影響；——提供用于估計的度量，以便工具用戶可在其中進行選擇；——允許在必要時添加新的度量。5.3.4在產品組合定義中估計新產品的預期開發工作量產品組合定義中包含的一些產品是新產品，因此應根據從現有相關產品收集的測量數據來估計工作量。在估計產品線的整體效益時，宜單獨考慮這種估計。方法宜支持估計產品組合定義中、新產品的預期開發工作量，具有以下能力：——分析現有產品和新產品之間的關系；——分析新產品預期開發工作的因素；——定義新產品的工作量估計函數。工具宜支持在產品組合定義中估計新產品的預期開發工作量，具有以下功能：——提供工具用戶可選擇的工作量估計的度量；——如果需要，允許添加新的度量；——顯示資產、功能域、特征、產品之間的關系及對經濟效益的影響程度。允許用戶執行操作：文檔化新產品預期經濟效益的估計結果。5.3.5估算建議資產再利用的經濟效益根據歷史數據及經驗開發，計算建議資產預期成本及收益的工作量估計函數。方法宜支持估計重新使用建議資產的經濟效益，具有以下能力：——收集歷史數據；——分析歷史數據；——從歷史信息中估計預期收益。工具宜支持估算重用建議資產的收益，具有下列能力：——文檔化估算建議資產重用效益的過程；——從各種來源導入歷史數據；——顯示領域、子領域、產品和收益之間的關系。5.3.6根據經濟評價結果得出資產方案該任務的目標是集成以前估計的結果，用于得出資產方案，包括由于產品線而造成的成本和收益。方法宜支持從經濟數據中得出資產建議，具有以下能力：——集成工作量估計；——使用決策過程（例如頭腦風暴、名義組技術（NGT）、德爾菲）對資產方案做出決策；——驗證決策。工具宜支持從經濟數據中得出資產方案，具有以下能力：——文檔化資產方案；——在圖形用戶界面中顯示資產方案；——使用輸入數據和預定義的成本效益函數提供自動計算；——突出顯示開發作為領域資產所必需的資產列表；——允許使用資產方案來追溯估計和實際成本/效益結果之間的差距。6領域需求工程GB/TXXXXX—XXXX/ISO/IEC26551:2016在領域需求工程中，識別和記錄功能性和非功能性需求以及這些需求外部可變性。領域需求工程應遵循產品線范圍界定階段產生的資產方案中定義的特征。這些特征是領域需求的關鍵來源。其他領域和應用工程過程將參考已定義的領域需求。領域需求工程有五個基本的子過程。——領域需求獲取。該子過程的目的是將產品線范圍界定階段定義的特征分解為原始需求，并從利益相關方和領域專家那里獲取附加需求和派生需求。同時，該子過程還從領域利益相關方那里明確地捕獲產品線成員的預期變化。——領域需求分析。該子過程的目的是基于所獲取的領域需求，找到共性并識別可變性，以實現產品線的預定重用目標。應更深入地分析領域需求，以找出更多的共通需求并減少獨特需求，從而提高經濟可行性和效益。產品線范圍是確定產品線邊界的主要輸入。——領域需求規格說明。該子過程的目的是文檔化領域需求，這些需求規范包括共性需求和可變需求。領域需求規格的可變性受產品線中特定成員產品的約束。——領域需求驗證和確認。該子過程的目的是驗證和確認產品線需求是正確的、完整的、一致的，并且適用于每個產品，而產品特定的需求應在應用需求驗證和確認子過程中進行驗證和確認。——領域需求管理。該服務的目的是管理領域需求的可追溯性和變更。由于產品線具有雙重性質，并且領域資產在多個應用中通用，可追溯性和變更管理的復雜性較高，因此應制定有效對策以應對這些復雜性。6.1領域需求獲取6.1.1目的領域需求獲取的目的是在產品線范圍界定結果的基礎上，分解、發現、評審和理解利益相關方需求以及與產品線平臺相關的約束。6.1.1.1輸入該子過程的輸入如下所述：——領域利益相關方的信息；——產品線范圍內的資產方案；——產品線范圍內的高級特征集合；——現有資產清單。6.1.1.2輸出該子過程的輸出如下所述：——維護領域信息（每個應用的目標、問題定義、當前和潛在用戶、需求、利益相關方等——建立領域信息源鏈接；——定義上下文關系圖；——產生細化的共性和可變特征集；——產生分類的領域需求（原始的共性需求和可變需求集）。6.1.1.3任務該子過程的任務如下所述。——繪制上下文關系圖。產品線的上下文關系圖獲取高級別實體和實體關系（例如產品線用戶、物理環境或與產品線相關的其他系統）。GB/TXXXXX—XXXX/ISO/IEC26551:2016——收集領域信息。通過舉辦研討會、檢查當前系統以及訪談領域和應用工程師，獲取領域信息。——確定原始領域需求。領域需求工程師評審收集的領域信息，并從用戶的角度確定原始的領域需求。更詳細地修訂產品線范圍內產生的高級特性集合（包括共性需求和可變需求）。對可變性進行細化，并將其鏈接到其他過程開發的相關模型中。——評審獲取的原始領域需求。檢查獲取的原始領域需求，看它們是否違反了產品線的范圍和利益相關方的需求。必要時進行修訂（包括與資產方案進行比較）。確定領域需求獲取的代表和利益相關方（例如潛在的客戶和其他利益相關方，比如領域專家和應用工程師）。利益相關方包括對客戶、競爭對手、市場趨勢和產品線成員產品有了解的人。注：獲取需求的技術示例：目標問題度量（GoalQuestionMetric，GQM）、質量功能展開（QualityFunctionDeployment，QFD）、卡諾6.1.2繪制上下文關系圖上下文關系圖描述了領域環境與產品線成員之間的關系，同時也描述了產品線成員之間的關系。該任務旨在提取產品線內的對象及其相互作用。方法宜支持繪制上下文關系圖，具有以下能力：——識別每個產品線成員現有的上下文關系圖；——分析領域環境（領域用戶、利益相關方、外部系統等）；——分析業務環境；——分析產品系列與已識別的領域實體之間的關系；——繪制領域上下文關系圖。工具宜支持繪制上下文關系圖，具有以下能力：——提供文檔模板，用于記錄產品線成員與已識別的領域實體之間的關系；——提供檢查單，用于識別領域實體；——繪制領域上下文關系圖。6.1.3收集領域信息領域信息是通過分析各種來源收集的，例如：產品線內的應用目前滿足的需求；利益相關方在當前應用中面臨的問題，以及應用尚待處理的更改請求。方法宜支持收集領域信息，具有以下能力：——確定領域信息源（例如產品組合、高級別生產計劃、領域定義、范圍界定資產提案、使用無上下文問題的訪談和調查，以及需求獲取研討會和會議）；——確定產品線利益相關方；——收集領域信息（產品線目標、利益相關方、現有產品線成員的目標和需求、新應用解決的問題和目標等）；——驗證收集的領域信息。工具宜支持收集領域信息，具有以下能力：——將領域信息導入所述領域需求獲取工作空間；——提供模板，用于文檔化收集到的領域信息；——提供存儲庫（或注冊表），用于保存領域信息；——維護領域信息及其來源之間的跟蹤鏈接。6.1.4識別原始領域需求該任務的目標是從產品線利益相關方處獲取原始需求。GB/TXXXXX—XXXX/ISO/IEC26551:2016方法宜支持識別原始領域需求，具有以下能力：——評審收集的領域信息；——將高級特征細化為較低級特征；——確定與特征相關的需求；——收集產品線內新應用的其他需求；——描述領域需求（例如：運行場景、目標模型、用例圖、特征方式）；——從“利益相關方”的角度開發領域使用場景。工具宜支持識別原始領域需求，具有以下能力：——提供關于領域信息的瀏覽、評審和評論環境；——提供模板，用于記錄提取出的領域需求；——從利益相關方的角度對提取的需求進行建模。同時，工具允許用戶執行以下操作：——描述領域需求；——描述領域使用場景。6.1.5評審獲取的原始領域需求評審獲取的原始領域需求，以確保其完整性和正確性。方法宜支持評審獲取的原始領域需求，具有以下能力：——在獲取的需求和來源之間建立可追溯性；——驗證獲取結果的完整性和正確性；——評審產品線內應用之間的沖突；——解決領域需求問題（記錄未解決的沖突，以便在需求分析階段進行分析和解決——文檔化獲取并分類的需求。工具宜支持評審獲取的原始領域需求，具有以下能力：——保持獲取需求與其來源之間的可追溯性；——提供文檔化獲取的領域需求的模板；——維護驗證的檢查單。6.2領域需求分析6.2.1目的該子過程的目的是定義功能需求、非功能需求和需求風險，并分析其可行性。在需求分析的同時，對可變性模型進行完善，與之前的模型保持一致，需求過程可變性和領域需求分析同時實施，從而對可變性模型進行一體化管理。6.2.1.1輸入該子過程的輸入如下所述。——獲取的領域需求。——高級領域需求模型（例如用例模型、特征方式、上下文關系圖）。——共同和可變特征的原始集合。——共同和可變需求的原始集合。6.2.1.2輸出GB/TXXXXX—XXXX/ISO/IEC26551:2016該子過程的輸出如下所述。——建立功能性和非功能性領域需求（包括約束、依賴關系和優先級）。——改進并建立領域需求模型（通過細化在需求獲取階段產生的用例模型、特性模型和上下文關系圖，來建立共性模型）。——確定與可變性相關的信息。定義領域需求層面的可變性（包括可變性、依賴性、約束）。——進行技術/經濟可行性分析，并產生分析結果。——定義評審檢查單。——為領域需求制定概念性的測試用例和場景。6.2.1.3任務該子過程的任務如下所述。——分類和平衡原始領域需求。原始領域需求被分為功能、質量屬性、約束和其他非功能需求。通過將高級別需求分解為低級別需求、將細化的需求聚合為更高級別的需求，來平衡原始領域需求的顆粒度。——分析共性和可變性。對產品族的共性需求進行分析，分析各應用之間存在系統性差異（可變性）的需求。可變性分析包括識別變化點、變體和依賴性。——建模領域需求。以高度抽象的方式可視化領域需求及其相互依賴關系，以發現不正確、不一致、缺失和多余的需求。領域需求模型應處理可追溯到領域可變性模型的共性和可變性。——創建原型并分析可行性。原型用于從多個角度（例如可接受的成本和性能）評估實現某些關鍵需求的可行性，同時理解和確定與需求相關的風險和優先級。——開發驗收測試中概念性的測試用例和場景。根據驗收測試需求，推導出概念性的測試用例和場景。這些測試用例和場景通常適用于產品系列的所有成員。這些場景和用例可來源于需求模型，比如用例圖。——評審領域需求。評審領域需求以識別和糾正不完整和不正確之處。6.2.2對原始領域需求進行分類和平衡該任務用于對原始領域需求進行分類和平衡。將目標、業務規則、功能需求、質量屬性、約束等按其共性和可變性特征進行分類，并將顆粒度、不正確和有矛盾之處協調一致，以便進一步分析。方法宜支持對原始領域需求進行分類和平衡，具有以下能力：——為平衡原始需求的抽象層次定義指導方針；——將高級別原始領域需求分解為較低級別的原始領域需求；——將低級別原始領域需求聚合為較高級別的領域需求；——識別原始領域需求之間的不一致。工具宜支持對原始領域需求進行分類和平衡，具有以下能力：——能夠將獲取的原始領域需求和相關信息導入到領域分析工作空間中；——提供編輯環境，以支持對原始領域需求的分解或聚合；——能夠區分共性的和可變性的原始需求；——提供文檔模板，用于描述分類的原始領域需求。6.2.3分析共性和可變性在該任務中，分析共性和可變性需求，定義可變性、變體、綁定時間、依賴性和約束。方法宜支持分析共性和可變性，具有以下能力：——分析原始的共性和可變性需求（例如通過將需求映射到特征、通過使用產品線的建模概念GB/TXXXXX—XXXX/ISO/IEC26551:2016——對需求進行詳細分析，以確定所有應用的共性和可變性需求（例如通過將領域需求與成員產品的需求進行映射，以及通過應用組織規則來確定共性和可變性）；——確定共性和可變性需求；——分析可變性需求的屬性特征（例如綁定時間、變化點及其變體和類型）；——為共性和可變性的需求決策提供依據和假設（如有必要）；——驗證共性和可變性（包括可變性之間的一致性）。工具宜支持分析共性和可變性，具有以下能力：——提供分析工作空間，以確定共性和可變性；——提供文檔模板，用于描述需求級別共性和可變性；——將相關信息導入領域分析工作空間；——顯示已定義的相關共性和可變性信息。6.2.4建模領域需求需求建模確保所識別領域需求的完整性和可行性。方法宜支持領域需求建模，具有以下能力：——建模需求（通過使用文本、自然語言或可視化建模）；——分析需求模型，確保其完整性、正確性、可行性和可驗證性；——細化功能需求（比如從場景、用例中細化）；——細化非功能需求。工具宜支持領域需求建模，具有以下能力：——支持領域需求建模或提供與建模工具交互的接口；——允許跟蹤領域需求；——提供文檔模板，用于文檔化領域需求模型。6.2.5創建原型并分析可行性針對那些模糊不清或存在技術困難的需求建立原型，基于原型進行可行性分析。方法宜支持創建原型和分析可行性，具有以下能力：——對領域需求進行優先級排序；——選擇需要創建原型的需求；——決定收集哪些信息；——進行原型設計；——從設計和使用原型的利益相關方那里收集反饋和其他必要信息；——使用原型設計結果分析可行性。工具宜支持創建原型和分析可行性，具有以下能力：——生成和存儲用戶定義的或工具提供的、用于多樣性分析的檢查表或模板（多樣性分析如：技術、經濟和業務分析）；——存儲和管理可行性分析的理由；——與外部工具交換有關原型設計的信息。6.2.6開發驗收測試的概念性測試用例和場景該任務將開發驗收測試中使用的測試用例和場景。對于無法開發測試用例的需求，在該任務之前進一步澄清。方法宜支持為驗收測試開發概念性測試用例和場景，具有以下能力：GB/TXXXXX—XXXX/ISO/IEC26551:2016——基于領域需求（領域需求模型或規范）開發驗收測試中使用的概念性測試用例和場景（概念性測試用例和場景應處理可變需求）；——在應用需求工程中生成可重用的概念性測試用例和場景；——為每個測試用例和場景分配唯一標識符。工具宜支持開發驗收測試的概念性測試用例和場景，具有以下能力：——支持從領域需求中自動/半自動地派生；——允許概念性測試用例和場景中存在可變性，以便后續在每個成員產品中進行綁定；——提供文檔模板，用于記錄派生測試用例和場景；——允許用戶查找和訪問相關信息（例如功能性和非功能性需求、可變性模型——從領域需求半自動/自動生成測試用例。6.2.7評審領域需求該任務確保領域需求清晰明確，包括所有利益相關方的需求，且評審共性和可變性，以確保共性需求的正確性、經濟和技術可行性以及完整性。方法宜支持評審領域需求，具有以下能力：——識別不明確或無法驗證的需求；——與利益相關方一起分析這些需求，并提出修改建議；——分析修改建議對領域需求的影響；——必要時修訂需求。工具宜支持評審領域需求，具有下列能力：——導入領域需求分析結果；——提供通過網絡評審和評價領域需求的環境。6.3領域需求規格說明6.3.1目的領域需求規格說明以一種一致的、可訪問的和可評審的方式，清晰而精確地記錄功能性和非功能性需求和約束。規格說明宜與相關的可變性模型建立跟蹤鏈接，以管理需求、可變性及其變更。6.3.1.1輸入該子過程的輸入如下所述：——功能性和非功能性領域需求（包括約束、依賴關系和優先級）；——領域需求模型；——可變性模型（來自需求可變性）；——領域需求的概念性測試用例和場景；——技術或經濟可行性分析結果；——軟件需求規格說明（SoftwareRequirementsSpecification，SRS）模板。6.3.1.2輸出該子過程的輸出：建立領域需求的SRS。領域需求規格說明（即產品線的SRS）應區分產品線中所有成員產品和應用特定部分的常用需求。建立從需求到來源的跟蹤鏈接。6.3.1.3任務GB/TXXXXX—XXXX/ISO/IEC26551:2016該子過程的任務如下所述。——識別領域需求的來源，以確保所有利益相關方都知道SRS中每個需求的方式和原因，以便于進一步的澄清需求，并追溯每個需求的起源。——通過詳實的跟蹤鏈接在需求源到領域需求之間建立可追溯性。領域需求之間、領域需求和其他領域制品（例如領域范圍界定）之間需要建立跟蹤鏈接。在需求過程可變性中建立管理可變性的跟蹤鏈接。——文檔化領域需求。使用SRS模板記錄領域需求。——評審領域需求規格說明。評審領域需求規格說明，以確保文檔的完整性和正確性。6.3.2識別領域需求的來源識別領域需求的來源，以建立跟蹤鏈接，并對需求進行管理。方法宜支持識別領域需求的來源，具有以下能力：——分析領域需求的屬性；——確定所有領域需求的來源；——分析領域需求和其他領域制品之間的關系。工具宜支持識別領域需求的來源，具有以下能力：——查找和引用在其他過程中生成的信息（從產品線范圍界定到領域需求分析——提供具有預定義屬性的模板，用于系統地記錄領域需求的相關信息；——文檔化和維護所識別的領域需求源信息。注：需求屬性示例：——決定共性或可變性；——決定的理由；——與每種可變性有關的產品；——從產品線范圍界定中得出的相關特征。6.3.3建立可追溯性為產品線建立跟蹤鏈接通常比為單個應用建立跟蹤鏈接更復雜，因為與單個應用開發環境相比，在產品線環境中有更多的信息源（例如：利益相關方、現有產品、市場）、更多的領域制品、更多的相互依賴性和更多制品的有效配置。因此，工具在產品線環境中扮演著特別重要的角色。方法宜支持建立可追溯性，具有以下能力：——建立從領域需求到需求源的正向和反向跟蹤鏈接，反之亦然；——建立需求制品（包括范圍界定制品）之間跟蹤鏈接；——建立跟蹤列表。工具宜支持建立可追溯性，具有以下能力：——展示領域需求和其來源之間的后向和前向跟蹤鏈接；——明確定義跟蹤鏈接的類型，以確定兩個制品之間的依賴關系是否為強制性的（即產品中選擇需求X，則應選擇需求Y）、可選的（即產品中選擇需求X，可以選擇需求Y，但不是必需的或是互斥的（即產品中選擇需求X，則無法選擇需求Y）；——以圖形方式展示需求制品之間的跟蹤鏈接以及相關的共性和可變性信息；——提供具有預定義可追溯性屬性的模板，用于文檔化可追溯性信息。6.3.4文檔化領域需求該任務制定一個結構良好的領域需求規格說明，其中包含所有必要的信息。GB/TXXXXX—XXXX/ISO/IEC26551:2016方法宜支持文檔化領域需求，具有以下能力：——通過區分共性需求和可變性需求，為每個需求提供唯一標識符；——定義可重復使用的SRS模板，用于文檔化每個產品；——對領域需求進行優先級排序；——將領域級業務規則（包括公司政策、政府法規和計算算法）與SRS分開記錄。工具宜支持文檔化共性和可變性需求，具有以下能力：——提供文件模板（包括區分共性需求和可變性需求）；——從建模工具導入需求模型用于文檔化；——通過拼寫檢查、數據字典、縮略語表等方式檢查文件質量和一致性；——將SRS和相關領域需求存儲在（集中式的）存儲庫中。6.3.5評審領域需求規格說明該任務確定領域需求規格說明的完整性、正確性、明確性和可追溯性。方法宜支持評審領域需求規格說明，具有以下能力：——確保領域需求規格說明包括所有必要的內容；——確認領域需求規格說明可以容易地被重用，以推導出應用需求規格說明；——分析和修訂領域需求規格說明。工具宜支持評審領域需求規格說明，具有以下能力：——導入和瀏覽領域需求規格說明；——為評審、討論和評論需求規格說明提供環境。6.4領域需求驗證和確認6.4.1目的該子過程的目的是確保產品線需求完整、正確、一致且清晰。領域需求確認宜與可變性模型確認一同進行，以保持需求和可變性之間的一致性。6.4.1.1輸入該子過程的輸入如下所述：——領域需求規格說明；——概念性測試用例和場景；——評審檢查單。6.4.1.2輸出該子過程的輸出如下所述。——驗收測試的概念性測試用例和場景。這些驗收標準通常用于推導特定產品的驗收標準。——基線化的領域需求。評審、檢查和確認從需求獲取、分析、規格說明、可追溯性、測試和需求模型中產生的文檔，確定領域需求的基線。6.4.1.3任務該子過程的任務如下所述。GB/TXXXXX—XXXX/ISO/IEC26551:2016——驗證領域需求。識別出模糊或不可驗證的領域需求，并檢查領域需求模型（如SRS、用例、測試用例和原型在領域需求獲取、分析和說明子過程中產生的其他文檔。使用在領域需求分析過程中產生的概念性測試用例來驗證領域需求。——確認領域需求。確認領域需求（包括功能和非功能領域需求）是否完整且正確。——確認概念性測試用例和場景。確認概念性測試用例和場景用于基于需求的系統測試或驗收測試是否合適。——基線化領域需求。該任務建立了所有成員產品共同認可的和批準的一套共性需求。當該項任務完成后，領域需求管理中所有需求都將受到嚴格的變更和配置控制。——啟動變更管理過程。在該任務中，啟動適當的變更管理過程和配置管理系統，以便在確定需求基線后對領域需求的變更進行妥善管理。6.4.2驗證領域需求該任務確保領域需求清晰、易于理解且可測試。方法宜支持驗證領域需求，具有以下能力：——驗證指定的單領域需求制品；——識別模糊或無法驗證的需求；——提供驗證檢查單；——驗證共性和可變性需求的優化。工具宜支持驗證領域需求，具有以下能力：——指導驗證過程；——展示指定的領域需求和相關信息；——支持多用戶同時編輯同一文檔；——提供團隊評審、標記和評論領域需求的環境；——提供記錄驗證結果的文檔模板（包括評審結論的理由以及采取的糾正措施——通知利益相關方驗證狀態。6.4.3確認領域需求該任務確保領域需求的完整性和正確性。方法宜支持確認領域需求，具有以下能力：——確認是否存在缺失或相互矛盾的領域需求；——提供確認檢查單；——檢查領域需求的完整性和正確性；——確認所定義的可變性，包括其變體和依賴關系。工具宜支持確認領域需求，具有以下能力：——指導確認過程；——展示指定的領域需求和相關信息；——支持多用戶同時編輯同一文檔；——提供團隊評審、標記和評論領域需求的環境；——提供記錄確認結果的文檔模板（包括評審結論的理由和采取的糾正措施——通知利益相關方確認狀態。6.4.4確認驗收測試的概念性測試用例和場景GB/TXXXXX—XXXX/ISO/IEC26551:2016對產品線中所有應用常用的概念性測試用例和場景進行確認，以確保其足以確認成員產品的完整性和正確性。在應用需求工程中，會基于領域驗收標準來定義應用特定的測試用例和場景。方法宜支持確認驗收測試的概念性測試用例和場景，具有以下能力：——定義概念性測試用例和場景的驗證標準；——確認概念性測試用例和場景可變性是否結構良好；——確認是否能從概念性測試用例和場景中推導出用于驗收測試的應用特定測試用例和場景。工具宜支持確認驗收測試的概念性測試用例和場景，具有以下能力：——瀏覽和訪問領域需求資產，以確認概念性測試用例和場景；——訪問領域需求資產、可變性模型和已定義的概念性測試用例和場景之間的跟蹤關系；——允許半自動/全自動化地生成確認報告。6.4.5建立領域需求基線在該任務中創建并發布領域需求基線，通過變更管理對基線的更改進行控制和管理。方法宜支持建立領域需求基線，具有以下能力：——為領域需求建立正式協議；——為已批準的領域需求建立基線；——管理基線領域需求的配置。工具宜支持建立領域需求基線，具有以下能力：——提供變更與配置管理系統交互的接口；——將基線化的領域需求導出到變更和配置管理系統的存儲庫中。6.4.6實施變更管理在實施需求管理中定義的變更管理之前，實施本變更管理。方法宜支持實施變更管理，具有以下能力：——建立變更管理環境（例如變更管理流程和支持性變更管理信息系統）；——建立一個變更管理信息系統和支持性的配置管理系統。建立一個變更管理信息系統和支持性的配置管理系統以支持實施變更管理，具有以下能力：——建立領域需求基線后，原始化領域需求庫，以存儲基線化的領域需求；——建立與變更管理信息系統和配置管理系統交互的接口。6.5領域需求管理6.5.1目的領域需求管理的目的是在產品線和產品線成員開發過程中，對領域需求工程過程（獲取、分析、記錄和確認）進行計劃、協調和文檔化，并有效地處理利益相關方的變更請求。6.5.1.1輸入該子過程的輸入：領域需求的變更請求（來自領域工程或應用工程）。6.5.1.2輸出該子過程的輸出如下所述：——建立領域需求文檔的新基線和版本；——文檔化的影響分析結果（包括對領域需求和應用需求的影響）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——維護每個領域需求的變更歷史。——更新后的領域需求跟蹤鏈接；——建立狀態統計和報告；——領域需求工程過程資產；——記錄可變性模型的變更請求（在需求可變性的可變性演化子過程中處理）。6.5.1.3任務該子過程的任務如下所述。——管理領域需求變更。跟蹤對領域需求的變更，并將批準的更改傳達給所有受影響的利益相關方。——管理可追溯性。可追溯性管理使利益相關方能從正向和反向兩個方向追蹤需求從起源到實現的整個生存周期。——管理領域需求的版本。管理在領域需求工程中產生的制品或制品的版本。——記錄并報告狀態（狀態統計）。記錄并報告受控的領域需求基線狀態和歷史管理記錄。狀態報告應包括領域需求的變更數量以及在領域需求工程中產生的最新制品版本。——管理過程改進。評估和評審領域需求工程及其信息系統，以了解所實施過程的優點和缺點。基于評估實施改進。——管理反饋。管理和解決來自其他領域和應用工程過程的反饋。在需求可變性過程中，對產品線中成員產品之間的可變性需求進行變更，以反映可變性的變化。6.5.2管理領域需求變更產品線變更管理是復雜的，因為領域需求的變更請求來自應用工程和領域工程。由于領域需求與產品線多個應用相關，因此相比單產品環境，在產品線環境中對所請求的變更進行影響分析更困難。因此，配套的工具和方法至關重要。方法宜支持管理需求變更，具有以下能力：——獲取領域需求的變更請求；——分析對其他領域需求相關變更的影響；——分析對其他應用相關變更的影響；——批準變更；——跟蹤變更請求的狀態直至結束。工具宜支持需求變更管理，具有以下能力：——建立請求變更的渠道；——上傳變更請求；——保存有關變更請求來源的信息；——通知利益相關方變更請求的狀態；——維護變更歷史（例如誰變更了需求，何時以及為何進行變更）。6.5.3管理可追溯性產品線跟蹤鏈接比單產品的跟蹤鏈接復雜，這是因為產品線中存在著領域工程跟蹤鏈接、應用工程跟蹤鏈接以及領域工程與應用工程之間的跟蹤鏈接。該任務涵蓋了產品線特定的工具和方法能力，以處理復雜性。方法宜支持管理可追溯性，具有以下能力：——分析變更請求對可追溯性的影響；——修訂跟蹤鏈接（例如領域需求和來源之間）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——確認跟蹤鏈接。工具宜支持管理可追溯性，具有以下能力：——維護用于恢復的需求跟蹤鏈接的版本；——更新跟蹤鏈接；——當利益相關方請求時，向特定的利益相關方顯示可追溯性信息。6.5.4管理領域需求版本應用工程可以共享多個版本的領域需求制品。應提供工具來應對這些復雜性。方法宜支持管理領域需求版本，具有以下能力：——指定領域需求制品基線的最新版本；——描述領域需求制品基線之間的差異；——管理歷史版本以便在故障時進行恢復。工具宜支持領域需求的版本管理，具有以下能力：——自動生成版本號；——提供恢復機制；——提供用于管理歷史版本的倉庫；——跟蹤版本控制下的相關制品（需求、模型等）；——隨著時間的推移控制領域需求制品基線的版本。6.5.5記錄和報告狀態在領域需求管理過程中，持續記錄和報告受控制品的狀態和修訂歷史，以便供所有應用參考。方法宜支持狀態記錄和報告，具有以下能力：——管理需求管理記錄和狀態報告，以展示受控制品的狀態和修訂歷史；——記錄領域需求制品的內容和狀態，以便在必要時恢復制品的先前版本；——必要時修改每件制品的狀況和歷史；——報告領域需求制品的狀態。狀態報告應包括需求變更數量、領域需求制品的最新版本、發布標識符以及版本的數量與比較。工具宜支持狀態信息的記錄和報告，具有以下能力：——維護領域需求制品的內容和狀態；——根據分配給用戶角色的權限和責任來控制用戶的訪問；——維護領域需求制品的修訂歷史（管理記錄和狀態報告）。6.5.6管理過程改進該任務專門處理改進領域需求工程生存周期過程。請注意，產品線技術管理的工具和方法中提到了整體產品線過程改進。方法宜支持管理過程改進，具有以下能力：——收集過程改進請求；——評估所實施的領域需求工程過程的優缺點；——基于過程改進請求和評估結果，提出領域需求工程過程改進建議；——制定行動計劃，以實施領域需求工程過程改進；——管理在領域需求工程過程實施中提出的問題。工具宜支持管理過程改進，具有以下能力：——維護領域需求工程過程資產（例如過程描述、過程制品）；GB/TXXXXX—XXXX/ISO/IEC26551:2016——為領域需求工程過程評估提供模板；——為領域需求工程過程改進的行動計劃提供模板。6.5.7管理反饋需要從各種來源收集與領域需求相關的反饋，例如其他領域需求工程服務和應用需求工程服務。該任務應能夠處理來自所有相關來源的各種反饋，并向提供反饋的來源通報所采取或計劃采取的應對措施。方法宜支持從反饋中學習，具有以下能力：——識別反饋來源；——評估反饋的可行性；——處理反饋（如果可對領域需求進行更改，則建立并處理明確的變更請求——返回反饋處理結果。工具宜支持管理反饋，具有以下能力：——建立收集反饋的渠道；——獲取和保存反饋以及關于反饋來源的信息；——更新反饋狀態；——將反饋處理結果通報給反饋源。7需求工程可變性管理需求可變性管理過程宜與領域需求工程并行實施，因為可變性模型會隨著領域和應用需求逐漸澄清和修改。可變性建模始于領域需求獲取子過程，并在整個產品線生存周期中不斷演化。該過程建立并維護產品線的外部可變性，但部分內部可變性可能會被指定。需求工程可變性管理具有以下子過程：——文本需求可變性旨在使用自然語言表達和文檔化需求可變性，使其明確化；——需求模型可變性旨在通過將可變性整合到需求模型中來文檔化可變性；——需求可變性機制旨在對需求可變性機制進行分類；——需求可變性與可變性模型之間的可追溯性旨在建立和維護需求可變性文檔與單獨定義的可變性模型之間的鏈接。7.1文本需求可變性文本需求可變性管理的目的是使用自然語言表達和文檔化需求可變性，并使其明確化。即使使用特定的關鍵字或短語來表達文本需求，文檔化需求可變性仍然為模糊性保留了空間。7.1.1.1輸入該子過程的輸入：文本需求文檔。7.1.1.2輸出該子過程的輸出：定義明確表達需求可變性的文本需求文檔。7.1.1.3任務該子過程的任務如下所述。GB/TXXXXX—XXXX/ISO/IEC26551:2016——使用文本需求定義需求可變性，以說明當需求用自然語言表達時的需求可變性。應明確描述可變點及其變體，包括對其他可變性的影響。——使用文本需求文檔化需求可變性，以增加可變性的結構和關系信息。應文檔化需求可變性，以提供在應用需求工程中選擇或處理變體的方法。7.1.2使用文本需求定義需求可變性該任務的目標是通過特定的關鍵字來表達可變性。應通過添加額外的注釋來明確可變點及其變體。方法宜支持使用文本需求定義需求可變性，具有以下能力：——明確文本需求的可變性；——明確表達可變點及其變體；——描述可變性的影響。工具宜支持使用文本需求定義需求可變性，具有以下能力：——突出顯示可變需求，使其便于區分；——提供明確表達需求可變性的符號。7.1.3使用文本需求文檔化需求可變性這個任務的目標是以文本形式文檔化可變性的結構和關系信息。宜提供在應用需求工程中選擇或處理變體的方法。方法宜支持使用文本需求文檔化需求可變性，具有以下能力：——為文本需求可變性添加結構信息，以便選擇或處理可變性，例如：變體的唯一標識符；——在文本需求可變性之間添加關系信息；——結構化需求可變性，以便處理；——驗證需求可變性文檔的可讀性。工具宜支持使用文本需求文檔化需求可變性，具有以下能力：——使能來自單獨定義的可變性模型的跟蹤鏈接；——提供唯一地識別每個變體的能力。7.2需求模型可變性需求模型可變性管理的目的是明確文檔化需求模型可變性。可變性宜用各種類型的需求模型來表示，包括特征模型、用例模型、狀態轉換模型、序列模型、數據模型等。7.2.1.1輸入該子過程的輸入：需求模型。7.2.1.2輸出該子過程的輸出：定義明確表達需求可變性的需求模型。7.2.1.3任務該子過程的任務如下所述。——使用需求模型定義需求可變性，以明確地表達需求模型需求可變性。在需求模型中描述可變點及其變體和約束。GB/TXXXXX—XXXX/ISO/IEC26551:2016——使用需求模型文檔化需求可變性，以詳細說明需求模型中需求可變性的相關信息，并提供對需求模型中可變性的清晰理解。7.2.2使用（需求）模型定義需求可變性該任務的目標是通過特定的關鍵字或短語來表達可變性。通過增加額外的表達來明確可變點及其變體。方法宜支持使用（需求）模型定義需求可變性，具有以下能力：——明確需求模型需求可變性；——明確表達可變點、其變體和變體的約束；——分別表示功能性或非功能性需求的可變性。工具宜支持使用（需求）模型定義需求可變性，具有以下能力：——提供建模符號以明確表達需求可變性；——提供用于區分功能性和非功能性需求可變性的符號。7.2.3使用需求模型文檔化需求可變性該任務的目標是在需求模型文檔中詳細描述需求可變性，以便將需求可變性整合到需求模型文檔中。通過使用不同的需求模型，例如特征模型、用例模型、狀態轉換模型、序列模型、數據模型等，來文檔化需求可變性。方法宜支持使用需求模型文檔化需求可變性，具有以下能力：——添加對需求模型中需求可變性的詳細說明；——建立以不同方式文檔化的相同需求可變性之間的關聯關系；——添加支持與可變性模型鏈接的粘接器；——整合以不同需求模型文檔化的需求可變性文檔；——驗證需求可變性文檔，以確保文檔的無歧義性。工具宜支持使用需求模型文檔化需求可變性，具有以下能力：——使能來自單獨定義的可變性模型的跟蹤鏈接；——支持整合以不同類型需求模型文檔化的需求可變性文檔。7.3需求可變性機制該子過程的目的是對適用于所關注領域的可變性機制進行分類，以指導需求中可變性機制的選擇，并對分類的可變性機制進行管理。在各種需求模型和文本需求中，通過擴展/包含、原型、標簽或標記等可變性機制表達需求子過程可變性，在需求階段綁定的可變性大多是外部可變性，但也有部分內部可變性可以在需求階段綁定。該子過程涉及與可變性機制相關的需求工程特定的方法和工具的能力。7.3.1.1輸入該子過程的輸入如下所述：——定義所關注的領域；——需求中可變性機制的目錄；——原始可變性模型；——原始決策表。7.3.1.2輸出GB/TXXXXX—XXXX/ISO/IEC26551:2016該子過程的輸出如下所述：——對需求中使用的可變性機制進行分類；——在需求中使用可變性機制的指南已形成文檔；——驗證需求中選定的可變性機制；——進行可變性機制改進；——生成添加了需求特定可變性機制信息的可變性模型；——生成添加了需求特定可變性機制信息的決策表。7.3.1.3任務該子過程任務如下所述：——識別需求可變性機制，即從需求可變性機制目錄中對合適的可變性機制進行分類；——指導需求中可變性機制的使用，為在需求中精確使用可變性機制提供文檔化的指南；——驗證需求中可變性機制的使用情況，旨在監控可變性機制的使用狀態，以提高機制選擇的準確性；——改進需求可變性機制，旨在改進可變性機制的使用和使用支持，使其能夠在需求模型和文本需求中使用。7.3.2識別需求可變性機制這項任務的目標是評審和發現適用于需求和需求制品可變性機制。方法宜支持識別需求可變性機制，具有以下能力：——識別可用于需求制品可變性機制；——對需求和需求制品可變性機制進行分類；——識別添加到原始可變性模型的需求特定可變性機制信息；——識別添加到原始決策模型的需求特定可變性機制信息；——驗證需求中已分類可變性機制的適用性。工具宜支持識別需求可變性機制，具有以下能力：——按類別顯示需求可變性機制；——可對需求可變性機制進行目錄管理；——可修改可變性模型，以添加需求特定的可變性機制信息；——可修改決策模型，以添加需求特定的可變性機制信息。7.3.3指導需求可變性機制的使用該任務的目的是為選擇可變性機制和執行成員產品配置和綁定提供指導。總指南見ISO/IEC26557。這項任務支持具體的指南，其中包含需求工程的具體實踐。方法宜支持指導需求可變性機制，具有以下能力：——為需求工程專門定制可變性機制的指導（見ISO/IEC26557）；——開發可變性機制的使用范例，以確保在需求中準確使用可變性機制。工具宜支持指導需求可變性機制，具有以下能力：——文檔化準確使用需求中可變性機制的指南；——提供需求可變性機制的使用范例。7.3.4驗證需求可變性機制的使用情況該任務的目標是驗證需求中可變性機制的有效性和效率。GB/TXXXXX—XXXX/ISO/IEC26551:2016定義用于驗證可變性機制使用情況的度量標準，并對使用狀態進行測量，適當分析結果，以提供有價值的反饋。方法宜支持驗證需求中可變性機制的使用情況，具有以下能力：——衡量需求中可變性機制分類的有效性和效率；——評審可變性機制的計劃與實際使用狀態；——制定和跟蹤糾正措施。工具宜支持驗證需求中可變性機制的使用情況，具有以下能力：——可自動/半自動收集測量數據；——與相關參與者分享可能的糾正措施。7.3.5改進需求可變性機制該任務的目標是改進在需求制品中使用的、已建立的可變性機制，并支持在需求階段綁定的可變性。根據其使用狀態的分析結果，可以重新組織并改進按分類識別的、實現可變性機制。方法宜支持改進需求可變性機制，具有以下能力：——識別需求中可變性機制的改進項；——實施已識別的改進項；——跟蹤改進項的狀態。工具宜支持改進需求可變性機制，具有以下能力：——文檔化改進項；——與相關參與方分享改進成果。7.4需求可變性與可變性模型之間的可追溯性該子過程的目的是在需求可變性文檔和單獨定義的可變性模型之間建立鏈接。7.4.1.1輸入該子過程的輸入如下所述：——包括需求可變性的需求模型或文本需求文檔；——可變性模型。7.4.1.2結果該子過程的輸出：定義了需求可變性包括其與可變性模型的跟蹤鏈接。7.4.1.3任務該子過程任務：定義需求可變性與可變性模型之間的明確鏈接。建立并保持需求文檔中需求可變性與單獨可變性模型的跟蹤鏈接。7.4.2定義需求可變性與可變性模型之間的明確鏈接該任務的目標是在需求可變性與可變性模型之間建立明確的跟蹤鏈接。方法宜支持定義需求可變性與可變性模型之間的明確鏈接，具有以下能力：——確定可變性模型與需求文檔需求可變性之間的鏈接；——確認需求可變性是否與可變性模型一致；GB/TXXXXX—XXXX/ISO/IEC26551:2016——檢查需求文檔中需求可變性的不同定義是否是一致的。工具宜支持定義需求可變性與可變性模型之間的明確鏈接，具有以下能力：——導入并瀏覽可變性模型；——存儲需求可變性與可變性模型之間的鏈接；——支持需求可變性與可變性模型之間的偏差評估。8需求工程資產管理在需求工程的資產管理中，領域需求工程所產生的制品構成領域資產。需求可變性與共性都作為領域資產進行管理。此外，應用需求工程中具有較高可重用性的制品也可被定義為領域資產。在需求管理中，資產管理為制品增加或開發額外的詳細