系統(tǒng)與軟件工程 生存周期過程 需求工程 征求意見稿

1系統(tǒng)與軟件工程生存周期過程需求工程——規(guī)定了在工程活動(dòng)中實(shí)施的所需過程，從而在整個(gè)生存周期內(nèi)產(chǎn)生對(duì)系統(tǒng)/軟件產(chǎn)品（包括——提供了所需和相關(guān)信息項(xiàng)的格式指南?！谏婕叭斯は到y(tǒng)、軟件密集型系統(tǒng)、軟件和硬件產(chǎn)品以及與這些系統(tǒng)和產(chǎn)品相關(guān)的服務(wù)的項(xiàng)——執(zhí)行需求工程活動(dòng)的人員，以確保其對(duì)需求工程過程的應(yīng)用符合GB/T2203——在涉及人工系統(tǒng)、軟件密集型系統(tǒng)、軟件和硬件產(chǎn)品以及與這些系統(tǒng)和產(chǎn)品相關(guān)服務(wù)的項(xiàng)目——執(zhí)行需求工程活動(dòng)的人員，以確保其在需求工程應(yīng)用過程中開發(fā)的信息下列文件中的內(nèi)容通過文中的規(guī)范性引用而構(gòu)成本文件必不可少的條款。其中，注日期的引用文件，僅該日期對(duì)應(yīng)的版本適用于本文件；不注日期的引用文件，其最新版本（包括所有的修GB/T8566-2022系統(tǒng)與軟件工程軟件生存周期過程（ISO/IEC/IEGB/T22032-2021系統(tǒng)與軟件工程系統(tǒng)生存周期過程（ISO/IEC/2注：GB/T19000區(qū)分了兩種類型的屬性：固有存在于某物中的永久性特征；以及產(chǎn)品、過程或系統(tǒng)的指定特征經(jīng)正式核準(zhǔn)的技術(shù)狀態(tài)項(xiàng)的版本，與介質(zhì)無關(guān)，是在技術(shù)狀態(tài)項(xiàng)的生存周期中的特定時(shí)間節(jié)點(diǎn)確業(yè)務(wù)需求規(guī)格說明businessre業(yè)務(wù)或使命需求(3.1.19)（業(yè)務(wù)或使命問題或機(jī)會(huì)的定義、各種概念以及各種解決方案的要求條對(duì)于某一個(gè)組織的一項(xiàng)或一系列行動(dòng)的設(shè)想或意圖，注1：運(yùn)營(yíng)理念經(jīng)常體現(xiàn)在長(zhǎng)期戰(zhàn)略計(jì)劃和年度業(yè)務(wù)計(jì)劃中。），3注2：一個(gè)派生需求通常是在利益相關(guān)方(3.1.28在系統(tǒng)/軟件生存周期過程中，執(zhí)行開發(fā)活動(dòng)（包括需求分析、設(shè)計(jì)、測(cè)試直到驗(yàn)收）的個(gè)人或組），對(duì)于一個(gè)組織的，關(guān)于一個(gè)系統(tǒng)或一組相關(guān)系統(tǒng)的運(yùn)行或一系列運(yùn)行的，設(shè)想或意注：運(yùn)行概念使用一個(gè)或多個(gè)特定系統(tǒng)或與一組相關(guān)的系統(tǒng)，從用戶（3.1.35）和操作方（3.1.18）角度，給出對(duì)想象中的事件或活動(dòng)序列的描述，包括產(chǎn)品或服務(wù)與其環(huán)境和用戶（3.1.35）的交互，以及在4在需方（3.1.1）和供方（3.1.3在系統(tǒng)、產(chǎn)品或服務(wù)的整個(gè)生存周期中識(shí)別、記錄、維護(hù)、溝通、追溯和跟蹤需求（3.1.19）的需求可追溯性requirements需求跟蹤矩陣requirementstracea）（5注：這意味著已對(duì)一個(gè)或一組需求進(jìn)行了評(píng)審，以幫助確保實(shí)現(xiàn)良好需求的特征，并對(duì)需求集進(jìn)行了良好的組織。軟件需求規(guī)格說明softwarereq軟件及其外部接口的基本需求（3.1.19）[功能、性能、設(shè)計(jì)約束（3.1.7）和屬性（3.1.2）]的注：利益相關(guān)方包括但不限于最終用戶（3.1.35）、最終用戶組織、支持者、開發(fā)者（3.1.11）、生產(chǎn)者、培訓(xùn)師、維護(hù)者、處置者、需方（3.1.1）、客戶（3.1.9）、操作方（3.1.18）、供應(yīng)商組織、認(rèn)證者和監(jiān)管機(jī)利益相關(guān)方需求規(guī)格說明stakeholderrequirementsspeci利益相關(guān)方（3.1.28）和與外部環(huán)境關(guān)系的需求（3.1.19）[特征、背景、概念、約束（3.1.7）系統(tǒng)及其運(yùn)行環(huán)境和外部接口的結(jié)構(gòu)化需求（3.1.19）集合[功能、性能、設(shè)計(jì)約束（3.1.7）和6在系統(tǒng)使用期間與系統(tǒng)交互或從系統(tǒng)中獲益的個(gè)人或團(tuán)通過提供客觀證據(jù)對(duì)特定的預(yù)期用途或應(yīng)用要求（3.1.19）已得到注：系統(tǒng)生存周期周境中的確認(rèn)是一組活動(dòng)，確保并獲得系統(tǒng)能夠?qū)崿F(xiàn)其預(yù)期用途、目標(biāo)和目的的信心。建立了注：系統(tǒng)生存周期周境中的驗(yàn)證是一組活動(dòng)，將系統(tǒng)生存周期中的產(chǎn)品與該產(chǎn)品所需的特性進(jìn)行比較。這可能包BABOK：業(yè)務(wù)分析知識(shí)手冊(cè)（BusinessAnalysisBookofKnowledge）BRS：業(yè)務(wù)需求規(guī)格說明（BusinessRequirementsSpecificatiConOps：運(yùn)營(yíng)理念（ConceptofOperaFSM：功能規(guī)模測(cè)量（FunctionalSizeMeasureHIS：人系統(tǒng)集成（HumanSystemsIntegratiMDD：模型驅(qū)動(dòng)開發(fā)（ModelDrivenDevelopment）MOP：性能測(cè)度（MeasuresofPerformancOpsCon：運(yùn)行概念（OperationalCoRTM：需求追蹤矩陣（RequirementsTraceabilityMSRS：軟件需求規(guī)格說明（SoftwareRequirementsSpecifStRS：利益相關(guān)方需求規(guī)格說明（StakeholderRequSyRS：系統(tǒng)需求規(guī)格說明（SystemRequirementsSpecificTBD：待確定（ToBeDetermiTBR：待規(guī)定（TobeTobeSpecTPM：技術(shù)性能測(cè)度（TechnicalPerformanceM4符合性74.1預(yù)期用途本文件為處理需求工程執(zhí)行GB/T22032-2021和GB/T8566-2022的過程提供了指南。本文件還對(duì)實(shí)施這些過程產(chǎn)生的信息項(xiàng)或文件的內(nèi)容和格式提出了規(guī)范性定義和建議。本文件的用戶可以聲稱符合4.2完全符合4.3過程的符合性4.4信息項(xiàng)內(nèi)容的符合性本文件提供了系統(tǒng)、產(chǎn)品或服務(wù)生存周期內(nèi)產(chǎn)生的多個(gè)需求工程信息項(xiàng)的要求。符合本文件信息——生成本文件中規(guī)定的所需信息項(xiàng)；——證明需求工程活動(dòng)期間產(chǎn)生的信息項(xiàng)符合本文件中定義的內(nèi)容要求。本文件中信息項(xiàng)的要求包含在第7章中。本文件中信息項(xiàng)的內(nèi)容要求見第9注1：如果本文件的用戶聲稱完全符合ISO/IEC/IEEE1528注2：在本文件中，為了便于參考，每個(gè)信息項(xiàng)4.5符合性4.5.1過程本文件未對(duì)剪裁生存周期過程作出規(guī)定。GB/T22032-2021附錄A提供了有關(guān)系統(tǒng)生存周期過程剪裁的規(guī)范性指導(dǎo)。GB/T8566-2022附錄A提供了有關(guān)軟件生存周期過程剪裁的規(guī)范4.5.2信息項(xiàng)擇或修改本文件的條款。聲明剪裁文本，并聲明其剪裁合規(guī)性。定制符合性是通過使5概念8本章介紹的概念適用于需求描述本身以及對(duì)其文檔化過程中產(chǎn)生的信息項(xiàng)。這些概念適用于相關(guān)5.2基本要求需求工程是一個(gè)具有跨領(lǐng)域功能的學(xué)科，在需方和供方或開發(fā)人員的領(lǐng)域之間進(jìn)行協(xié)調(diào)，以建立和維護(hù)相關(guān)系統(tǒng)、軟件或服務(wù)要滿足的需求。需求工程涉及發(fā)現(xiàn)、獲取、開發(fā)、分析a)參考已定義的系統(tǒng)、軟件或服b)使利益相關(guān)方（如需方、用戶、客戶、操作方、供方）能夠達(dá)成一致的理解；e)為驗(yàn)證設(shè)計(jì)和解決方案提供5.2.2利益相關(guān)方當(dāng)在需求工程的周境中考慮時(shí)，項(xiàng)目中的利益相關(guān)方因項(xiàng)目而異。至少一組利益相關(guān)方包括用戶或多個(gè)組織具有從該系統(tǒng)中受益的合法權(quán)益。其次，監(jiān)管機(jī)構(gòu)可能有法律、行業(yè)或其他5.2.3將需要轉(zhuǎn)化為需求定義需求始于利益相關(guān)方需要（或目標(biāo)、目的），這些需要經(jīng)過細(xì)化和演變才能成為利益相關(guān)方的有效需求。初始的利益相關(guān)方關(guān)注點(diǎn)不作為利益相關(guān)方要求，因其通常缺乏定義、分析以及可能的一致性和可行性。需求工程使用運(yùn)營(yíng)理念來幫助理解利益相關(guān)方在組織層面的關(guān)注點(diǎn)，并從系統(tǒng)角度來看待系統(tǒng)運(yùn)營(yíng)理念，將利益相關(guān)方從最初的、往往是潛在的需要引導(dǎo)到一組客觀充分、結(jié)構(gòu)化和更當(dāng)相關(guān)系統(tǒng)是整個(gè)系統(tǒng)結(jié)構(gòu)中第二級(jí)或更低層級(jí)的系統(tǒng)元素時(shí)，還需要識(shí)別該層級(jí)利益相關(guān)方的需要和要求。這些需要不僅僅適用于系統(tǒng)結(jié)構(gòu)中最頂層的系統(tǒng)。在做出更低級(jí)別的架構(gòu)或設(shè)計(jì)決策之然后，利益相關(guān)方的系統(tǒng)需求被轉(zhuǎn)換為相關(guān)系統(tǒng)的較低層級(jí)系統(tǒng)元素需求。如果技術(shù)或復(fù)雜性風(fēng)轉(zhuǎn)換可能會(huì)涉及到大量的迭代。同樣的過程也遞歸地應(yīng)用于較低物理層級(jí)的需設(shè)計(jì)和開發(fā)的系統(tǒng)元素，第6章詳細(xì)說明了執(zhí)行利益相關(guān)方和系統(tǒng)需求定義的過程。第7、8和9章包含與記錄需求相關(guān)的信5.2.4需求構(gòu)造9應(yīng)制定結(jié)構(gòu)良好的利益相關(guān)方需求、系統(tǒng)需求和系統(tǒng)元素需求。此舉有助于與利益相關(guān)方進(jìn)行需求確認(rèn)，并有助于確保需求準(zhǔn)確地描述利益相關(guān)a)系統(tǒng)應(yīng)滿足或擁有解決問題、實(shí)現(xiàn)目標(biāo)或解決利益相關(guān)方問題的能該描述提供了區(qū)分需求和這些需求的屬性（條件、假設(shè)和約需求是轉(zhuǎn)換或表達(dá)需要及其相關(guān)約束和條件的文字陳述。需求可以用自然語言或其他形式的語言編寫。如果以自然語言的形式表達(dá)，則文字陳述宜包括一個(gè)主語和一個(gè)動(dòng)詞，以及充分表達(dá)內(nèi)容所需的其他元素。需求應(yīng)說明需求的主題（例如，系統(tǒng)、軟件等）、應(yīng)做什么（例如，d)偏好或目標(biāo)是期望的、非強(qiáng)制性的、非約束性的規(guī)定，使用“宜”。注2：敏捷中的需求可以使用替代方式，如用戶故事，而不明確使用術(shù)語“應(yīng)”。關(guān)于或或條件是為需求規(guī)定的可測(cè)量的定性或定量屬性。條件進(jìn)一步限定了所需的需求，并提供了允許以可確認(rèn)和驗(yàn)證的方式制定和說明需求的屬性。條件可能會(huì)限制設(shè)計(jì)師可以選擇的選項(xiàng)。重要的是將利益相關(guān)方的需要轉(zhuǎn)化為利益相關(guān)方的需求，約束限制了系統(tǒng)工程過程的設(shè)計(jì)解決方案或?qū)崿F(xiàn)。約束可以適用于所有b)物理尺寸限制（例如，控制器應(yīng)安裝在機(jī)可對(duì)需求進(jìn)行排序或加權(quán)，以表明優(yōu)先級(jí)、時(shí)間或相5.2.5獨(dú)立需求的特征a)必要的。需求定義了基本能力、特性、約束和/或質(zhì)量因素。如果這些未包含在需求集中，則將存在能力或特性方面的缺陷，而這些缺陷無法通過實(shí)施其他需求來實(shí)現(xiàn)。該要求目前適用，并沒有隨著時(shí)間的推移而過時(shí)。明確確定了具有計(jì)劃失效期日期或適用日期的需求。b)合適的。需求的具體意圖和詳細(xì)程度適合于其所指的實(shí)體層級(jí)（與實(shí)體層級(jí)相適應(yīng)的抽象層注1：雖然額外的詳細(xì)信息可能仍然很重要，但這些信息以其他形式記錄和傳達(dá)，如5.2.8中的需求屬性（例如，基本原理），以幫助設(shè)計(jì)和實(shí)現(xiàn)。此外，在需求中包含設(shè)計(jì)解決方案會(huì)產(chǎn)生潛在設(shè)計(jì)解決方案可能被忽略或消除的風(fēng)險(xiǎn)。例如，說明表達(dá)準(zhǔn)確的業(yè)務(wù)系統(tǒng)集或可購(gòu)買而非制造的系統(tǒng)的需求，說明概念系統(tǒng)中項(xiàng)目的差d)完整的。需求充分描述了滿足實(shí)體需求所需的必要能力、特征、約束或質(zhì)量因素，而不需要其g)可驗(yàn)證的。需求的結(jié)構(gòu)和措辭應(yīng)確保其實(shí)現(xiàn)能夠在需求存在的水平上得到證明（驗(yàn)證）并使客5.2.6一組需求的特征對(duì)于利益相關(guān)方、系統(tǒng)和系統(tǒng)元素需求的集合，要考慮一些特定的特征，而不是針對(duì)任何單獨(dú)的需求。這些需求集提供了一個(gè)符合利益相關(guān)方意圖和約束的一致解決方案。系統(tǒng)、軟件或服務(wù)的每組素，而無需進(jìn)一步的信息。此外，集合不包含任何“待決定（TBD）”、“待規(guī)定(TBS)”或“待解決(TBR)”子句?！癟Bx”詞組的解決可能是迭代的，“TBx”項(xiàng)目有一個(gè)可接受的時(shí)間注2：在需求定義的演變過程中，通常需要包括TBx名稱，因?yàn)檫^程由系統(tǒng)分析結(jié)果和權(quán)衡決定通知。然注3：經(jīng)修改的開源軟件通常具有所關(guān)注的系統(tǒng)中未使用的現(xiàn)有功能。對(duì)于集成系統(tǒng)、系統(tǒng)體系和包含COTS組b)始終如一。需求集包含唯一的單個(gè)需求，這些需求與集合中的其他需求不沖突或重疊，并且單位和測(cè)量系統(tǒng)是同質(zhì)的。需求集合中使用的術(shù)語是一致的，即在整個(gè)需求集合中使用相同的術(shù)c)可行。整套需求可以在實(shí)體約束（例如成本、進(jìn)度、f)能夠被驗(yàn)證。滿足需求集將導(dǎo)致在約束條件下（例如，成本、進(jìn)度、技術(shù)、仔細(xì)檢查這些特性的需求集對(duì)于避免生存周期內(nèi)的需求變化和增長(zhǎng)（“需求蠕變”）至關(guān)重要，需求應(yīng)說明“需要什么”，而不是“如何”。需求宜說明所關(guān)注的系統(tǒng)需的設(shè)計(jì)決策。然而，隨著需求在系統(tǒng)的各個(gè)層級(jí)上進(jìn)行分配和分解，可以確認(rèn)在更高層級(jí)上定義的設(shè)計(jì)決策/解決方案架構(gòu)。這是需求、架構(gòu)和設(shè)計(jì)過程的迭代和遞歸應(yīng)用程序的一應(yīng)避免使用含糊和籠統(tǒng)的術(shù)語，以防導(dǎo)致需求往往難以驗(yàn)證，甚至不可能驗(yàn)證，或者可能）；）；）；d)歧義術(shù)語，如副詞和形容詞（如“幾乎總是”、“重要”、“最），）；）；）；i)不完整的參考文件（未指定參考文件的日期和版本號(hào)；未僅指定參考文件的適用部分以限制有關(guān)需求的所有假設(shè)均應(yīng)在5.2.8中與需求相關(guān)的需求屬性之一(例如，基本原理)或隨附的文件中5.2.8需求屬性為了支持需求分析，格式良好的需求宜包括定義的描述性屬性，以幫助識(shí)別解和管理需求。屬性信息宜與所選需求存儲(chǔ)庫(kù)中的需求相關(guān)需求屬性示例a)標(biāo)識(shí)。每個(gè)需求都應(yīng)被唯一標(biāo)識(shí)（即編號(hào)、名稱標(biāo)簽、助記符）。聯(lián)系和關(guān)系，也可以與標(biāo)識(shí)分開。唯一標(biāo)識(shí)符有助于需求追蹤。一旦分配，標(biāo)識(shí)是唯一的，b)版本號(hào)（以及需求版本的指示）。這是為了確保實(shí)現(xiàn)正確的需求版本，并c)所有者。維護(hù)需求的組織人員或元素，有權(quán)對(duì)該需求發(fā)表意見，批準(zhǔn)需求變更，并報(bào)告需求d)利益相關(guān)方優(yōu)先級(jí)。宜確定每個(gè)需求的優(yōu)先級(jí)。這可以通過潛在利益相關(guān)方之間的協(xié)商一致過程來確定。在適當(dāng)情況下，可使用1-5等量表或高、中、低等簡(jiǎn)單方案來優(yōu)先級(jí)。優(yōu)先級(jí)并不意味著某些要求是不必要的，但可能表明在需要就替代品作出決定時(shí)，哪些要求是權(quán)衡空間的候選要求。優(yōu)先化需要考慮需要需求的利益相關(guān)方。這有助于權(quán)衡需e)風(fēng)險(xiǎn)。根據(jù)風(fēng)險(xiǎn)因素分配給每個(gè)需求的風(fēng)險(xiǎn)值。有風(fēng)險(xiǎn)的需求包括不具備格式良好的需求應(yīng)），實(shí)體需要無法實(shí)現(xiàn)（系統(tǒng)驗(yàn)證失敗）。風(fēng)險(xiǎn)還可以解決技術(shù)、進(jìn)度、成本、政治等方面的可行性/可達(dá)性。如果滿足需求所需的技術(shù)是新的，成熟度較低，則風(fēng)險(xiǎn)高于在其他類似項(xiàng)目f)原理。應(yīng)掌握確定每個(gè)需求的基本原理?；驹硖峁┝诵枰撔枨蟮睦碛桑ǜ颍⒅赋隽巳魏沃С中苑治?、權(quán)衡研究、建模、模擬或其他實(shí)質(zhì)性g)困難。宜指出每項(xiàng)需求的假定難度（例如，簡(jiǎn)單/標(biāo)稱/困難）。h)類型。需求在意圖和所代表的屬性種類上有所不同。類型屬性的使用有助于識(shí)別相關(guān)需求，需求類型屬性示例a)功能/性能。功能需求描述系統(tǒng)或系統(tǒng)元素功能或系統(tǒng)將執(zhí)行的任務(wù)。性能是功能的一個(gè)屬性。性能需求本身就是一個(gè)不完整的需求。性能通常是定b)接口。接口需求定義了系統(tǒng)如何與外部系統(tǒng)交互（外部接口），或系統(tǒng)內(nèi)的系統(tǒng)元素（包括人的元素）如何相互交互（內(nèi)部接口）。外部接口要求在系統(tǒng)、軟件或服務(wù)與項(xiàng)目外部世界程要求包括：遵守國(guó)家法律和地方法規(guī)，包括環(huán)境法、行政要求、需方/供方關(guān)系要求和具體工作指令。過程需求也可能由公司方針或?qū)嵺`強(qiáng)加給項(xiàng)目。系統(tǒng)或系統(tǒng)元素實(shí)施過程需求，如指定特定設(shè)計(jì)方法，通常在項(xiàng)目協(xié)議文檔（如合同、工作說明書和質(zhì)量計(jì)劃）中獲得。性、可攜帶性、可重用性、可靠性、可維護(hù)性和安全性。在開始要求活動(dòng)之前，應(yīng)識(shí)別質(zhì)量要求的種類（例如，“能力”）。這宜根據(jù)正在開發(fā)e)可用性/使用質(zhì)量要求（針對(duì)用戶性能和滿意度）。為系統(tǒng)設(shè)計(jì)和評(píng)估提供依據(jù)，以滿足用戶需要?？捎眯?使用質(zhì)量需求是與系統(tǒng)的總體需求規(guī)格說明一起開發(fā)的，并構(gòu)成系統(tǒng)總體注2：GB/TSQuaRE標(biāo)準(zhǔn)，特別是GB/T25000.30f)人為因素要求。在安全性、性能、有效性、效率、可靠性、可維護(hù)性、健康、幸福感和滿意度方面，說明與人類用戶（以及受使用影響的其他利益相5.3實(shí)際考慮事項(xiàng)迭代和遞歸兩種形式過程的應(yīng)用，對(duì)于應(yīng)用本文件中定義的過程是必不可少的和有用的。過程的迭代應(yīng)用當(dāng)在系統(tǒng)的同一層級(jí)上重復(fù)應(yīng)用同一過程或過程集時(shí)，該應(yīng)用稱為迭代應(yīng)用。迭代不僅是適當(dāng)?shù)?，而且是預(yù)期的。通過應(yīng)用一個(gè)或一組過程創(chuàng)建新信息。通常，這些信息的形式是關(guān)于需求、分析的風(fēng)險(xiǎn)或機(jī)遇的問題。此類問題應(yīng)在完成一個(gè)或一組過程的活動(dòng)之前解決。當(dāng)重新應(yīng)用活動(dòng)或過程可以解決問題時(shí)，這樣做很有用。在將下一個(gè)過程或一組活動(dòng)應(yīng)用于所關(guān)注的系統(tǒng)之前，可能需要迭代來確過程的遞歸應(yīng)用當(dāng)同一組過程或同一組過程活動(dòng)應(yīng)用于系統(tǒng)結(jié)構(gòu)內(nèi)連續(xù)層級(jí)的系統(tǒng)元素時(shí)，應(yīng)用程序形式稱為遞歸。一個(gè)應(yīng)用程序的結(jié)果用作系統(tǒng)結(jié)構(gòu)中下一個(gè)較低（或較高）系統(tǒng)的輸入，以獲得更詳?shù)慕Y(jié)果集。這種方法為系統(tǒng)結(jié)構(gòu)中的連續(xù)系統(tǒng)增加了價(jià)值。圖2說明了從上到下將流程遞歸應(yīng)用到系統(tǒng)的過程。利益相關(guān)方需求定義過程只能應(yīng)用于所關(guān)注的系統(tǒng)層級(jí)。然而，需求、架構(gòu)和設(shè)5.3.2需求工程中的迭代和遞歸的層級(jí)上定義和記錄需求陳述，而不僅僅是整個(gè)所關(guān)注的系統(tǒng)。將系統(tǒng)需求分配或分發(fā)到系統(tǒng)元素可以實(shí)現(xiàn)這一點(diǎn)。將需求分配給系統(tǒng)元素的活動(dòng)是架構(gòu)定義過程的一部分，與系統(tǒng)架構(gòu)的定義并行進(jìn)行。在需求過程和生存周期中的其他過程（如架構(gòu)、設(shè)計(jì)）之間可能存在多次迭代，以解決需求和架構(gòu)之a(chǎn))需求分析中、分析活動(dòng)之間有目的的迭代；b)從下游活動(dòng)到需求分析的計(jì)劃迭代，因?yàn)轭A(yù)測(cè)的、顯著的、需求的真實(shí)變化率反映了需要的c)從下游活動(dòng)到需求的計(jì)劃內(nèi)或計(jì)劃外迭代，因?yàn)榭尚行院推胶鈫栴}由技術(shù)或?qū)嵤﹩栴}引起的d)由于其他解決方案問題，如非開發(fā)系統(tǒng)元素的變更或缺陷所關(guān)注的系統(tǒng)的設(shè)計(jì)創(chuàng)建了對(duì)系統(tǒng)元素的要求，而系統(tǒng)元素的設(shè)計(jì)創(chuàng)建了對(duì)較低物理系統(tǒng)元素的要求，依此類推。因此，本文件中所述的需求工程活動(dòng)可以并且通常宜應(yīng)用于逐步從屬的解決方案元架構(gòu)設(shè)計(jì)的主要目標(biāo)之一是確定如何劃分系統(tǒng)；也就是說，如何識(shí)別哪些需求宜分配給哪些系統(tǒng)元素。在定義系統(tǒng)元素時(shí)，宜創(chuàng)建額外的需求聲明（稱為派生需求），以定義系，從而在系統(tǒng)元素的較低抽象層級(jí)的上下文中提供必要的清晰性，或指定系統(tǒng)元素的設(shè)計(jì)約束或性此外，在架構(gòu)或設(shè)計(jì)演變的某些部分發(fā)展之前，無法導(dǎo)出某些需求。一些要求取決于幾個(gè)系統(tǒng)元素如何相互操作。例如，系統(tǒng)的信息吞吐量取決于系統(tǒng)硬件、軟件、人員動(dòng)作和環(huán)境的交互。需求、架構(gòu)和設(shè)計(jì)過程的遞歸和迭代應(yīng)用程序用于獲得這經(jīng)驗(yàn)豐富的工程師通常能夠識(shí)別現(xiàn)有或現(xiàn)成的解決方案在哪里可以適應(yīng)系統(tǒng)元素的實(shí)現(xiàn)。分配給這些注：6.3.3詳細(xì)說明了定義需求的過程，包括如何應(yīng)用迭代本條通過說明項(xiàng)目中的典型應(yīng)用程序類型，描需求過程及其結(jié)果規(guī)格說明取決于定義需求的系統(tǒng)的范圍。要開發(fā)或改變的系統(tǒng)或系統(tǒng)元素的需求受制于業(yè)務(wù)或組織運(yùn)作的組織級(jí)需求。系統(tǒng)或系統(tǒng)元素的需求逐步分配到較低級(jí)別的系統(tǒng)。系統(tǒng)范注1：即使業(yè)務(wù)一詞可用于公共部門等非營(yíng)利組織，本文件的用戶也可以根據(jù)用戶環(huán)境將業(yè)務(wù)一詞替換為組織或組業(yè)務(wù)需求規(guī)格說明（BRS）、利益相關(guān)方需求規(guī)格說明（StRS）、系統(tǒng)需求規(guī)格說明（SyRS）和軟件需求規(guī)格說明（SRS）旨在表示不同的需求信息項(xiàng)集。規(guī)格說明對(duì)應(yīng)于圖3中的需求，如下所示：BRS–業(yè)務(wù)需求（業(yè)務(wù)管理層級(jí)StRS—利益相關(guān)方需求（業(yè)務(wù)運(yùn)營(yíng)層面SyRS—系統(tǒng)需求；SRS—軟件需求。這些信息項(xiàng)可以迭代或遞歸地應(yīng)用于多個(gè)規(guī)格說明（實(shí)例）。圖4中說明了需求過程注2：在某些情況下，項(xiàng)目不是由業(yè)務(wù)需求驅(qū)動(dòng)的，而是由任務(wù)需求驅(qū)動(dòng)的。在這種情況下，可以考慮任務(wù)需求規(guī)運(yùn)營(yíng)理念（ConOps）和系統(tǒng)運(yùn)行概念（OpsCon）有助于從組織中的各個(gè)利益相關(guān)方處獲取需求，并作為溝通和分享組織意圖的實(shí)用手段。在組織層面，ConOps解決了領(lǐng)導(dǎo)層預(yù)期的組織運(yùn)作方式。ConOps可能將一個(gè)或多個(gè)系統(tǒng)的使用稱為“黑箱”。OpsCon從用戶的角度解決了特BRS、StRS、SyRS、SRS、ConOps和OpsCon中表示的信息項(xiàng)是相互依賴的。這些項(xiàng)目的開發(fā)需要互不同類型的系統(tǒng)可以為其包含的各種需求提供并行文檔。但是，一般來說，需求文檔將從BRS、StRS和SyRS開始，包括軟件規(guī)格說明以及硬件和接口規(guī)格根據(jù)對(duì)GB/T22032-2021和GB/T8566-2022中一項(xiàng)或兩項(xiàng)的遵守情況，項(xiàng)目應(yīng)實(shí)施GB/T22032-2021和GB/T8566-2022中定義的以下c)系統(tǒng)需求定義過程（GB/T22032-2021中6.4.3）或系統(tǒng)/軟件需求定義過程（GB/T8566-與本文件相關(guān)的原始GB/T22032-2021和GB/T8566-2022,為避免過度重復(fù)，GB/T8566-20222)利益相關(guān)方需要和需求定義過程；這三個(gè)過程產(chǎn)生了一組基線需求，這些需求將導(dǎo)入到架構(gòu)和設(shè)計(jì)過程，配、分解并跟蹤到系統(tǒng)元素。架構(gòu)和設(shè)計(jì)過程還包括需求分配，以啟動(dòng)需求過程的遞歸和迭代的應(yīng)用。這應(yīng)用了ISO/IEC/IEEE24748-1中所述的項(xiàng)目系統(tǒng)生存周期模型定義。架構(gòu)和設(shè)計(jì)過程包括需求的分組織戰(zhàn)略通常包括組織的預(yù)期方向和業(yè)務(wù)或使命目標(biāo)，包括應(yīng)解決的任何問題或機(jī)遇。通過審查與組織業(yè)務(wù)或使命相關(guān)的問題和機(jī)遇，組織可以識(shí)別現(xiàn)有能力、系統(tǒng)、產(chǎn)品或服務(wù)中的缺陷或差距。該策略包括開展業(yè)務(wù)或使命分析所需的方法、里程碑、資源和具體考慮因或使命需要得到詳細(xì)闡述并正式成為業(yè)務(wù)/使命需求。這還包括用于識(shí)別問題空間識(shí)別和計(jì)劃為了支持業(yè)務(wù)或使命分析所需要的使能系使能系統(tǒng)或服務(wù)有助于系統(tǒng)的生存周期活動(dòng)。就業(yè)務(wù)或使命分析而言，包括組織的業(yè)務(wù)系統(tǒng)和存儲(chǔ)庫(kù)、業(yè)務(wù)開發(fā)和市場(chǎng)分析資源，以及為問題空間和解決方案空間的評(píng)估和分析提供洞察力這可能包括對(duì)企業(yè)內(nèi)部或外部的業(yè)務(wù)數(shù)據(jù)系統(tǒng)在相關(guān)權(quán)衡空間因素的周境中分析客戶投訴、問題和機(jī)在為解決方案類別的識(shí)別和評(píng)估做準(zhǔn)備時(shí)，這項(xiàng)任務(wù)與理解已識(shí)別的問題或機(jī)遇的驅(qū)動(dòng)因素相關(guān)。重點(diǎn)是任務(wù)需求、業(yè)務(wù)機(jī)會(huì)、能力的變化方面，某些質(zhì)量或性能方面的改進(jìn)，或效率方面的一些提高。權(quán)衡空間因素是確定備選方案可行性的最關(guān)鍵標(biāo)準(zhǔn)。這些因素根據(jù)使命或業(yè)務(wù)機(jī)會(huì)的重要程度來定義問題。標(biāo)準(zhǔn)可以是技術(shù)參數(shù)，如有效性度量，也可以是業(yè)務(wù)參數(shù)，如市場(chǎng)份注：質(zhì)量改進(jìn)包括人身財(cái)產(chǎn)安全性、信息安全性、可訪問性和可用性。性能改進(jìn)包括可靠性、用戶滿意度和服務(wù)每項(xiàng)分析任務(wù)都宜從機(jī)會(huì)或問題的簡(jiǎn)明陳述開始。雖然業(yè)務(wù)或使命管理層可能會(huì)發(fā)現(xiàn)很難簡(jiǎn)明扼要地定義問題或機(jī)遇，但如果問題或機(jī)遇的所有者無法在一開始就簡(jiǎn)明扼要地表達(dá)出來，則后續(xù)分析很可能失敗。在一些組織中，問題或機(jī)遇可以用一個(gè)簡(jiǎn)明的陳述來描述，有時(shí)稱為使業(yè)務(wù)或使命管理準(zhǔn)備一些初步的生存周期概念，這些概念由業(yè)務(wù)運(yùn)營(yíng)層的利益相關(guān)方在隨后的利益相關(guān)方需要和需求定義過程中詳細(xì)闡述和細(xì)化。典型的生存周期概a)OpsCon概述了在組織預(yù)期運(yùn)營(yíng)的背景下系統(tǒng)解決方案(新的或發(fā)展的)的運(yùn)營(yíng)方面的內(nèi)容。b)獲取概念描述系統(tǒng)解決方案的獲取方式，包括利益相關(guān)方參與、解決方案來源、需求定義、d)支持概念描述部署系統(tǒng)解決方案后支持系統(tǒng)解決方案所需的支持基礎(chǔ)設(shè)施和人力考慮。支持e)退役概念描述系統(tǒng)停止運(yùn)行和退役的方式，包括處理過程中使用的或由此產(chǎn)生的所有有害物由于這些是生存周期概念的典型示例，也可以創(chuàng)建其他示例來處理生存周期的特定焦點(diǎn)。生存周注：最終的系統(tǒng)解決方案可以是新系統(tǒng)、現(xiàn)有系統(tǒng)或系統(tǒng)集的演變、對(duì)現(xiàn)有系統(tǒng)或系統(tǒng)集的操作變更，或這些的本活動(dòng)確定并描述可解決問題或機(jī)遇的解決方案類別。在需求工程的早期階段，業(yè)務(wù)或使命管理需要謹(jǐn)慎地用邏輯術(shù)語描述需要，也就是說，用問題域（業(yè)務(wù)任何問題域，通常在解決域中都有一系列潛在的解決方案類。每個(gè)備選解決方案類將代表一組解決方案，這些解決方案可能代表完全不同的設(shè)計(jì)類型，甚至是不同類型的項(xiàng)目。因此，可行性分析是縮小解決方案范圍的關(guān)鍵步驟，以便能夠有效地管理后續(xù)項(xiàng)根據(jù)可用資源（如資金、時(shí)間、人員和材料）考慮可行的備選方案。權(quán)衡空間因素在一套評(píng)估參數(shù)和決策標(biāo)準(zhǔn)中發(fā)揮著重要作用。權(quán)衡空間因素是確定替代解決方案類別可行性的最關(guān)鍵標(biāo)準(zhǔn)。這些因素根據(jù)任務(wù)或業(yè)務(wù)機(jī)會(huì)的重要程度來定義問題。標(biāo)準(zhǔn)可以是技術(shù)參數(shù)，如有效性度量務(wù)參數(shù)，如市場(chǎng)份額。關(guān)于備選方案權(quán)衡研究和評(píng)估的制定和實(shí)施，請(qǐng)參考GB/T22032-2021中6.3.4和6.4.6或GB/T8566-2022中6.3.4有關(guān)執(zhí)行決策分析（權(quán)衡研究）和在備選方案中做出決策的信息，請(qǐng)參考GB/T22032-2021中宜建立和維護(hù)需求可追溯性，以記錄業(yè)務(wù)需要和需求是如何滿足業(yè)務(wù)問題和機(jī)遇的，以及是如何與首選替代解決方案類和利益相關(guān)方需要和需求相關(guān)的。需要在整個(gè)系統(tǒng)生存周期以及以后獲取、在追蹤和維護(hù)業(yè)務(wù)和使命需求。使用需求管理工具可以促進(jìn)這一過程。關(guān)于可追溯性應(yīng)用的更多討論見關(guān)鍵信息項(xiàng)和工件將包括初步生存周期概念，包括：Op退役概念。此外，權(quán)衡研究報(bào)告和支持性分析也可能被視為關(guān)鍵信利益相關(guān)方需要和需求定義過程的目的，是定義利益相關(guān)方對(duì)系統(tǒng)的需求，此系統(tǒng)能夠在定義該過程定義了在整個(gè)系統(tǒng)生存周期內(nèi)涉及的利益相關(guān)方[或利益相關(guān)方類(集)]及其需要。對(duì)這些需要進(jìn)行分析，并將其轉(zhuǎn)換到一個(gè)共同的利益相關(guān)方需求集合。此集合表述系統(tǒng)與其運(yùn)行環(huán)境之h)利益相關(guān)方需要和要求定義過程所需的所有使能系項(xiàng)目應(yīng)根據(jù)與利益相關(guān)方需要和需求定義過程相關(guān)準(zhǔn)備利益相關(guān)方需要和需最好識(shí)別系統(tǒng)生存周期的所有階段，然后識(shí)別在整個(gè)系統(tǒng)生存周期中擁有關(guān)方或利益相關(guān)方類。從利益相關(guān)方那里獲得的需求可能取決于利益相關(guān)方在組織中的角色、責(zé)任和地位。識(shí)別在所需產(chǎn)品或服務(wù)中扮演角色或感興趣的所有利益相關(guān)方類。然后識(shí)別對(duì)目標(biāo)、戰(zhàn)略、運(yùn)營(yíng)和目標(biāo)體系有重大影響的利益相關(guān)方。隨著對(duì)所需產(chǎn)品或服務(wù)的了解越來越多，利益相關(guān)方類的列表通常會(huì)隨著時(shí)間的推移而修改。應(yīng)識(shí)別每個(gè)利益相關(guān)方類的代表，并包括多層級(jí)的觀點(diǎn)。僅從一個(gè)利益相關(guān)方類或一個(gè)層級(jí)收集的信息角度單一可能存在偏見。有代表性的利益相關(guān)方是必要的，以提該策略包括誘導(dǎo)和獲取利益相關(guān)方要求并將其轉(zhuǎn)化為利益相關(guān)方需求所需的方法、里程碑、資源和具體考慮因素。這包括如何處理對(duì)立的利益。在處理對(duì)立的利益相關(guān)方要求時(shí)，首先尋找對(duì)需求子不同的或?qū)α⒌睦嫦嚓P(guān)方需要可能會(huì)引起解決方案可能需要適應(yīng)需求的變體的實(shí)現(xiàn)，這些變體可能是解決方案的操作、邏輯或物理方面的變體。該策略解決了如何處理各種各樣的、可能相互對(duì)立的需使能系統(tǒng)或服務(wù)有助于系統(tǒng)的生存周期活動(dòng)。在利益相關(guān)方這還可以包括工具和存儲(chǔ)庫(kù)，這些工具和存儲(chǔ)庫(kù)維護(hù)有關(guān)系統(tǒng)的信息，這些系統(tǒng)在接口處提供輸入或這可能包括對(duì)企業(yè)內(nèi)部或外部的業(yè)務(wù)數(shù)據(jù)系統(tǒng)或其他資源的預(yù)定或指在運(yùn)營(yíng)理念和初步生存周期概念內(nèi)定義使用的ConOps描述了一個(gè)組織對(duì)一項(xiàng)行動(dòng)或一系列行動(dòng)的假設(shè)或意圖。ConOps通常包含在長(zhǎng)期戰(zhàn)略計(jì)劃ConOps提供了界定操作空間、系統(tǒng)功能、接口和操作環(huán)境的基礎(chǔ)。有時(shí)，使用周境描述獲取使用周境（見ISO/IEC25063）。初步生利益相關(guān)方需要的識(shí)別包括直接從利益相關(guān)方那里提取需要，基于領(lǐng)域知識(shí)和的利益相關(guān)方需要，以及記錄以往活動(dòng)的差距。需要通常包括效能指標(biāo)。功能分析通常用于輔助提取有助于誘導(dǎo)出和識(shí)別非功能性需求的質(zhì)量需求，這些需求通常是隱含的利益相關(guān)方需使用決策管理過程（GB/T22032-2021，6.擇。其他過程可用于提供評(píng)估和選擇的洞察力，例如測(cè)量過程（GB/T22032-2021中的6.3.7或GB/T8566-2022中的6.3.7）以提供定量洞察力，系統(tǒng)分析過程（GB/T22032-2021，6.4.6或GB/T8566-2022中的6.4.6）提供特定參數(shù)或風(fēng)險(xiǎn)管理過程（GB/T22032-2021中的6.3.5或GB/T8566-2022中的6.3.5）的分析結(jié)果，以深入了解與需要相關(guān)的技術(shù)、成本、進(jìn)度或其他風(fēng)險(xiǎn)在大多數(shù)系統(tǒng)中，可能有許多需要來源，最終也可能是需求來源，因此識(shí)別并評(píng)估對(duì)系統(tǒng)的影響是至關(guān)重要的。需要處理的一些共同來源和問題包a)目標(biāo)。術(shù)語“目標(biāo)”（有時(shí)稱為“業(yè)務(wù)關(guān)注點(diǎn)”或“關(guān)鍵成功因素”）指的是系統(tǒng)層目標(biāo)。目標(biāo)為一個(gè)系統(tǒng)提供了動(dòng)力，但往往是模糊不清的。評(píng)估目標(biāo)的價(jià)值（相對(duì)于優(yōu)先級(jí)）c)運(yùn)行場(chǎng)景。是否有任何需要考慮的特殊場(chǎng)景？場(chǎng)景可用于定義運(yùn)行概念，并限制系統(tǒng)產(chǎn)品、預(yù)期操作環(huán)境和接口系統(tǒng)、平臺(tái)或產(chǎn)品的預(yù)期用途范圍。場(chǎng)景有助于識(shí)別可能被忽略的需求。將場(chǎng)景分解為更小的部分有助于揭示可能導(dǎo)致識(shí)別需求的活動(dòng)?！吧械囊惶臁狈治鲈试S分析員在典型的使用周期中瀏覽系統(tǒng)的使用情況。這種類型的分析可能從傳統(tǒng)結(jié)構(gòu)化系統(tǒng)思維以外d)運(yùn)行環(huán)境和使用周境-需求源自系統(tǒng)/軟件產(chǎn)品將在其中運(yùn)行的環(huán)境。系統(tǒng)/軟件會(huì)在高溫或低環(huán)境的其他方面（威脅和互操作系統(tǒng)）也可能導(dǎo)致對(duì)系統(tǒng)的需求。這些會(huì)極大地影響系統(tǒng)的可g)有效性。系統(tǒng)在執(zhí)行其任務(wù)時(shí)應(yīng)具有多大的有效性/效率？有效性的適用措施是什么？系統(tǒng)是i)組織環(huán)境。需要許多系統(tǒng)來支持組織的注2：很少有系統(tǒng)不存在與使用、用戶、操作員、維護(hù)人員或某些人為系統(tǒng)問題源相關(guān)的重大風(fēng)險(xiǎn)。有關(guān)使用系統(tǒng)可能導(dǎo)致的傷害類型的說明，參見ISO9241-220:2注3：有關(guān)可訪問性的更多信息，參見ISO/IECTR2注4：有關(guān)用戶需要的更多信息，參見ISO/IEC25064；有關(guān)識(shí)別用戶和環(huán)境特性，參見ISO9241-11和ISO/IEC開發(fā)運(yùn)行概念和其他生存周定義一組有代表性的場(chǎng)景，以識(shí)別與預(yù)期的運(yùn)行和其他生存周期概念相符的場(chǎng)景可用于定義概念文檔，并限定系統(tǒng)產(chǎn)品、預(yù)期運(yùn)行環(huán)境和接口系統(tǒng)、平臺(tái)或產(chǎn)范圍。場(chǎng)景有助于識(shí)別可能被忽略的需求。場(chǎng)景可以幫助建立為對(duì)系統(tǒng)成功至關(guān)重要的、滿足關(guān)鍵和期望的系統(tǒng)性能閾值和目標(biāo)的系統(tǒng)性能指標(biāo)。場(chǎng)景還可能確定那些需要的、但可能會(huì)做出妥協(xié)的、用以滿足關(guān)鍵的參數(shù)。用例方法也可用于定義概念文檔。根據(jù)這種方法，識(shí)別了一組參與者（與系統(tǒng)交在利益相關(guān)方需要和需求過程中，利益相關(guān)方對(duì)業(yè)務(wù)或使命分析過程中提出的一些初步生存周期概念進(jìn)行了詳細(xì)闡述和細(xì)化。這些包括OpsCon、獲取概念、部署概念、支持概念、退役概念以及為解這些因素可能包括工作場(chǎng)所環(huán)境、正?；虍惓Ｊ褂脳l件，以及用戶的預(yù)期技能和知識(shí)。系統(tǒng)可用種全面的系統(tǒng)方法，以使包括人、技術(shù)（硬件和軟件）、操作環(huán)境和系統(tǒng)元素之間的必要接口協(xié)調(diào)工場(chǎng)景和任務(wù)、用戶群體和質(zhì)量特性考慮的清晰理解。用戶任務(wù)和性能、人力和培訓(xùn)方面的需求主要可以通過將系統(tǒng)的目標(biāo)或使命分解到任務(wù)分析層級(jí)來定義，以定義用戶界面的特征或前端分析來確定培將利益相關(guān)方需要轉(zhuǎn)化為利益相關(guān)a)外部或組織利益相關(guān)方（例如，工程計(jì)劃、技術(shù)性能度量、技術(shù)成熟度、法規(guī)、生存周期成d)反映總體需方/用戶滿意度的有效性和適用性措施（例如，性能、安全性、可靠性、可用性、a)最高管理層要求的預(yù)算限額是后續(xù)需求過程的約束；b)為系統(tǒng)制定的維護(hù)策略可能會(huì)對(duì)需求施加條件或約束（維修時(shí)間和/或備件水平可能會(huì)驅(qū)動(dòng)識(shí)別與關(guān)鍵質(zhì)量特性相關(guān)的利益相關(guān)方需求和功作為這項(xiàng)任務(wù)的一部分，識(shí)別和評(píng)估重用以前存在的需求的機(jī)會(huì)非常重要。這包括識(shí)別提供類似功能或能力的現(xiàn)有系統(tǒng)、適用于所關(guān)注的新系統(tǒng)的指定功能或能力，以及關(guān)于可重用程需求和需要獲取是一項(xiàng)迭代活動(dòng)。考慮幾種不同的技術(shù)h)組織分析技術(shù)（如優(yōu)勢(shì)-劣勢(shì)-機(jī)熟悉如何將他們的專業(yè)知識(shí)轉(zhuǎn)化為格式良好的需求陳述。除了這些需求的人力資源外，重要的系統(tǒng)需領(lǐng)域的基本特征。也可能存在驅(qū)動(dòng)系統(tǒng)要求的安全或其他對(duì)用戶社區(qū)的描述（通常在組織運(yùn)作概念中找到）可以提供對(duì)整個(gè)工作的共同理解，并確認(rèn)場(chǎng)景的適當(dāng)性。用戶描述可能涵蓋產(chǎn)品將要銷售到的人口統(tǒng)計(jì)組，或指定使用該系統(tǒng)或從其運(yùn)行中獲益的在利益相關(guān)方需求和需要獲取過程中，讓利益相關(guān)方參與利益相關(guān)方需求（例如，格式良好的需宜針對(duì)5.2.5和5.2.6中定義的特如果來自現(xiàn)有或遺留系統(tǒng)的利益相關(guān)方需求已被識(shí)別為可重用的候選需求，則宜根據(jù)適用性、可行性、可用性、質(zhì)量、成本效益、價(jià)值和貨幣等因素對(duì)其進(jìn)行分析以供使用。在重用需求時(shí)，宜仔細(xì)檢查重用需求與所關(guān)注的系統(tǒng)的特定需求的符合性，以確保符在需求工程過程中，通常會(huì)有一個(gè)或多個(gè)正式計(jì)劃的點(diǎn)來確認(rèn)需求。目標(biāo)是在投入資源實(shí)施需求的系統(tǒng)解決方案之前識(shí)別所有問題。需求確認(rèn)涉及檢查需求集的過程，以幫助確保需求定義了正確的需求確認(rèn)須經(jīng)項(xiàng)目管理方和關(guān)鍵利益相關(guān)方批準(zhǔn)。本活動(dòng)用于確認(rèn)需求正確反映了利益相關(guān)方的在需求的分析和分配過程中，持續(xù)進(jìn)行需求協(xié)商非常重要，因?yàn)闀?huì)發(fā)生沖突?？赡苄枰谝蠡コ鲇诤贤颍祟悰Q策可追溯至利益相關(guān)方通常很重要。多種分析方法和沖突解決技一些組織認(rèn)為需求協(xié)商是需求確認(rèn)的一部分。只要沖突解決在需求分析任務(wù)中盡早發(fā)生，特定流管理利益相關(guān)方需要和要進(jìn)行需求評(píng)審可能是驗(yàn)證和確認(rèn)需求規(guī)格說明最常用的方法。成立一個(gè)查找錯(cuò)誤、錯(cuò)誤的假設(shè)、清晰度的缺失、可驗(yàn)證性問題以及與標(biāo)準(zhǔn)實(shí)踐的偏差的評(píng)審小組，進(jìn)行審查的小組的成員很重要（例評(píng)審可以在需求集合中的系統(tǒng)結(jié)構(gòu)的任何層面進(jìn)行。各種類型的評(píng)審可能適用于需求的整個(gè)開發(fā)和維護(hù)過程，包括技術(shù)評(píng)審、檢查和走查?？梢酝ㄟ^使用低保真原型來獲得系統(tǒng)潛在用戶的反饋，實(shí)利益相關(guān)方要求的協(xié)議可能僅限于單個(gè)利益相關(guān)方，僅同意利益相關(guān)方要求的關(guān)方需求之間可能存在沖突。完整記錄利益相關(guān)方需要，即使這些需要之間存在沖突，這是利益相關(guān)宜建立和維護(hù)需求可追溯性，以記錄正式需求如何滿足利益相關(guān)方的目標(biāo)并達(dá)成利益相關(guān)方的協(xié)定。利益相關(guān)方需求需要在整個(gè)系統(tǒng)生存周期和更長(zhǎng)的時(shí)間內(nèi)獲取、跟蹤和維護(hù)，并置于技術(shù)狀態(tài)控制之下。使用需求管理工具可以促進(jìn)這一過程。關(guān)于可追溯性應(yīng)用的更多討論見本文件的任注3：GB/T22032-2021、6.3.5和本文件宜考慮使用需求管理工具，尤其是對(duì)于更復(fù)雜的項(xiàng)目。該工具宜能夠示關(guān)系。需求管理工具旨在促進(jìn)和支持整個(gè)項(xiàng)目生存周期內(nèi)需求的系統(tǒng)化管理。這包括但不限于需求注5：有關(guān)需求管理工具的其他信息和指南，參見ISO/IEC需求存儲(chǔ)庫(kù)宜首先保存利益相關(guān)方需要的源文檔、項(xiàng)目約束（如來自業(yè)務(wù)策略/其設(shè)計(jì)的整個(gè)系統(tǒng)需求集提供基礎(chǔ)的所有其他條件。可作為利益相關(guān)方需求定義過程一部分輸出的信系統(tǒng)[系統(tǒng)/軟件]需求定義過程的目的是，把期望的能力從面向利益相關(guān)方或用戶的視圖，轉(zhuǎn)為了滿足利益相關(guān)方的需求，本過程創(chuàng)建了一組特定的可測(cè)量的系統(tǒng)需求，從供應(yīng)商的角度指定了系統(tǒng)應(yīng)該具備哪些特性、屬性以及功能和性能需求。只要條件允許，需求不應(yīng)隱含任何特定實(shí)a)組織。利益相關(guān)方宜了解將使用目標(biāo)系統(tǒng)/軟件的組織以及該組織的真正使命b)環(huán)境。利益相關(guān)方宜了解所關(guān)注系統(tǒng)領(lǐng)域的成熟度、所關(guān)注系統(tǒng)與運(yùn)行環(huán)境中其他系統(tǒng)之間c)約束。利益相關(guān)方宜考慮影響所關(guān)注的系統(tǒng)的生存周期的約束，如成本、進(jìn)度、政治、環(huán)境該策略包括識(shí)別和定義系統(tǒng)/軟件需求以及在整個(gè)生存周期中管理需求所需的方法、里程碑、資源識(shí)別和規(guī)劃支持系統(tǒng)[/軟件]需求定義所必要的使能使能系統(tǒng)或服務(wù)有助于系統(tǒng)的生存周期活動(dòng)。在系統(tǒng)/軟件需求定義的情況下，使能系統(tǒng)和服務(wù)包括工具和存儲(chǔ)庫(kù)。這些工具和存儲(chǔ)庫(kù)可用于從利益相關(guān)方獲取系統(tǒng)需求，并獲取、管理和當(dāng)更好地理解了系統(tǒng)/軟件的各種功能和元功能或能力的現(xiàn)有系統(tǒng)、適用于所關(guān)注的新系統(tǒng)的識(shí)別與風(fēng)險(xiǎn)、軟件系統(tǒng)的關(guān)鍵性或者關(guān)鍵質(zhì)量特性相技術(shù)措施用于深入了解系統(tǒng)或系統(tǒng)元素在達(dá)到要求中規(guī)定的技術(shù)參數(shù)方面的進(jìn)展情況。這些措施包括性能測(cè)度（MOP）和技術(shù)性能測(cè)度（TPM）。MOP表征與系統(tǒng)操作相關(guān)的物理或功能屬性的測(cè)度。MOP是在運(yùn)行環(huán)境條件下測(cè)量的。TPM是用于評(píng)估設(shè)計(jì)進(jìn)度、性能要求合規(guī)性和關(guān)鍵性能參數(shù)的技術(shù)風(fēng)險(xiǎn)的測(cè)度。有關(guān)這些方面的更多信息，參見ISO/IEC/IEEE24748-2。使用質(zhì)量測(cè)度用于確定產(chǎn)品是否滿足特定用戶的需要，以在現(xiàn)實(shí)系統(tǒng)環(huán)境中的特定使用環(huán)境中實(shí)現(xiàn)有效性、生產(chǎn)率、安全性和滿意度的特定目標(biāo)。v)來自現(xiàn)有的自動(dòng)和手動(dòng)系統(tǒng)運(yùn)行過程和數(shù)據(jù)的轉(zhuǎn)換，遷vi)需求屬性，如基本原理；優(yōu)先級(jí)；軟件系統(tǒng)元素括派生需求）如何滿足利益相關(guān)方需求和目標(biāo)，并達(dá)成利益相關(guān)方軟件規(guī)格說明參數(shù)的選擇取決于軟件元素、架構(gòu)和利益相規(guī)格說明是需求的集合，描述了產(chǎn)品、材料的基本技術(shù)要求以及確定是否滿足這些要求的標(biāo)準(zhǔn)。作為系統(tǒng)/軟件需求分析過程重要組成部分的需求規(guī)格說a)為需方或供方之間就產(chǎn)品的用途達(dá)成協(xié)議奠定了基礎(chǔ)（在市場(chǎng)驅(qū)動(dòng)的項(xiàng)目中，用戶輸入）；架構(gòu)可用于幫助分析需求集，以幫助確保架構(gòu)的所有特性和功能在需求中得到正確表可用性、質(zhì)量、成本效益、價(jià)值和貨幣等因素對(duì)其進(jìn)行分析以供使用。在重用需求時(shí)，宜仔細(xì)檢查重注1：有關(guān)要求重用的附加指南，參見ISO/IE5.2.8中的分類有助于完成此任務(wù)。GB/T22032-2021中的a）或GB/T8566-2022中的a）中的“驗(yàn)證準(zhǔn)備”活動(dòng)宜用于需求驗(yàn)證的定義、識(shí)別評(píng)估每個(gè)系統(tǒng)需求實(shí)現(xiàn)情況所需的性能測(cè)度和技術(shù)性能測(cè)度。該架構(gòu)可用于幫助定義關(guān)鍵性除了驗(yàn)證需求之外，下面的活動(dòng)處理了需求（無論是單獨(dú)的還是作為一個(gè)集合）的確認(rèn)，以恰當(dāng)將分析后的需求反饋給合適的利益相關(guān)方進(jìn)行需求確認(rèn)有助于確保利益相關(guān)方需求已正確轉(zhuǎn)化為系統(tǒng)需求。可以使用各種技術(shù)，包括利益相關(guān)方評(píng)審、原型設(shè)計(jì)、建模和仿真、概念建模和正式建模。適當(dāng)?shù)募夹g(shù)可以根據(jù)利益相關(guān)方的特點(diǎn)而有所不同，因此可能需要采用多種技術(shù)，以便考慮所有利益相關(guān)方。本文件在任務(wù)1下討論了評(píng)利益相關(guān)方評(píng)審是一種常見的技術(shù)，用于確認(rèn)易于實(shí)現(xiàn)的需求。利益相關(guān)方評(píng)利益相關(guān)方的小組一起對(duì)需求進(jìn)行分析，以確定系統(tǒng)需求是否完整、正確和一致，且反映利益原型通常用于獲取需求、確認(rèn)系統(tǒng)需求的解釋、澄清或檢查需求屬性以及識(shí)別任何遺漏的需求。原型的優(yōu)勢(shì)在于，為利益相關(guān)方的評(píng)估和輸入提供了更豐富的背景，可以更容易地解釋假設(shè)，并且可以提供關(guān)于其錯(cuò)誤原因的有用反饋。例如，通過動(dòng)畫或靜態(tài)原型可以更好地理解用戶界面的動(dòng)態(tài)行為，而不是通過文本描述或圖形模型。然而這也有一些缺點(diǎn)，包括開發(fā)原型的成本、潛在的錯(cuò)誤假設(shè)和無根據(jù)的期望以及低保真度原型的質(zhì)量問題。當(dāng)原型的目的得到充分理解時(shí)，可以使用原型的適當(dāng)保真度水平來實(shí)現(xiàn)有效的早期需求評(píng)審和驗(yàn)證。保真度水平和構(gòu)建質(zhì)量應(yīng)以原型目的為基礎(chǔ)。建模和仿真可用于協(xié)助利益相關(guān)方確認(rèn)需求。建模和仿真的優(yōu)勢(shì)在于，當(dāng)結(jié)果與利益相關(guān)方的預(yù)期不符時(shí)，可以演示交互作用并允許進(jìn)行敏感性分析。架構(gòu)定義過程中的模型和視圖可用于幫助利益注2：有關(guān)建模在開發(fā)架構(gòu)和幫助識(shí)別相關(guān)需求中的作用的更多信息，參見ISO/IEC/IE靜態(tài)概念建模是另一種可以使用的技術(shù)。目的是幫助理解問題，而不是開始設(shè)計(jì)解決方案。因此，概念模型包括來自問題域的實(shí)體模型，這些實(shí)體被配置為反映其真實(shí)世界的關(guān)系和依賴關(guān)系。有幾種a)問題的性質(zhì)：某些類型的應(yīng)用程序要求對(duì)某些方面進(jìn)行特別嚴(yán)格的分析。例如，控制流持、作為過程要求或簡(jiǎn)單地“更好”的記法可能是適當(dāng)?shù)腸)需方的過程要求：需方可能會(huì)采用特定的記法或方法，這可能與之前的使用基于離散數(shù)學(xué)的記法并可追溯到邏輯推理的形式化建模在一些專業(yè)領(lǐng)域產(chǎn)生了影響。正式建?？赡苡尚璺交驑?biāo)準(zhǔn)實(shí)施，也可能為某些關(guān)鍵功能在系統(tǒng)需求的分析和分配過程中，持續(xù)進(jìn)行需求協(xié)商非常重要，因?yàn)闀?huì)發(fā)生沖突。當(dāng)需求集完整、進(jìn)行需求評(píng)審可能是驗(yàn)證和確認(rèn)需求以及促進(jìn)需求符合性的最常用方法。此外，利益相關(guān)方宜準(zhǔn)備通過談判達(dá)成并維持協(xié)定。通常，系統(tǒng)/軟件需求的所有者負(fù)責(zé)主持協(xié)商。負(fù)責(zé)人宜具備必要的談判需求追蹤涉及到恢復(fù)需求的來源和預(yù)測(cè)需求變更的影響?？勺匪菪砸税ń涌谝蟆Ｗ粉櫴菆?zhí)行以下分析的基礎(chǔ)：覆蓋率分析（以幫助確保在設(shè)計(jì)中滿足所有利益相關(guān)方的需求，并確保每個(gè)低層級(jí)還宜向上追溯到激發(fā)每個(gè)需求的需求和利益相關(guān)方（例如，從軟件需求返回到幫助滿足的系統(tǒng)需求）。對(duì)于源自權(quán)衡或設(shè)計(jì)研究的需求，這些派生需求宜可追溯至其派生的研究，且該研究宜可追溯b)允許跟蹤需求開發(fā)和分配，以及相關(guān)措施，如需求覆蓋率、合規(guī)性和復(fù)雜性；每個(gè)需求應(yīng)進(jìn)行技術(shù)狀態(tài)控制。與需求一起記錄的輔助信息可以包括每個(gè)需求、決策、假設(shè)和變更歷史的概要依據(jù)，以及5.2.8中描述的需求分類信息。再次指出，需求管理工具的使用促進(jìn)了維護(hù)需求可追溯性和技術(shù)狀態(tài)控制信息項(xiàng)的繁瑣而復(fù)雜的項(xiàng)目，這些信息項(xiàng)可以作為系統(tǒng)需求定義過程的一架構(gòu)定義過程的目的是生成系統(tǒng)架構(gòu)備選方案，選擇一個(gè)或多個(gè)備選方案，構(gòu)建利益相關(guān)方關(guān)注接口需求（機(jī)械、電氣、數(shù)據(jù)和包絡(luò)）是需要全面記錄的重要需求類型，可以包含在規(guī)格說明或接口控制文檔中，并且需要可追溯到接口雙方。接口需求被納入架構(gòu)定義中。接口文檔由涉及系統(tǒng)間備選架構(gòu)是根據(jù)配置系統(tǒng)的一組系統(tǒng)元素的需求來定義的。建立和維護(hù)需求和架構(gòu)（包括系統(tǒng)元注1：GB/T22032-2021，第6.4.9節(jié)或GB針對(duì)每項(xiàng)驗(yàn)證活動(dòng)選擇適當(dāng)?shù)尿?yàn)證方法或技術(shù)和相關(guān)該活動(dòng)通過在創(chuàng)建需求時(shí)最初關(guān)聯(lián)驗(yàn)證方法來實(shí)現(xiàn)。宜記錄驗(yàn)證方法。文檔可能包括需求驗(yàn)證和可追溯性矩陣或驗(yàn)證計(jì)劃中的驗(yàn)證聲明。驗(yàn)證方法定義了如何（包括成功標(biāo)準(zhǔn)和結(jié)束方法）、何時(shí)何地證明每項(xiàng)要求的合規(guī)性以供需方接受。驗(yàn)證方法與每個(gè)需求相關(guān)聯(lián)以定義活動(dòng)，這些活動(dòng)產(chǎn)生證明需求滿足的客觀信息。一個(gè)好的驗(yàn)證方法定義可b)誰。確定負(fù)責(zé)執(zhí)行驗(yàn)證的組織或人員，如承包商、分包c(diǎn))何時(shí)。在獲取項(xiàng)目計(jì)劃中指定進(jìn)行驗(yàn)證的時(shí)間。這應(yīng)該是一項(xiàng)基于事件的成就，有四種標(biāo)準(zhǔn)驗(yàn)證方法可用于獲取滿足要求的客觀證據(jù)：檢查、分析或模擬、演示和測(cè)檢查——根據(jù)適用文檔對(duì)項(xiàng)目進(jìn)行檢查，以確認(rèn)符合要求。現(xiàn)實(shí)際條件下的測(cè)試或不符合成本效益的情況下使用。當(dāng)此類方法確定擬定解決方案滿足適當(dāng)?shù)男枨蟆⒁?guī)格說明或派生需求時(shí)，可使用分析（包括模擬）。分析也可以基于“相似性”，通過審查類似項(xiàng)目的先前驗(yàn)證，并確認(rèn)其驗(yàn)證狀態(tài)可以合法地轉(zhuǎn)移到當(dāng)前系統(tǒng)元素。只有當(dāng)項(xiàng)目在設(shè)計(jì)、制造和使用方面相似時(shí)，才能使用相似性；類似的系統(tǒng)元素采用了同等演示——功能性能的定性展示，通常在沒有或很少使用儀器或測(cè)試設(shè)備的情況下完成。演示使用一組由供方選擇的系統(tǒng)激勵(lì)的測(cè)試活動(dòng)，以表明系統(tǒng)或系統(tǒng)元素對(duì)激勵(lì)的響應(yīng)是合適的員在使用系統(tǒng)時(shí)可以執(zhí)行其分配的功能。進(jìn)行觀察并與預(yù)定響應(yīng)進(jìn)行比較。當(dāng)以統(tǒng)計(jì)術(shù)語給出要求或測(cè)試——在真實(shí)或模擬的受控條件下，對(duì)項(xiàng)目的可操作性、可保障性或性能進(jìn)行定量驗(yàn)證的行動(dòng)。環(huán)境條件、所需的資質(zhì)和測(cè)試人員、要遵循的一般步驟、要收集的具體數(shù)據(jù)、收集數(shù)據(jù)的重復(fù)性標(biāo)準(zhǔn)這確保了系統(tǒng)或系統(tǒng)元素可以按照協(xié)定的標(biāo)準(zhǔn)執(zhí)行其分配的功能。開發(fā)評(píng)審和系統(tǒng)驗(yàn)證和確認(rèn)結(jié)果構(gòu)成認(rèn)證需求可追溯性經(jīng)常被用作一個(gè)單一的責(zé)任點(diǎn)，用于將需中向前推進(jìn)，以評(píng)估需求是否得到滿足。在需求可追溯性中，驗(yàn)證方法和信息與需求相關(guān)聯(lián)，以表明如何驗(yàn)證系統(tǒng)或系統(tǒng)元素表明其滿足需求。隨著系統(tǒng)生存周期階段的推進(jìn)，宜增加對(duì)工作產(chǎn)品需求的確認(rèn)過程的目的是提供客觀證據(jù)，證明系統(tǒng)在使用時(shí)能夠滿足其業(yè)務(wù)或使命目標(biāo)，以及利益相關(guān)注1：GB/T22032-2021中的6.4.11或GB系統(tǒng)運(yùn)行概念和包含系統(tǒng)的利益相關(guān)方需求基線，其中所關(guān)注的系統(tǒng)是需求管理包括那些記錄和維護(hù)不斷發(fā)展的需求以及來自需求工程活動(dòng)的相關(guān)上下文和歷史信息的任務(wù)。需求管理還建立了定義、控制和發(fā)布所關(guān)注的系統(tǒng)各級(jí)基線需求的程序。有效的需求管理發(fā)生在GB/T22032-2021和GB/T8566-需求很少是靜態(tài)的。宜識(shí)別可能演變的需求，并將其傳達(dá)給需方和技術(shù)團(tuán)體。需求的核心子集可能會(huì)提前凍結(jié)。評(píng)估擬議新需求的影響，以幫助確保維持需求基線的初始意圖，在大多數(shù)情況下，需求理解都會(huì)隨著生存周期活動(dòng)的進(jìn)行而不斷發(fā)展。這通常會(huì)導(dǎo)后期修改需求?；蛟S理解需求工程最關(guān)鍵的一點(diǎn)是，需求的很大一部分將發(fā)生變化。無論如何，在生存周期中進(jìn)行需求變更時(shí)應(yīng)謹(jǐn)慎。盡管某些變更可能不可避變更可能導(dǎo)致“需求蠕變”，從而導(dǎo)致成本超支、進(jìn)度延誤、設(shè)計(jì)錯(cuò)誤、買方不滿甚至取消項(xiàng)目。無論需求變更的原因是什么，認(rèn)識(shí)到變更的必然性是極為重要的，并采取措施減輕變更的影響是非常重要的。通過確保擬定的變更經(jīng)過定義的影響評(píng)估、審查和批準(zhǔn)流程，并通過應(yīng)用詳細(xì)的需求追技術(shù)狀態(tài)管理的目的是在整個(gè)生存周期內(nèi)管理和控制系統(tǒng)元素和技術(shù)狀態(tài)。技術(shù)狀態(tài)管理還管理系統(tǒng)運(yùn)行概念和利益相關(guān)方、系統(tǒng)、軟件和系統(tǒng)元素要求被確定為技術(shù)狀態(tài)管理規(guī)劃中技術(shù)狀態(tài)常用的基線是功能基線、分配基線、開發(fā)基線和產(chǎn)品基線。給定項(xiàng)目使用的基線以及變更批準(zhǔn)所a)功能基線（需求基線）建立了對(duì)系統(tǒng)預(yù)期功能的共同理解（即協(xié)定的系統(tǒng)需求規(guī)格說明和相關(guān)b)分配基線對(duì)應(yīng)于所關(guān)注的系統(tǒng)下物理層級(jí)的已審核和版本化系統(tǒng)元素需求規(guī)格說明，包括接口c)開發(fā)基線表示生存周期中選定時(shí)間內(nèi)不斷演變的系統(tǒng)和系統(tǒng)元素技術(shù)狀態(tài)。此基線的變更權(quán)限當(dāng)對(duì)運(yùn)行概念和利益相關(guān)方、系統(tǒng)、軟件和系統(tǒng)元素需求進(jìn)行變更時(shí)，需要正式捕獲這些更改，并將其記錄在需求的文檔基線中，同時(shí)還需要確定具體更改和相關(guān)基本原理的技術(shù)狀態(tài)信息。宜維護(hù)應(yīng)根據(jù)項(xiàng)目和組織技術(shù)狀態(tài)管理過程對(duì)需求進(jìn)行技術(shù)狀態(tài)注2：GB/T22032-2021，6.3.5和GB/T信息管理過程的目的是向指定的利益相關(guān)方生成、獲取、確認(rèn)、轉(zhuǎn)換、保留、檢索、傳播和處置系統(tǒng)運(yùn)行概念文檔和利益相關(guān)方需求規(guī)格說明、系統(tǒng)需求規(guī)格說明、軟件需求規(guī)格說明和其他系注2：GB/T22032-2021中6.3.6和GB/T測(cè)量過程的目的是收集、分析和報(bào)告客觀數(shù)據(jù)和信息，以支持有效管理并證明產(chǎn)品、服務(wù)和過程需求工程作為一門學(xué)科，從過程和產(chǎn)品環(huán)境中的需求測(cè)量中獲益?？赡苄枰粋€(gè)以上的指標(biāo)來洞分析工作，可用于設(shè)置需求發(fā)布標(biāo)準(zhǔn)，可作為需求和詳細(xì)設(shè)計(jì)評(píng)審的輸入標(biāo)準(zhǔn)，并可用于承b)需求數(shù)量–需求數(shù)量可用于測(cè)量需求工程活動(dòng)的進(jìn)度，估計(jì)需求完c)需求波動(dòng)性——在過程上下文中，需求波動(dòng)性可以表示組織的需求工程過程不會(huì)將一組需求聚合到一個(gè)結(jié)構(gòu)良好的集合中。在產(chǎn)品環(huán)境中，高波動(dòng)性值可能表明利益相關(guān)方未能就系統(tǒng)c)追溯性指標(biāo)（例如，無子女的父母百分比、每個(gè)父母的平均子女）；軟件需求用于軟件功能規(guī)模測(cè)量（FSM）方法中，以幫助管理軟件項(xiàng)目的許多方面。FSM方法分為注3：GB/T22032-2021中的6.3.7和GB/T8566-2022中的6.3.7提供了有關(guān)測(cè)量過程的附加信息，ISO/IEC/IEEE選擇在整個(gè)生存周期內(nèi)可隨時(shí)獲得數(shù)據(jù)的度量是一種良好的實(shí)踐。然后，可以將數(shù)據(jù)采集集成到與需求相關(guān)的過程中，以便在需求工程進(jìn)行時(shí)定期獲得數(shù)據(jù)和洞察力?？傮w審查b)利益相關(guān)方需求規(guī)格說明（StRSd)軟件需求規(guī)格說明（SRS），如果遵守GB/T8566-2022。注2：如5.4所述，四種文檔類型中的每一種都可以在項(xiàng)目中產(chǎn)生多個(gè)規(guī)格說明信息項(xiàng)。例如，可以為系統(tǒng)和系統(tǒng)注3：四種規(guī)格說明信息項(xiàng)BRS、StRS、SyRS和SRS可包含類似的信息項(xiàng)，這些信息項(xiàng)可視為同一產(chǎn)品的不同視圖。注4：BRS和StRS在不同領(lǐng)域中可以有不同的標(biāo)題，并且可以包含在其他信息項(xiàng)中，只要這些規(guī)格說明的功能可以信息項(xiàng)的管理應(yīng)采用GB/T22032-2021和GB/T8566-2022的業(yè)務(wù)需求規(guī)格說明（BRS）描述了組織開發(fā)或更改系統(tǒng)的動(dòng)機(jī)，定義使用系統(tǒng)所依據(jù)的流程和方針業(yè)務(wù)部門應(yīng)指定BRS的信息元素。業(yè)務(wù)管理層應(yīng)對(duì)本規(guī)格說明的內(nèi)容負(fù)責(zé)。BRS是利益相關(guān)方積極注2：在許多行業(yè)中，BRS通常與利益相關(guān)方需求規(guī)格說明（StRS）相關(guān)。本文件的用戶可以根據(jù)用戶環(huán)境將StRS注3：業(yè)務(wù)分析知識(shí)手冊(cè)（BABOK）將利益相關(guān)方需求和業(yè)務(wù)需求區(qū)分如下：業(yè)務(wù)需求是對(duì)企業(yè)目的、目標(biāo)或需求的高級(jí)陳述，描述了項(xiàng)目使能的原因、項(xiàng)目將實(shí)現(xiàn)什么以及哪些指標(biāo)可用于衡量項(xiàng)目的成功。利益相關(guān)方需求是對(duì)特定利益相關(guān)方或利益相關(guān)方類別需求的陳述，描述了給定利益相關(guān)方的需求以及利益相關(guān)方將如何沒有一個(gè)最優(yōu)的組織。圖5顯示了在組織/業(yè)務(wù)上下文中創(chuàng)建利益相關(guān)方需求規(guī)格說明（StRS）描述了組織開發(fā)或更改系統(tǒng)的動(dòng)機(jī)，定義使用系統(tǒng)的過護(hù)人員從使用環(huán)境中派生的需求。在BRS中描述的上下文中，StRS描述了組織將如何利用該系統(tǒng)為業(yè)務(wù)StRs的信息元素應(yīng)由利益相關(guān)方指定。利益相關(guān)方應(yīng)對(duì)規(guī)格說明的內(nèi)容負(fù)責(zé)。StRS是利益相關(guān)方積極參與需求過程的基礎(chǔ)。StRS中包含的利益相關(guān)方需求的典型類型是組織需求、業(yè)務(wù)需求和用戶需注1：ISO/IEC/IEEE15289提供了將用戶（利益相關(guān)方）需求納入系統(tǒng)需求規(guī)格說明的指南。由于這些內(nèi)容是從利益相關(guān)方的角度指定的，本文件在StRS中包含了這些需求。用戶需求可以在SyRS中通過解沒有一個(gè)最優(yōu)的編排。圖6顯示了在組織/業(yè)務(wù)上下文中創(chuàng)建的S系統(tǒng)需求規(guī)格說明（SyRS）識(shí)別了所選所關(guān)注的系統(tǒng)的假設(shè)和非功能性需求的說明。SyRS可能包括用于說明系統(tǒng)環(huán)境、使用場(chǎng)景、主要域?qū)嶓w、數(shù)據(jù)、信息SyRS的目的是根據(jù)系統(tǒng)與其外部環(huán)境的交互或接口，描述系統(tǒng)應(yīng)該做什么。SyRS應(yīng)完整描述所有輸入、輸出以及輸入和輸出之間所需的關(guān)系。傳統(tǒng)上，SyRS被視為將需方的要求傳達(dá)給將指定和構(gòu)建系統(tǒng)的技術(shù)團(tuán)體的文檔。構(gòu)成本規(guī)格說明及其表述的需求集合起到了兩個(gè)群體之間的橋梁作用，需要被需方和技術(shù)團(tuán)體理解。創(chuàng)建系統(tǒng)中最困難的任務(wù)之一是與兩個(gè)組中的所有子組進(jìn)行溝通，本文件提出了這種結(jié)構(gòu)化信息收集與向不同受眾呈現(xiàn)信息的方式之間的區(qū)別。SyRS的呈現(xiàn)形式應(yīng)適合其預(yù)期用途。這可以是紙質(zhì)文檔、模型、原型、其他非紙質(zhì)文檔或他們的任何組合來表示。所有這些表述都可以從這個(gè)SyRS中派生出來，以滿足特定受眾的需求。但是，應(yīng)注意確保每個(gè)演示文檔都可追溯到系統(tǒng)需求信息的共同來源。受眾應(yīng)該意識(shí)到，這種結(jié)構(gòu)化的信息收集仍然是解決所選特定演通常，過程需求（如何開發(fā)或構(gòu)建系統(tǒng)）應(yīng)包含在合同文檔，如工作說明書中，SyRS提供了需求定義、系統(tǒng)運(yùn)行概念、系統(tǒng)架構(gòu)和系統(tǒng)需求分析任務(wù)的結(jié)果。因此，SyRS描述了系統(tǒng)的需方希望系統(tǒng)為他們做什么、系統(tǒng)的預(yù)期環(huán)境、系統(tǒng)的使用概況、性能參數(shù)、預(yù)期質(zhì)量和有效應(yīng)編排SyRS的特定需求部分，以便利益相關(guān)方一致同意編排方法有助于理解需求。對(duì)于所有項(xiàng)目，軟件需求規(guī)格說明（SRS）是在特定環(huán)境中執(zhí)行特定功能的特定軟件產(chǎn)品、程序或并將外部性能和功能需求放在軟件部分上。當(dāng)然，SRS應(yīng)同意并擴(kuò)展這些系統(tǒng)需求。SRS表示需求的優(yōu)先級(jí)和關(guān)鍵性。SRS定義了其適用的指定軟件產(chǎn)品的所有所需功能，并記錄了軟件必須執(zhí)行的條件和約SRS的具體要求條款的編排應(yīng)確保系統(tǒng)利益相關(guān)方一致同意編排方法有助于理解要求。對(duì)于所有系a)系統(tǒng)模式——根據(jù)操作模式，某些系統(tǒng)的行為完全不同。例如，根據(jù)其模式，控制系統(tǒng)可能b)用戶類——一些系統(tǒng)為不同的用戶類提供不同的功能集。例如，電梯控制系統(tǒng)為乘客、維修c)對(duì)象——對(duì)象是在系統(tǒng)中具有對(duì)應(yīng)對(duì)象的真實(shí)實(shí)體。例如，在患者監(jiān)控系統(tǒng)中，對(duì)象包括患者、傳感器、護(hù)士、房間、醫(yī)生、藥品等。與d)特征——特征是系統(tǒng)外部所需的服務(wù)，可能需要一系列輸入來實(shí)現(xiàn)所需結(jié)果。例如，在電話系統(tǒng)中，功能包括本地呼叫、呼叫轉(zhuǎn)移和會(huì)議呼叫。每個(gè)特征通常以一系列刺激-反e)激勵(lì)——一些系統(tǒng)通過描述其在激勵(lì)情況下的功能能夠被最好地組織。例如，自動(dòng)飛機(jī)著陸系統(tǒng)的功能可分為功率損失、風(fēng)切變、橫搖突變、垂直速f)響應(yīng)——一些系統(tǒng)通過描述支持響應(yīng)生成的所有功能能夠最好地組織。例如，人事系統(tǒng)可以被編排為關(guān)聯(lián)到生成工資支票的所有功能、關(guān)聯(lián)到生成當(dāng)前員工列表所有功能等相對(duì)應(yīng)的條公共內(nèi)部數(shù)據(jù)訪問組織的功能層級(jí)結(jié)構(gòu)。數(shù)據(jù)流圖和數(shù)據(jù)字典可用于顯示函數(shù)和注2：有許多記法、方法和自動(dòng)支持工具可用于幫助記錄SRS要求。在很大程度上，方法和工具的有用性是組織的以證明是有用的；當(dāng)按特征組織時(shí)，激勵(lì)-響應(yīng)序列可以證明是有用的；當(dāng)按功能層級(jí)結(jié)構(gòu)進(jìn)行組織時(shí)，數(shù)9信息項(xiàng)內(nèi)容9.2.1標(biāo)識(shí)標(biāo)題和修訂通知唯一標(biāo)識(shí)文檔。修訂信息可能包括項(xiàng)目名稱、文檔版本號(hào)、發(fā)布日期、批準(zhǔn)簽字、文檔當(dāng)前版本中已更改的子條款列表以及文9.2.2前頁(yè)9.2.3定義提供任何詞或詞組的定義，這些詞或詞組具有普通詞典定義以外的特9.2.4參考資料b)按標(biāo)題、報(bào)告編號(hào)（如適用）、日期和發(fā)布組織標(biāo)識(shí)每份文該信息可參考附錄或其他文檔提供。參考資料信息宜細(xì)分為“遵守”部分（包含引用文檔中包含9.2.5首字母縮略語和縮寫詞9.3業(yè)務(wù)需求規(guī)格說明（BRS）內(nèi)容本條定義了業(yè)務(wù)需求規(guī)格說明（BRS）的規(guī)范性內(nèi)容。項(xiàng)目根據(jù)與業(yè)務(wù)需求規(guī)格說明9.3.2業(yè)務(wù)目的在組織層面上描述組織尋求新業(yè)務(wù)或改變當(dāng)前業(yè)務(wù)以適應(yīng)新的管理環(huán)境的原因和背景。在這種情9.3.3業(yè)務(wù)范圍b)定義相關(guān)業(yè)務(wù)領(lǐng)域中包含的業(yè)務(wù)活動(dòng)范圍。范圍可以根據(jù)組織中與業(yè)務(wù)活動(dòng)直接相關(guān)的部門c)描述正在開發(fā)或更改的系統(tǒng)的范圍。描述包括系統(tǒng)描述相關(guān)業(yè)務(wù)領(lǐng)域的主要內(nèi)部部門和外部實(shí)體，及9.3.5主要利益相關(guān)方列出主要利益相關(guān)方或利益相關(guān)方類別，并描述他們將如何影響組織和9.3.6業(yè)務(wù)環(huán)境定義在理解新的或現(xiàn)有的業(yè)務(wù)時(shí)宜考慮的外部和內(nèi)部環(huán)境因素，并獲取利益相關(guān)方對(duì)擬議開發(fā)或更改的系統(tǒng)的要求。環(huán)境因素宜包括市場(chǎng)趨勢(shì)、法律法規(guī)、社會(huì)責(zé)任和技術(shù)基礎(chǔ)等外部條件對(duì)業(yè)務(wù)以9.3.7使命、目的和目標(biāo)9.3.8業(yè)務(wù)模式描述預(yù)期實(shí)現(xiàn)業(yè)務(wù)任務(wù)的方法。描述宜集中于系統(tǒng)支持的開發(fā)或更改方法，包括產(chǎn)品和服務(wù)、地9.3.9信息環(huán)境描述基于多個(gè)信息系統(tǒng)公共基礎(chǔ)的組織級(jí)決策的總體策略，宜包括以a）項(xiàng)目組合——當(dāng)多個(gè)系統(tǒng)項(xiàng)目正在運(yùn)行或計(jì)劃追求相同的業(yè)務(wù)目的時(shí)，優(yōu)先級(jí)、相對(duì)定位和b）長(zhǎng)期系統(tǒng)計(jì)劃——對(duì)已經(jīng)確定或計(jì)劃了的公共系統(tǒng)基礎(chǔ)設(shè)施或架構(gòu)，宜將其描述為對(duì)可能的c）數(shù)據(jù)庫(kù)技術(shù)狀態(tài)——宜指定組織級(jí)數(shù)據(jù)庫(kù)技術(shù)狀態(tài)計(jì)劃以及組織全局?jǐn)?shù)據(jù)可用性和可訪問性9.3.10業(yè)務(wù)過程提供業(yè)務(wù)活動(dòng)程序的說明以及過程內(nèi)可能的系統(tǒng)接口。此信息項(xiàng)的目的是表示系統(tǒng)如何以及在何種上下文中支持業(yè)務(wù)活動(dòng)。通常，業(yè)務(wù)過程通過分解和分類形成有序結(jié)構(gòu)。每個(gè)業(yè)務(wù)過程應(yīng)有唯一的名稱和編號(hào)。單個(gè)業(yè)務(wù)過程的描述宜表示為表示活動(dòng)序列的9.3.11業(yè)務(wù)運(yùn)行方針和規(guī)則描述用于執(zhí)行業(yè)務(wù)過程的邏輯命題。這些命題可能是啟動(dòng)、分支和終止業(yè)務(wù)過程中的業(yè)務(wù)活動(dòng)順9.3.12業(yè)務(wù)運(yùn)行約束描述在執(zhí)行業(yè)務(wù)過程時(shí)要施加的條件。這些條件可能與性能約束有關(guān)（例如，9.3.13業(yè)務(wù)運(yùn)行模式非常繁忙的狀態(tài)。業(yè)務(wù)操作的不穩(wěn)定狀態(tài)包括由于意外情況（如事故或自然災(zāi)害）而導(dǎo)致擬議系統(tǒng)不9.3.14業(yè)務(wù)運(yùn)行質(zhì)量定義業(yè)務(wù)運(yùn)營(yíng)所需的質(zhì)量層級(jí)。例如，業(yè)務(wù)過程可以以比業(yè)務(wù)過程可靠性更高的優(yōu)先級(jí)處理所需注：這可能包括使用中的可用性和質(zhì)量的高層級(jí)目標(biāo)（有效性、效率、滿意度和無使用風(fēng)險(xiǎn)，見ISO9241-9.3.15業(yè)務(wù)結(jié)構(gòu)識(shí)別和描述與系統(tǒng)相關(guān)的業(yè)務(wù)結(jié)構(gòu)，如組織結(jié)構(gòu)（分工和部門）、角色和責(zé)資源共享結(jié)構(gòu)?？赡苄枰瓜到y(tǒng)功能與這些結(jié)構(gòu)保持一致，并9.3.16高層級(jí)運(yùn)行概念以高層級(jí)的方式描述擬議系統(tǒng)，指出在不指定設(shè)計(jì)細(xì)節(jié)的情況下提供的操作特性。宜包括以下信9.3.17高層級(jí)運(yùn)行場(chǎng)景描述用戶/操作員/維護(hù)人員在重要使用環(huán)境中如何與系統(tǒng)交互的示例。描述了系統(tǒng)支持的業(yè)務(wù)過程的一個(gè)活動(dòng)或一系列活動(dòng)的高級(jí)場(chǎng)景。場(chǎng)景應(yīng)具有唯一的名稱和編號(hào)，并應(yīng)在9.3.9中的業(yè)務(wù)流程描9.3.18其他高層級(jí)生存周期概念9.3.19項(xiàng)目約束本條定義了利益相關(guān)方需求規(guī)格說明（StRS）的規(guī)范性內(nèi)容。項(xiàng)目根據(jù)項(xiàng)目政策中與利益相關(guān)方需求規(guī)格說明相關(guān)的內(nèi)容，生成以下信息項(xiàng)內(nèi)容?？筛鶕?jù)項(xiàng)目的信息管理方針選擇內(nèi)容9.4.2利益相關(guān)方目的在組織層面上描述組織尋求新業(yè)務(wù)或改變當(dāng)前業(yè)務(wù)以適應(yīng)新管理環(huán)境的原因和背景。在這種情況9.4.3利益相關(guān)方范圍b)定義相關(guān)業(yè)務(wù)領(lǐng)域中包含的業(yè)務(wù)活動(dòng)范圍。范圍可以根據(jù)組織中與業(yè)務(wù)活動(dòng)直接相關(guān)的部門c)描述正在開發(fā)或更改的系統(tǒng)的范圍。描述包括系統(tǒng)9.4.4概述描述相關(guān)業(yè)務(wù)領(lǐng)域的主要內(nèi)部部門和外部實(shí)體，及9.4.5利益相關(guān)方9.4.6業(yè)務(wù)環(huán)境定義外部和內(nèi)部環(huán)境因素，在理解新的或現(xiàn)有的業(yè)務(wù)和獲取利益相關(guān)方對(duì)要開發(fā)9.4.7使命、目的和目標(biāo)9.4.8業(yè)務(wù)模型描述預(yù)期實(shí)現(xiàn)業(yè)務(wù)目標(biāo)的方法。描述宜集中于系統(tǒng)支持的開發(fā)或更改方法，包括產(chǎn)品和服務(wù)、地9.4.9信息環(huán)境a)項(xiàng)目組合——當(dāng)多個(gè)系統(tǒng)項(xiàng)目正在運(yùn)行或計(jì)劃追求相同的業(yè)務(wù)目標(biāo)時(shí)，優(yōu)先級(jí)b)長(zhǎng)期系統(tǒng)計(jì)劃——對(duì)已經(jīng)確定或計(jì)劃了的公共系統(tǒng)基礎(chǔ)設(shè)施或架構(gòu)，宜將其描述為對(duì)可能的c)數(shù)據(jù)庫(kù)技術(shù)狀態(tài)——宜指定組織級(jí)數(shù)據(jù)庫(kù)技術(shù)狀態(tài)計(jì)劃以及組織全局?jǐn)?shù)據(jù)可用性和可訪問性9.4.10系統(tǒng)過程提供系統(tǒng)支持業(yè)務(wù)活動(dòng)的方式和周境描述。一般來說，系統(tǒng)過程是從具有分解和分類的業(yè)務(wù)過程的有序結(jié)構(gòu)開始的。每個(gè)系統(tǒng)過程在結(jié)構(gòu)中都應(yīng)該有唯一的名稱和編號(hào)。單個(gè)系統(tǒng)過程的描述宜表示9.4.11系統(tǒng)運(yùn)行方針和規(guī)則描述業(yè)務(wù)運(yùn)行方針和規(guī)則可能如何在SyRS和SRS的功能需求中得到解決。方針和規(guī)則應(yīng)具有唯一的9.4.12運(yùn)行約束描述在執(zhí)行業(yè)務(wù)過程時(shí)對(duì)系統(tǒng)施加的系統(tǒng)條件和功能要求。這些條件可能導(dǎo)出SyRS中的性能要求。9.4.13系統(tǒng)運(yùn)行模式和狀態(tài)9.4.14系統(tǒng)運(yùn)行質(zhì)量定義系統(tǒng)運(yùn)行所需的質(zhì)量水平，如性能、兼容性、可靠性、安全性、可維護(hù)性和可移植性。例如，9.4.15用戶需求用戶需求是為滿足已識(shí)別的用戶需要而設(shè)計(jì)和評(píng)估系統(tǒng)提供基礎(chǔ)的使用需求。用戶需求可以包括指定預(yù)期結(jié)果和相關(guān)質(zhì)量標(biāo)準(zhǔn)的使用的相關(guān)質(zhì)量（包括可用性）需求，指定實(shí)現(xiàn)預(yù)期結(jié)果所需交互的用戶系統(tǒng)交互需求，以及任何可能限制解決方案設(shè)計(jì)和實(shí)現(xiàn)自由以滿足用戶需求的約束。用戶需求可為設(shè)計(jì)指定的使用環(huán)境（即系統(tǒng)使用的環(huán)境）宜作為用戶需求規(guī)格說明的一部分進(jìn)行規(guī)定，以明確識(shí)別需求適用的條件。系統(tǒng)的可用性要求和目標(biāo)包括特定使用環(huán)境中可測(cè)量的有效性、效率和滿意注1：有關(guān)使用環(huán)境的更多信息，參見ISO/IEC25030和ISO9241-11。有關(guān)日常產(chǎn)品使20282-1注2：ISO/IECTR25060、ISO/IEC25064、ISO9241-210和ISO9241-220中提9.4.16運(yùn)行概念以高層級(jí)的方式描述擬議系統(tǒng)，指出在不指定設(shè)計(jì)細(xì)節(jié)的情況下提供的運(yùn)行特性。宜包括以下信9.4.17運(yùn)行場(chǎng)景描述用戶/操作員/維護(hù)人員在重要使用環(huán)境中如何與系統(tǒng)交互的示例。描述了系統(tǒng)支持的業(yè)務(wù)過程的一個(gè)活動(dòng)或一系列活動(dòng)的場(chǎng)景。該場(chǎng)景應(yīng)具有唯一的名稱和編號(hào)，并應(yīng)在9.3.10中的業(yè)務(wù)過程描9.4.18擬議系統(tǒng)的其他詳細(xì)概念9.4.19項(xiàng)目約束本條定義了系統(tǒng)需求規(guī)格說明（SyRS）的規(guī)范性內(nèi)容。項(xiàng)目根據(jù)項(xiàng)目有關(guān)系統(tǒng)需求規(guī)格說明的政策，生成以下信息項(xiàng)內(nèi)容?？筛鶕?jù)項(xiàng)目的信息管理方針選擇內(nèi)容的編排，如順序和章條9.5.2系統(tǒng)用途9.5.3系統(tǒng)范圍b)參考并說明早期最終需求分析的結(jié)果，以簡(jiǎn)短但清晰的方式表達(dá)用c)描述所指定系統(tǒng)的應(yīng)用。作為范圍的一部分，該描述應(yīng)準(zhǔn)確地描述所有相關(guān)的頂層利益、目9.5.4系統(tǒng)概述系統(tǒng)周境從總體上描述系統(tǒng)的主要元素，包括人的元素及其相互作用方式。系統(tǒng)概述包括適當(dāng)?shù)膱D表和敘系統(tǒng)功能用戶特征識(shí)別系統(tǒng)的每種類型的用戶/操作員/維護(hù)人員（按功能、位置、設(shè)備類型）、每組人數(shù)、他們使9.5.5功能要求9.5.6可用性要求定義系統(tǒng)的可用性和使用質(zhì)量需求和目標(biāo)，包括可測(cè)量的有效性、效9.5.7性能要求）；b)定量標(biāo)準(zhǔn)，包括在規(guī)定的環(huán)境和其他條件下滿足用戶需求所需的設(shè)備耐久能力，包括最低總9.5.8系統(tǒng)接口要求指定系統(tǒng)元素之間以及與外部實(shí)體的接口要求。系統(tǒng)元素之間的接口宜包括與人元素的接口。與定義與接口相關(guān)的任何相互依賴性或約束（例如，通信協(xié)議、特殊設(shè)備、標(biāo)準(zhǔn)、固定格式）。每9.5.9系統(tǒng)運(yùn)營(yíng)人-系統(tǒng)集成要求參考適用文檔，并規(guī)定任何特殊或獨(dú)特的要求，例如，對(duì)人員和通信以及人員/設(shè)備交互功能分配定義由于操作的敏感性或任務(wù)的關(guān)鍵性而需要集中人力工程注意的任何特定區(qū)域、站點(diǎn)或設(shè)備的可維護(hù)性要求a)時(shí)間（例如，平均和最大停機(jī)時(shí)間、反可靠性需求其他質(zhì)量需求9.5.10系統(tǒng)模式和狀態(tài)9.5.11物理特性物理需求包括對(duì)重量、體積和尺寸的約束。包括系統(tǒng)安裝位置的結(jié)構(gòu)特征、本規(guī)格說明涵蓋的項(xiàng)目或服務(wù)適應(yīng)性需求定義增長(zhǎng)、擴(kuò)展、能力和收縮的需求。例如，如果系統(tǒng)將需要未來的網(wǎng)絡(luò)帶寬，則宜為適用的硬9.5.12環(huán)境條件真菌、霉菌、沙子、鹽霧、灰塵、輻射、化學(xué)物質(zhì)、空氣污染物和浸沒感應(yīng)環(huán)境（如運(yùn)動(dòng)、沖擊、噪聲、電磁、熱電磁信號(hào)環(huán)境；自感環(huán)境（如運(yùn)動(dòng)、沖擊、噪聲、電磁、熱威脅以及合作環(huán)9.5.13系統(tǒng)安全要求定義與容納系統(tǒng)的設(shè)施和系統(tǒng)本身的操作安全要求相關(guān)的系統(tǒng)安全要求。安全要求的一個(gè)例子可法。這可能包括保護(hù)系統(tǒng)免受意外或惡意訪問、使用、修改、破壞或披露的因素。特別是在安全關(guān)鍵型嵌入式系統(tǒng)中，這可能包括數(shù)據(jù)集的分布式日志或歷史記錄、將某些功能分配給不同的單個(gè)系統(tǒng)，9.5.14信息管理要求定義系統(tǒng)對(duì)其接收、生成或?qū)С龅男畔⒌墓芾硇枨?。示例包括系統(tǒng)需要接收和存儲(chǔ)的信息的類型9.5.15政策和法規(guī)要求從將影響系統(tǒng)運(yùn)行或性能的組織策略和業(yè)務(wù)實(shí)踐中派生需求。從相關(guān)的外部法規(guī)中獲取需求。需求的例子包括多語言支持、人力資源政策和保護(hù)人詳細(xì)說明健康和安全標(biāo)準(zhǔn)的派生需求，包括與設(shè)備特性、操作方法和環(huán)境影響（如有毒系統(tǒng)和電9.5.16系統(tǒng)生存周期保障要求概述質(zhì)量活動(dòng)，如評(píng)審和測(cè)量收集和分析，以幫助實(shí)現(xiàn)質(zhì)量體系。生存周期維持和基地級(jí)維修所需的設(shè)施、備件、尋源采購(gòu)、供應(yīng)、提供、技術(shù)文檔和數(shù)據(jù)、支持人員培訓(xùn)、初期干9.5.17包裝、搬運(yùn)、裝運(yùn)和運(yùn)輸要求定義對(duì)系統(tǒng)施加的要求，以確保系統(tǒng)能夠在其預(yù)期運(yùn)行環(huán)境中進(jìn)行包裝、處理、裝運(yùn)、運(yùn)輸和存9.5.18驗(yàn)證提供計(jì)劃用于鑒定系統(tǒng)或系統(tǒng)元素的驗(yàn)證途徑和方法。建議以與9.5.5至9.5.17中信息元素平行的9.5.19假設(shè)和依賴性列出適用于系統(tǒng)需求的任何假設(shè)和依賴性，這些假設(shè)和依賴性宜在分9.6軟件需求規(guī)格說明（SRS）內(nèi)容9.6.3范圍9.6.4產(chǎn)品視角如果產(chǎn)品是一個(gè)更大系統(tǒng)的一個(gè)元素，則將該較大系統(tǒng)的需求與SRS涵蓋的產(chǎn)品功系統(tǒng)接口用戶界面硬件接口指定軟件產(chǎn)品和系統(tǒng)硬件元素之間每個(gè)接口的邏輯特征，這包括技術(shù)狀態(tài)特征（端口數(shù)、指令集等還包含支持哪些設(shè)備、如何支持這些設(shè)備以及協(xié)軟件接口指定其他所需軟件產(chǎn)品（例如，數(shù)據(jù)管理系統(tǒng)、操作系統(tǒng)或數(shù)學(xué)軟件包）的使用，以及與其他應(yīng)注：指定所需的平臺(tái)或操作系統(tǒng)是可以接受的，但要求特定版本幾乎不可行。通常，可以為軟件指定最新版本或b)根據(jù)消息內(nèi)容和格式定義接口。無需詳細(xì)說明任何記錄良好的接口，但需要參考定義接口的通信接口操