# 安全與私隱要求 安全與私隱要求是產品常設要求的一部分，讓已核准的產品義務在不同交付作業中持續適用。本文說明承擔產品負責人或產品經理職責的人，如何結合專業意見與產品脈絡，把要求寫得足夠清楚，供人員與 AI 使用，並在政策、風險及相關要求改變時持續維護。這些經過維護的要求，讓後續作業有依據推導合規的功能規格，再驗證依規格交付的軟體。 這套做法以要求重用的研究為基礎。Christian 與 Mead 指出，有些安全要求過於含糊，無法指導交付；另一些則過於具體，直接指定特定機制。他們的《Security Requirements Reusability and the SQUARE Methodology》探討如何透過通用要求，以及對安全概念的共同理解來支援重用，並提出以重用為重點的 R-SQUARE，作為安全品質要求工程方法 SQUARE 的變體。[^citation-01] 在 AI 輔助交付中，後續工作還必須正確理解要求的適用條件、假設、例外及彼此關係，因此這些內容也要寫清楚。規格優先交付把維護和協調這些知識納入知識系統，讓其他交付作業、人員或 AI 工作階段接手時，仍能使用已確認的解讀。 安全要求說明產品必須如何保護資訊、資產與服務。私隱要求則關注資訊處理及其對人的影響，包括系統按預期運作時仍可能產生的影響。美國國家標準暨技術研究院（NIST）的《Privacy Framework》說明了這種較廣泛的私隱風險觀點。[^citation-02] 兩類要求都會參考適用法律、監管指引、合約、既有組織政策，以及專業風險判斷。[產品常設要求與限制條件](/zh-tw/hub/standing-product-requirements-and-constraints)已定義這些判斷如何形成長期適用的產品義務；本文進一步說明安全與私隱要求的內容、使用方式與審查工作。 本文會以 Cookies 範例貫穿各節，透過網頁應用程式的 cookie 同意管理，說明高層次的私隱義務如何形成反覆適用的產品要求。網頁應用程式可以透過 cookies，也就是由使用者瀏覽器保留的小量資料，記住使用者的偏好，供下次造訪時使用。團隊需要判斷哪些用途必須取得同意，以及使用者同意、拒絕或撤回同意時，應用程式應如何回應。落實這些決定，涉及產品行為、專業判斷、技術控制措施，以及證明使用者選擇已生效的證據。本例假設具備相關專業能力的私隱決策負責人已確認，某一組非必要的偏好 cookies 必須取得同意；用於身分驗證的 cookies 和同意紀錄，則各有已核准的處理方式。團隊透過共用的 cookie 管理元件，在新增功能時持續落實這些決定。 ## 1. 專業權限與產品責任 在這個交付模型中，承擔產品負責人（Product Owner）或產品經理（Product Manager）角色的人，對產品合規負最終責任。大型組織通常設有專職角色；小型團隊則可能由工程師或創辦人兼任。因此，本文所述職責可以由同一人承擔，但仍須明確列出決策權限，以及任何必要的獨立審查安排。無論由誰承擔產品角色，都必須理解適用義務、提供解讀所需的產品脈絡、取得適當的專業意見，並確保已議定的要求反映在規格與驗收決策中。 產品脈絡包括產品提供什麼功能、處理誰的資料、處理目的，以及哪些服務會接收資料。法務或合規專業人員可能熟悉義務，卻不了解這些事實。因此，承擔產品責任的人也要提供這些資訊，並在產品改變時更正。 安全與私隱專業人員評估威脅、私隱影響，以及擬採用的控制措施是否足夠。如有法務與合規專業人員參與，他們會協助判斷哪些義務適用及如何解讀；團隊也可以從外部取得所需專業意見。組織須指定誰有權核准專業判斷、處理解讀爭議，以及接受剩餘風險或規則允許的例外。這樣的分工保留了專業決策權，而產品負責人或產品經理仍須負責把判斷落實到產品。 責任分工也要說明決策如何傳達及接受審查。NIST《Cybersecurity Framework 2.0》可作為相關治理參考：它把網路安全成果分為不同職能，其中 GOVERN 涵蓋風險策略、政策、角色、責任與監督。[^citation-03] 實際準備時，團隊要為每項重大義務找出來源與決策負責人，記錄其權限範圍，並建立把未決問題交由他們處理的途徑。後續交付工作才能取得所需專業意見。 產品責任與適用法律訂明的責任並行。例如，歐盟《一般資料保護規則》（GDPR）把相關義務賦予資料控制者。歐洲資料保護委員會（EDPB）的指引說明了控制者對有效資料保護措施與保障機制的責任。[^citation-04] 適用這套法規的產品團隊，須把相關控制者及其義務納入產品脈絡；其他法律制度可能採用不同的責任分配。框架中的產品負責人或產品經理角色確立交付責任，適用法律則決定產品須處理的法律責任。 專業意見要結合預期行為與實際資料流加以檢視，才能成為可用的產品知識。產品負責人或產品經理把意見與產品脈絡帶入[結構化討論](/zh-tw/hub/requirements-increments-and-structured-discussion)，讓相關參與者釐清適用條件、假設、例外，以及彼此有衝突的義務。AI 可以在討論中整理來源、提出待釐清的問題；專業結論則由具備相應能力的人員審查，並在其權限內確認決策。如果把未經審查的 AI 解讀當成定論，同一錯誤便可能一路傳入規格、實作與測試。 參與者執行业務分析、架構、工程或品質工作時，會運用已核准的判斷來定義行為、設計、實作及證據。在這些活動中，他們是專業判斷的下游使用者，即使同一人也兼任產品管理角色，仍是如此。他們要提供可能需要重新專業評估的事實，也有責任理解與自身工作相關的政策；即使已有控制措施執行日常規則，這項責任仍然存在。 在 Cookies 範例中，產品管理人員說明功能要記住哪些偏好，以及原因。私隱專業人員，以及有需要時參與的法務或合規專業人員，為同意與保留安排的決策提供依據；安全專業人員則評估存取與資料暴露風險。產品管理人員隨後確保已核准的 cookie 行為反映在功能規格與驗收條件中。 ## 2. 產品特定要求的形成與重用 ### 2.1. 組織脈絡與產品解讀 產品團隊根據與自身義務相關的來源，建立適用於產品的權威要求。如果組織維護了政策、標準、控制措施目錄或已核准的模式，組織脈絡層便能提供可重用的輸入，供團隊選取相關來源，再按產品情況調整其應用。若沒有這一層知識，產品負責人或產品經理便直接整理適用來源與專業判斷。[共享知識系統](/zh-tw/hub/shared-knowledge-system)說明了廣泛知識如何與產品特定解讀連接；獨立維護的組織脈絡層，是其中一種可用來源。 解讀的工作，是把義務連到產品為履行義務而必須作出的決策。例如，資料最少化原則仍需要團隊判斷：為達成所述目的，產品究竟需要哪些資料。ENISA 的《Privacy and Data Protection by Design》探討了從原則走向設計的過程，把法律原則連到設計策略與技術措施。[^citation-05] 產品紀錄應保留已核准的解讀、來源與可取得的版本資訊、決策負責人，以及說明如何適用的理由。 組織可以透過 Model Context Protocol（MCP）提供政策儲存庫的存取途徑，讓 AI 工具讀取所連接的資源。在這種安排下，服務提供持續維護的來源，產品特定知識則記錄來源如何適用於軟體。按產品調整過的解讀可以直接用於工作，團隊同時要安排來源檢查與審查，使解讀保持有效。 管治指示列明參與者進行相關工作時必須查閱的知識。在 Cookies 範例中，只要變更涉及同意或 cookie 行為，已核准的要求與實作指引便應納入工作範圍。Skill 可以提供應用這些知識的程序。如果工具會選擇性載入 Skills，必要的閱讀要求與操作規則就應放在適用的管治指示中。團隊也要透過 AI 實際使用的存取途徑，確認它能取得相關來源。 人員同樣需要按工作選取脈絡。產品經理需要了解義務及其對產品的影響；工程師還需要已核准的設計與目前實作。〈共享知識系統〉所述的「按需分層載入上下文」，讓 AI 從較廣泛的脈絡逐步取得當前工作所需的知識。人員也會依專業責任與手上的工作，選取相關知識。 ### 2.2. 清晰程度與重用條件 下一位參與者要能重用要求，就必須理解其含義與適用條件。R-SQUARE 著重建立共同的安全概念，把通用要求定義清楚，讓面對相似威脅的系統能夠採用。[^citation-01] 產品特定的常設要求還要說明，原有推論在什麼情況下成立。在 Cookies 範例中，這包括已分類的偏好 cookies、用途，以及必須取得同意的條件。 以下資訊讓後續人員與 AI 能取得已核准的判斷。它們進一步展開[產品常設要求與限制條件](/zh-tw/hub/standing-product-requirements-and-constraints)的參考結構，可以集中記錄，也可以透過持續維護的連結查閱。 1. **含義與適用條件** 指明要求涵蓋的資料、參與者、用途、能力與運作條件。 2. **必須達成的結果** 清楚寫出義務或限制，讓具備相應能力的參與者能判斷，需要什麼證據才能確認符合要求。 3. **假設與例外** 記錄支持適用判斷的事實、已核准的例外，以及例外的到期或審查條件。 4. **權限與決策依據** 指明誰確認了解讀，以及何處可以查閱來源與決策紀錄。 5. **相關要求** 找出影響同一行為的其他義務，並保留協調重大相互影響後的決定。 6. **驗證與審查** 說明預期證據，以及哪些變更或定期審查需要重新作出判斷。 可用的 cookie 要求會說明：哪些偏好 cookies 可以設定或讀取、用途是什麼、需要符合哪些同意條件，以及條件不再成立時必須如何處理。共用 cookie API 實作了其中部分決定。把義務明確寫出來，團隊日後就能依同一組預期結果評估替代元件。 ### 2.3. 形成要求時的依賴關係 產品意圖提供起始目的。其他產品常設要求可隨產品需要逐漸明確而形成，並在已有相關知識時互相參考。特定決策之前必須確立什麼要求，取決於適用條件，因此準備工作應依重大依賴關係安排；即使產品特定紀錄仍在形成，適用義務也持續有效。 產品管理人員與相關專業人員要找出知識缺口，以及哪些工作必須待缺口解決後才能推進。既有的可靠性、資料、架構或整合知識，可能揭露遺漏的私隱假設；新的私隱要求也可能指出這些領域的相應缺口。依照[知識系統就緒度](/zh-tw/hub/knowledge-system-readiness-for-specification-first-delivery)所述方法，每項重大缺口都需要負責人，以及必須解決的時點。 在 Cookies 範例中，團隊記錄的要求是：只有在所需同意仍有效時，才能為所述用途設定與使用已分類的偏好 cookies；使用者撤回同意時，相關使用必須停止，cookies 也必須移除。相關決策紀錄則列出涵蓋的資料、已核准的解讀，以及同意證據的獨立處理方式，供後續交付作業套用與檢視。 ## 3. 威脅、私隱影響與假設 要求需要保留足夠的分析脈絡，讓具備相應能力的參與者理解其成立原因，並辨識重大變更。安全分析檢視受保護資產與服務面對的威脅；私隱分析則檢視資料在收集、使用、披露、保留及處置過程中，可能對個人造成的影響。 進行這些評估，必須先知道資料流向，以及資料可能如何被處理。LINDDUN 是其中一種私隱分析方法，它把私隱威脅類別連到系統的資料流模型，協助識別要求。[^citation-06] 至於較廣泛的風險評估，NIST《Guide for Conducting Risk Assessments》則整理了威脅、弱點、可能性與影響的評估方式，供決策使用。[^citation-07] 專業人員選擇合適的方法，保留用來說明產品要求的結論，以及結論成立所依賴的條件。分析紀錄必須讓人能檢視這些條件；以下欄位可作為安全或私隱常設要求之決策依據的參考結構。 1. **保護對象與利益** 指明要求所涉及的資訊、資產、服務或個人利益。 2. **威脅或私隱影響** 說明哪些事件、處理活動或濫用可能造成不利結果，以及誰或什麼會受影響。 3. **相關脈絡** 記錄影響判斷的資料類別、用途、接收者、存取關係、保留安排及運作地點。 4. **成立假設** 寫出評估所依賴的事實，並為重大事實提供可查閱的證據。 5. **重新檢視條件** 指明哪些變更或發現，會要求決策負責人重新評估要求或其控制措施。 在 Cookies 範例中，安全分析會考慮偏好資料遭未經授權存取的風險；私隱分析還要檢視超出核准用途所需的保留，以及撤回同意後繼續使用的情況。最初判斷的假設是：偏好 cookies 用於所述的便利功能、只由預定的產品元件使用，並經由已核准的 cookie 管理途徑處理。 若某項交付作業把這些偏好分享給分析服務供應商，就改變了用途或接收者的假設。發現變更的參與者應記錄擬議資料流，並在依賴該判斷的規格獲核准之前，交由產品管理及相關專業人員處理。他們會對照既有要求評估新情況，判斷需要新增或修訂哪些義務。 ## 4. 控制措施的決策與常設要求之間的協調 ### 4.1. 控制目的與剩餘風險 控制措施是為達成安全或私隱結果而選用的措施。其決策紀錄說明預期效果、選擇理由、適用條件、預期證據及限制。剩餘風險則是在考慮所選措施後，評估仍然存在的風險。組織須指定誰有權在適用義務與例外規則允許的範圍內接受該風險。 選擇控制措施，首先要決定產品必須達成什麼保護效果。在選定具體機制之前，私隱設計策略提供了一組有助討論的概念。Hoepman 提出八項涵蓋資料處理與組織流程的策略：最少化、隱藏、分離、彙總、告知、控制、落實及證明。這些策略把早期私隱決策連到設計模式與技術。[^citation-08] 在 Cookies 範例中，減少保留的偏好資料，以及讓使用者能行使選擇權，是兩種不同的控制目的，都需要能達成各自目的的實作。 產品常設要求表達義務與可驗證的結果；相關決策紀錄說明所選措施為何足夠；架構知識、管治指示與技術規格則記載具體設計與操作規則。[產品常設要求規格與決策紀錄](/zh-tw/hub/standing-product-requirements-and-constraints)說明了現行要求與決策依據之間的這種分工。 Cookies 範例採用共用的 cookie 管理元件，讓應用程式碼透過它讀取、設定與移除 cookies。工程指引要求參與者使用該元件，並定義如何新增 cookie 行為。其決策紀錄說明控制措施的涵蓋範圍與限制，包括既有 cookies、第三方程式碼，以及未受涵蓋的執行環境。指定的決策負責人須處理重大的剩餘風險，或在權限內接受該風險。 只要要求、適用條件與成立假設仍有效，元件便可重用。新的資料、用途、接收者或信任關係，都需要重新檢查適用條件。使用元件的經驗有助於判斷其預期運作方式，而本次評估則要確認，它是否仍足以支援擬議用途。 ### 4.2. 要求之間的相互影響 安全與私隱要求和其他產品義務同屬一套產品常設要求系統。紀錄應指出重大依賴關係，以及對同一行為提出的相互衝突要求。相關決策負責人須判斷如何一併滿足適用義務，並記錄議定條件或已獲授權的例外。以下角度列出常見的相互影響，供團隊檢視。 1. **保留安排與證據** 找出哪些紀錄能證明合規、保留理由、誰可以存取，以及各類資料適用的刪除規則。 2. **可靠性與復原** 判斷復原後的資料如何持續遵守目前的授權、保留與撤回同意要求。 3. **架構與整合** 確認控制措施涵蓋哪些接收者、服務與執行環境，包括新加入的資料流。 4. **產品行為** 定義非必要能力無法使用或被使用者拒絕時，產品如何繼續提供服務，例如使用者不願透過 cookies 記住偏好的情況。 在 Cookies 範例中，偏好資料與同意決策的證據各有用途。決策負責人分別指定處理方式，確保撤回同意會終止相關使用，並移除已分類的偏好 cookies；另有正當理由保留的證據，則依其各自獲核准的規則處理。功能規格就能為各類資料寫出議定結果。 團隊應記錄要求之間的關係，以及協調其相互影響後作出的決策。任一要求改變時，便能循這些關係找到另一位決策負責人與受影響規格。因此，重用工作也包括維護多項要求共同依賴的議定內容。 ## 5. 推導交付作業的功能規格 交付作業的功能規格定義可觀察的行為、情境、例外與驗收條件。準備規格的人員應找出適用的產品常設要求，確認其假設與相互影響，並在開始依賴這些知識的實作前處理重大缺口。 Cookies 範例說明這項工作如何從特定法律與產品脈絡出發。對適用英國相關規則的產品而言，英國資訊專員公署（ICO）的指引說明了 cookies 及相關瀏覽器技術的同意要求與例外。[^citation-09] 產品負責人或產品經理與相關專業人員，應依適用指引確認擬議 cookie 用途的分類與義務。本例沿用前文已確立的同意要求，對偏好 cookies 的處理方式屬於已核准的情境假設。 產品常設要求確立撤回同意後必須達成的結果，以及停止相關處理的義務；交付作業規格則定義各種狀態及轉換如何達成該結果。政策或管治指示可以要求規格涵蓋相關狀態，精確行為則寫在功能規格中。以下紀錄說明：在已核准的分類範圍內，交付作業新增另一項非必要偏好時，需要確立什麼內容。 1. **尚未確認取得同意** 功能在不設定或使用已分類偏好 cookies 的情況下運作。 - **需要定義的行為:** 定義尚未取得有效同意時，目前互動如何進行，以及如何處理既有偏好 cookies。 - **驗證:** 觀察初次使用與重新載入頁面的行為，並涵蓋瀏覽器中已有舊 cookies 的情況。 2. **使用者給予同意** 功能只為所述用途記住已核准的偏好。 - **需要定義的行為:** 指明可以設定與讀取哪些 cookies，以及對目前互動的影響。 - **驗證:** 對照已核准的資料與用途，檢查 cookie 值及後續行為。 3. **使用者拒絕同意** 功能不使用非必要的偏好 cookies，並提供已核准的使用體驗。 - **需要定義的行為:** 避免功能透過已分類的 cookies 還原偏好，並定義使用者會得到的體驗。 - **驗證:** 拒絕同意後操作功能，並重新載入頁面。 4. **使用者撤回同意** 終止受影響的使用，並移除已分類的偏好 cookies。 - **需要定義的行為:** 定義撤回同意何時生效、如何移除受影響的 cookies，以及對進行中互動的影響。 - **驗證:** 撤回同意後檢查 cookies 與行為，再重試相關存取途徑並重新載入頁面。 5. **無法取得同意紀錄或紀錄無效** 功能採用尚未取得有效同意時的已核准行為。 - **需要定義的行為:** 定義後續狀態與清理方式，並把同意證據與偏好 cookies 是否存在分開處理。 - **驗證:** 測試同意紀錄缺失或無效的情況；若已核准規則訂有期限，也要測試到期情況。 6. **瀏覽器封鎖 cookies** 功能採用已核准的替代或失敗處理行為，同時維持私隱條件。 - **需要定義的行為:** 定義 cookie 操作失敗或無法執行時，互動如何繼續。 - **驗證:** 測試 cookies 被封鎖的情況，檢查後續行為及任何替代處理。 實際規格還要釐清可能影響結果的時機、進行中工作階段的行為、多分頁影響與失敗處理。分析人員及產品參與者會與相關專業人員共同確立行為；架構師與工程師決定設計及實作責任；品質專業人員則為每項重大條件安排相應驗證。如果實作發現某條 cookie 存取途徑不受已核准的控制措施涵蓋，或遇到相互衝突的保留規則，參與者須把發現交回決策負責人，再依既定權限修訂規格。 ## 6. 驗證與知識系統維護 ### 6.1. 符合要求與驗收 驗證要檢視規格是否涵蓋適用要求，以及軟體是否符合規格。在 Cookies 範例中，程式碼檢查可以確認應用程式碼是否使用共用 cookie 管理元件；行為證據還要確認，使用者的選擇是否在同意紀錄、受影響的 cookies，以及後續功能行為中產生議定結果。 使用者選擇與實際執行之間的關係，已有實證研究檢視。Matte、Bielova 與 Santos 研究了採用 IAB Europe「透明度與同意框架」的 cookie 橫幅；該框架會向參與服務傳達使用者的同意選擇。研究發現，有些實作在使用者作出選擇前，或已明確拒絕後，仍記錄為同意。[^citation-10] 如果只檢查是否有橫幅或共用元件，就會漏掉這種失效情況。因此，驗收本例功能時，需要取得使用者同意、拒絕或撤回同意後相關行為的證據。 承擔驗收責任的角色審查這些證據、偏離項目，以及必要的專業判斷。產品負責人或產品經理仍對產品合規負責，包括要求是否足以處理產品的實際情況。[可信賴交付作業與驗收證據](/zh-tw/hub/trusted-increments-and-acceptance-evidence)進一步說明，如何把要求、責任、驗證與證據連到驗收決策。 ### 6.2. 定期審查與來源變更 安全與私隱要求沿用[產品常設要求與限制條件](/zh-tw/hub/standing-product-requirements-and-constraints)所述的定期審查流程。每項要求，或按既定程序一併管理的一組要求，都須記錄最後實質修改時間、最近一次完成審查的時間與結果、下次預期審查日期，以及審查責任。負責人依義務及其後果選定合適週期；兩次定期審查之間若出現重大變更，則由事件觸發審查。 審查要確認產品脈絡、專業解讀、威脅評估、控制措施與剩餘風險判斷是否仍然成立，也要檢視它們與其他要求的相互影響。例如，對適用 GDPR 的產品而言，EDPB 關於第 25 條的指引要求在整個處理期間，定期審查資料保護措施是否有效。[^citation-04] 團隊應找出自身產品適用的審查義務，並透過共通的產品常設要求流程記錄結果。 產品若依賴持續維護的上游來源，就可以用巡查工作檢查來源，找出可能影響已核准解讀的變更。紀錄須列明查過的來源與版本、時間及結果；專業審查再判斷要求對產品是否仍然有效。來源檢查與專業審查各自保留結果，即使審查確認既有要求仍有效、無須修改內容，也應留下審查紀錄。 若以程式碼儲存庫管理這些知識，每項由政策或法律衍生的產品特定要求，都可以在文件或所連結的要求索引中附上審查中繼資料。`reviewOwner`、`lastReviewedAt`、`nextReviewAt`、`source` 與 `sourceVersion` 等欄位，讓參與者能找到負責人、審查安排與所依據的來源。決策負責人在確認要求時選定週期，並記錄下次審查日期。按既定程序管理文件的平台，也可以維護同等資訊。 排程執行的 AI 工作可以依下列程序準備審查： 1. 讀取要求索引，找出已到期或逾期的審查，並一併查看相關來源變更通知與已記錄的產品變更。若缺少審查日期或無法存取來源，向指定負責人回報。 2. 比較權威來源與現行要求所依據的版本，整理審查摘要，列出來源連結、觀察到的變更、可能受影響的假設或控制措施、相關要求及未決問題。即使沒有發現變更，也要記錄來源檢查結果。 3. 把摘要交給承擔產品責任的人，以及負責相關專業決策的人員。他們評估目前產品脈絡、確認或修訂要求，並記錄已完成的審查、結果、下次審查日期，以及任何後續工作。 這項 AI 工作的權限涵蓋資料查找、比較與修訂建議的準備。排程工作完成，表示審查準備已完成；要求是否仍然有效，則由專業決策確認。在 Cookies 範例中，即使已發表的指引沒有改變，仍可能需要按期審查，因為新功能或第三方整合可能已改變偏好 cookies 的使用方式。 ### 6.3. 變更影響與知識保留 審查發現重大變更時，決策負責人須評估它對要求及相依知識的影響。如果共同假設、控制措施或先前已解決的衝突有所改變，就要檢視相關產品常設要求；如果交付作業規格與既有軟體的行為仍依賴已被取代的解讀，也需要審查。 透過既有決策與交付流程，維護要求及其相依的產品知識。 1. **識別變更** 記錄來源、假設、資料流或威脅的變更，以及控制措施的新發現，並交給相應決策負責人。 2. **評估後果** 判斷要求是否仍然有效，並找出受影響的要求、規格、控制措施、軟體與證據。 3. **確認處理方式** 記錄已核准的解讀、生效條件、剩餘風險決策，以及必要修正或對相依工作的限制。 4. **保留結果** 更新現況知識與連結，記錄審查結果及下次審查日期，並驗證軟體所需的變更。 在 Cookies 範例中，加入分析功能可能需要重新評估私隱、修改產品常設要求與控制措施的涵蓋範圍，以及定義新的功能行為。審查應找出這些後果與負責人，包括先前已驗收軟體所需的修正。要求目前是否有效，以及軟體目前是否符合要求，應分別清楚呈現。 若重大影響仍未釐清，必須先處理，才能據此核准相依工作。審查期間，既有生效日期與例外到期條件仍然適用。實作、驗證與營運中的發現，則透過[交付作業生命週期中的知識收斂](/zh-tw/hub/knowledge-convergence-across-the-increment-lifecycle)回到知識系統。 ## 7. 結語 安全與私隱要求把產品義務、適用條件、假設與預期證據寫得足夠清楚，後續交付工作才能重用其中的專業判斷。規格優先交付讓這些知識貫穿整個過程：承擔產品責任的人結合專業意見與產品脈絡，相關決策負責人確認產品常設要求，各項適用的交付作業再推導履行要求所需的行為與驗證。Cookies 範例展示了這個過程如何把同意義務連到可觀察的行為，涵蓋使用者的不同選擇，以及之後的產品變更。 要持續重用要求，就必須同時維護專業判斷與實作。來源檢查、定期審查，以及已記錄的要求關係，讓團隊能重新評估改變的假設、協調義務，並找出受影響的規格與軟體。AI 可以協助這些工作，相關決策仍由具備相應能力的人員作出。這樣建立的知識系統，既提供未來參與者可採用的已核准解讀，也清楚指出哪些問題需要重新判斷，以及應交由誰處理。 [產品常設要求與限制條件](/zh-tw/hub/standing-product-requirements-and-constraints)對比例原則的說明，可用來決定準備與審查的深度；[知識系統就緒度](/zh-tw/hub/knowledge-system-readiness-for-specification-first-delivery)中的「不熟悉產品的參與者測試」，則檢視另一位具備相應能力的參與者，能否運用這些知識繼續負責任地交付。 [^citation-01]: Christian, T., and Mead, N. R. (2010). *Security Requirements Reusability and the SQUARE Methodology*. CMU/SEI-2010-TN-027. Software Engineering Institute, Carnegie Mellon University. [Report and DOI](https://www.sei.cmu.edu/library/security-requirements-reusability-and-the-square-methodology/). [^citation-02]: National Institute of Standards and Technology. (2020). *NIST Privacy Framework: A Tool for Improving Privacy through Enterprise Risk Management, Version 1.0*. NIST CSWP 01162020. [Full text](https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.01162020.pdf). [^citation-03]: National Institute of Standards and Technology. (2024). *The NIST Cybersecurity Framework (CSF) 2.0*. NIST CSWP 29. [Publication](https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final). [^citation-04]: European Data Protection Board. (2020). *Guidelines 4/2019 on Article 25 Data Protection by Design and by Default*. Version 2.0, adopted October 20, 2020. [Full text](https://www.edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf). [^citation-05]: Danezis, G., Domingo-Ferrer, J., Hansen, M., Hoepman, J.-H., Le Métayer, D., Tirtea, R., and Schiffner, S. (2014). *Privacy and Data Protection by Design: From Policy to Engineering*. ENISA report, December 2014; publication page dated January 12, 2015. [Report](https://www.enisa.europa.eu/publications/privacy-and-data-protection-by-design). [^citation-06]: Deng, M., Wuyts, K., Scandariato, R., Preneel, B., and Joosen, W. (2011). A privacy threat analysis framework: supporting the elicitation and fulfillment of privacy requirements. *Requirements Engineering*, 16, 3–32. [DOI: 10.1007/s00766-010-0115-7](https://doi.org/10.1007/s00766-010-0115-7). [^citation-07]: National Institute of Standards and Technology. (2012). *Guide for Conducting Risk Assessments*. NIST SP 800-30 Rev. 1. [Publication](https://csrc.nist.gov/pubs/sp/800/30/r1/final). [^citation-08]: Hoepman, J.-H. (2014). Privacy design strategies. In *ICT Systems Security and Privacy Protection*, IFIP Advances in Information and Communication Technology, 428, 446–459. [DOI: 10.1007/978-3-642-55415-5_38](https://doi.org/10.1007/978-3-642-55415-5_38). [^citation-09]: Information Commissioner's Office. (2026). *Guidance on the Use of Storage and Access Technologies*. Updated April 29, 2026; accessed September 12, 2026. [Guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/). [^citation-10]: Matte, C., Bielova, N., and Santos, C. (2020). Do cookie banners respect my choice? Measuring legal compliance of banners from IAB Europe's Transparency and Consent Framework. *IEEE Symposium on Security and Privacy*. [Author manuscript](https://arxiv.org/abs/1911.09964).