缺乏數(shù)據(jù)、粗略的需求、不確定的業(yè)務(wù)目標是軟件開發(fā)項目失敗的原因。但是，您絕對有能力解決這些問題。

明確定義項目的功能和非功能需求至關(guān)重要，因為這可以讓您改進軟件開發(fā)過程。

在這篇博文中，我們分享了有關(guān)編寫更好的項目需求如何降低風險和項目成本、提高生產(chǎn)力和取悅客戶的信息

讓我們開始吧！

軟件需求的概念似乎很簡單：您選擇您的項目將要解決的任何問題，仔細考慮，然后提出相當多的軟件需求。

看起來一切都很簡單，對吧？但事實并非如此。有很多問題需要討論：

• 你如何收集需求？

• 您如何評估利益相關(guān)者群體的需求和期望？這些要求是否有任何技術(shù)限制？

• 您如何確定工作已完成？

這份清單似乎無窮無盡。

在考慮這些時，您會發(fā)現(xiàn)軟件需求是一個相當廣泛的專業(yè)領(lǐng)域。這涉及定義需求、需求分析、規(guī)范和驗證的過程，以及在整個軟件開發(fā)周期中管理需求的過程。

一些組織雇用一名需求收集人員。但開發(fā)需求的責任通常分配給完全不同的專家。業(yè)務(wù)分析師、產(chǎn)品所有者、經(jīng)理和開發(fā)人員可能會參與此過程。

需求的定義

需求的定義涉及需求的收集和制定。有些要求可以由消費者決定。另一個可以由正在為其開發(fā)產(chǎn)品的系統(tǒng)或活動領(lǐng)域定義。

對于項目管理，需求的定義是必不可少的一點。它使您能夠確定項目量并設(shè)置優(yōu)先級以滿足客戶的需求。

什么會影響要求？

您可以使用各種來源收集需求。例如：

• 業(yè)務(wù)目標；

• 領(lǐng)域知識;

• 利益相關(guān)者；

• 商業(yè)規(guī)則;

• 操作環(huán)境。

但請注意，通過確定要求，您應(yīng)該：

• 特別注意目標。確定需求的優(yōu)先級并確定實現(xiàn)項目目標的最合理方法。

• 為深入的需求分析模擬真正的挑戰(zhàn)。

• 找出不同利益相關(guān)者的觀點。要求可能相互沖突或重疊。找出不同利益相關(guān)者的需求至關(guān)重要，尤其是在項目初步規(guī)劃期間。

• 考慮操作環(huán)境。這將取決于組織結(jié)構(gòu)、文化和內(nèi)部政策。

需求如何影響軟件開發(fā)過程？

未記錄的需求是溝通不暢的常見原因，這會導致返工、更改和錯誤修復。通常，這會導致截止日期中斷和成本急劇增加。

請注意，每個團隊成員都應(yīng)該以相同的方式理解所有項目開發(fā)部分。如果您將軟件開發(fā)外包給不熟悉您的業(yè)務(wù)的團隊，這一點尤其重要。使用軟件需求規(guī)范，您將確保開發(fā)人員能像您一樣看到所有功能。

為什么規(guī)格和要求很重要？

錯誤最小化

準確定義的產(chǎn)品需求使開發(fā)人員能夠在產(chǎn)品開發(fā)的早期階段識別并修復錯誤。結(jié)果，這導致錯誤和迭代次數(shù)的減少。

縮短價值實現(xiàn)時間

減少錯誤可以減少完成項目和實現(xiàn)投資有效性所需的時間。在競爭激烈的環(huán)境中，這可能是一個重要的好處。

削減開發(fā)成本

如果時間和材料合同是您選擇的選項，那么清晰概述的需求列表可能是一個寶貴的優(yōu)勢。

更好的用戶體驗

可靠的產(chǎn)品需求使您能夠構(gòu)建一個解決方案，為所有利益相關(guān)者帶來額外的商業(yè)價值。嘗試包括用戶正在等待的功能。

亞馬遜提供對其AVS 產(chǎn)品要求的開放訪問，因為 Alexa 的技能開發(fā)人員應(yīng)該熟悉用戶期望和產(chǎn)品的關(guān)鍵功能。亞馬遜告訴完整的功能性和非功能性需求指南將使開發(fā)人員能夠提供最佳的用戶體驗。此外，這可以為所有使用 Alexa 產(chǎn)品的開發(fā)人員制定相同的政策和標準。

如果我們沒有任何需求管理系統(tǒng)怎么辦

沒有必要應(yīng)用特定的系統(tǒng)。您可以采用問題跟蹤程序、項目管理工具或版本控制系統(tǒng)來記錄您的需求。

但是，如果您根本不寫下要求，那么您就是在冒險。

例如，某些功能可能會被省略或未按照您想要的方式實現(xiàn)。

讓我們考慮另一個例子。由于您的業(yè)務(wù)增加，您的軟件也將增長。因此，建議在某個地方注意預(yù)期的項目持續(xù)時間并保持時間安排。

需求分類

需求類別

項目需求通常分為三個主要類別：業(yè)務(wù)、解決方案和涉眾需求。

• 業(yè)務(wù)需求包括有關(guān)客戶目標、目標用戶和產(chǎn)品總體需求的信息和內(nèi)容。此時，您應(yīng)該找出客戶希望通過產(chǎn)品實現(xiàn)的目標。由于所有決定都將基于此信息，因此這些要求應(yīng)盡可能詳細。

• 涉眾需求假設(shè)用戶需要什么才能獲得良好的產(chǎn)品體驗。在此階段，您應(yīng)該規(guī)劃產(chǎn)品地圖、布局線框、考慮到達的設(shè)備和用例。請注意，利益相關(guān)者的需求可能很難競爭。如果管理不當，這會對項目的進度、預(yù)算和范圍產(chǎn)生負面影響。

• 在解決方案需求階段，你之前決定的一切都應(yīng)該根據(jù)當前可用的系統(tǒng)進行規(guī)劃。這種類型的需求包括功能需求和非功能需求。

• 功能需求描述了產(chǎn)品或服務(wù)需要做的事情。

• 非功能性需求描述了系統(tǒng)應(yīng)該如何運行。

什么是功能性和非功能性要求？

清晰的功能和非功能需求可讓您降低應(yīng)用程序開發(fā)成本并節(jié)省時間。簡而言之，功能性和非功能性需求的區(qū)別如下：

• 功能需求驅(qū)動系統(tǒng)的應(yīng)用架構(gòu)，而非功能需求驅(qū)動系統(tǒng)的技術(shù)架構(gòu)。這意味著功能需求包括您未來項目的所有功能以及用戶參與其中的方式。然而，非功能性需求描述了系統(tǒng)如何工作。

• 通常，功能性需求以“系統(tǒng)必須執(zhí)行<requirement>”的形式表達，而非功能性需求則以“系統(tǒng)應(yīng)該是<requirement>”的形式表達。

• 功能需求很容易定義。要識別非功能性需求，您需要分析產(chǎn)品的性能。

Karl E. Wiegers 的下圖顯示了功能需求和非功能需求之間的關(guān)系

什么是功能要求

功能需求定義了軟件的內(nèi)部工作。簡而言之，它們描述了應(yīng)該由網(wǎng)絡(luò)和應(yīng)用程序開發(fā)人員實現(xiàn)的產(chǎn)品功能。例如，這可以為用戶提供通信通道或?qū)?shù)據(jù)從一種格式傳輸?shù)搅硪环N格式。

例如，對罐子的功能要求是它能容納液體，并有一個帶螺紋的蓋子頂部以密封果醬以更好地保存

通常，功能需求包括一個唯一的名稱和編號、一個簡短的描述，以及對需要這些需求的原因的描述。

對于軟件開發(fā)公司和利益相關(guān)者而言，描述應(yīng)該清晰準確。如果產(chǎn)品不符合功能要求，通常意味著該產(chǎn)品質(zhì)量低劣。

暫時從閱讀切換到視頻，看看由華盛頓大學和威斯康星大學創(chuàng)建的功能需求的一些很好的例子。

請注意，即使未滿足非功能性要求，也可以認為滿足功能性要求。

功能需求部分應(yīng)包括以下數(shù)據(jù)：

• 設(shè)計范圍。由于并非所有項目階段都同時完成，因此設(shè)計范圍可能會有所不同。每個開發(fā)階段可能有自己的設(shè)計范圍。您可以應(yīng)用的最佳意見之一是用例圖。

• 系統(tǒng)功能。要定義所需的系統(tǒng)功能，請考慮用戶如何與軟件交互以及系統(tǒng)提供什么樣的響應(yīng)。這些東西經(jīng)常寫在用例和 UI 規(guī)范文檔中。

• 數(shù)據(jù)定義。您應(yīng)該定義允許值和默認值、字段長度等。

• 用戶類。將使用該軟件的人群：客戶、訪客、員工、管理層或組織的代表。

• 用戶界面。屏幕摘要、報告布局和方案。請注意，您應(yīng)該詳細解釋每個屏幕的操作方式。

功能需求的主要類型

這些需求可能會出現(xiàn)在功能需求的規(guī)范文檔中。本文檔重點介紹了該軟件的主要特性和功能。它可以僅涉及功能需求，也可以涉及用戶故事或用例等其他類型。

通常，規(guī)范由以下部分組成：

• 目標。在本節(jié)中，您應(yīng)該指定背景、關(guān)鍵定義和系統(tǒng)概述。

• 描述。本節(jié)假定了主要功能、產(chǎn)品愿景、業(yè)務(wù)規(guī)則和假設(shè)的大綱。例如，您可以定義將用于數(shù)據(jù)處理的工具并簡要描述產(chǎn)品改進策略。

• 具體要求。在這里，我們建議您描述功能、系統(tǒng)屬性、數(shù)據(jù)庫特性、連接等。

• 用例。用例定義人機交互的功能和有價值的方面。描述如何在系統(tǒng)中開始工作，它將如何響應(yīng)用戶操作，并概述每個功能用例的場景。

用例規(guī)范模板

用例文檔通常包括以下幾個部分：

• 
  

• 演員。這些用戶將與您的軟件進行交互。參與者可以是人或系統(tǒng)。但請注意，它們不是系統(tǒng)的一部分。例如，在學習管理系統(tǒng)中，這些參與者可以是訪客、學生、員工或管理員。

• 系統(tǒng)。這是描述產(chǎn)品預(yù)期行為的功能列表。

• 功能。功能需求指定了每個用戶組和系統(tǒng)之間交互所必需的功能。

• 協(xié)會。這部分定義了系統(tǒng)的不同特性和相關(guān)參與者之間的關(guān)系。

• 用戶故事。與用例相比，用戶故事從用戶的角度定義交互。本文檔通過考慮所有用戶的動機和期望來概述可能的交互。用戶故事文檔通常采用以下結(jié)構(gòu)：

作為一個<role>，我想要<goal/desire>，這樣<benefit>

但較短的版本也很常用：

作為一個<role>，我想要<goal/desire>

示例：作為用戶，我想從商店下載應(yīng)用程序，然后注冊/登錄、按人名搜索照片、查看照片和更新、設(shè)置喜歡以及上傳媒體文件。

請注意，有時用例與用戶需求不相關(guān)。在這種情況下，清晰的用戶故事文檔使您能夠決定哪些用例是必要的。

敏捷開發(fā)團隊在直觀、可視化的積壓工作中組織用戶故事，也稱為用戶故事地圖。這使人們能夠了解系統(tǒng)的功能，并找出差距和遺漏。

• 功能分解或工作分解結(jié)構(gòu) (WBS)。功能分解是一種可視化文檔，可讓您將復雜的流程劃分為更小的部分。因此，您可以有效地理解和管理復雜的開發(fā)流程。此外，您可以更準確地估算項目時間表和成本。或者，如果出現(xiàn)問題，該結(jié)構(gòu)可以讓您找出系統(tǒng)的哪一部分出現(xiàn)故障。

各個部分及其層次結(jié)構(gòu)通常以功能分解圖的形式呈現(xiàn)，其中包含總體功能和所需的子任務(wù)。

功能分解的例子

• 軟件原型使您能夠闡明項目愿景和開發(fā)過程中的主要挑戰(zhàn)。原型概述了您的解決方案將如何運行并提供用戶與解決方案交互的示例。

原型有兩種一般形式：

• 一次性原型。這樣的原型是直觀地表示需求的快速且廉價的選擇。

• 
  

• 增量或一次性原型。這是一個更加復雜和強大的原型，將不斷完善和重建。盡管進化原型可能不具備用戶計劃的所有功能，但它們是功能性系統(tǒng)，甚至可以變成 MVP。

您如何確定功能要求？

在定義功能需求時，我們建議您：

• 描述您需要的功能，而不是您計劃應(yīng)用的工具。

• 請記住用戶與系統(tǒng)的交互。

• 關(guān)注外觀的詳細表示，而不是代碼設(shè)計和實現(xiàn)。

但是，請記住，在記錄功能需求時，請使您的語言足夠詳細。因此，您的開發(fā)團隊將清楚地了解所需的解決方案以及實施它的所有其他方法。您還應(yīng)該避免使用技術(shù)術(shù)語與主題專家建立有效的溝通。

什么是非功能性需求？

非功能性需求指定您的項目、系統(tǒng)或流程的行為方式。這些需求將隨著業(yè)務(wù)需求的變化而創(chuàng)建、更改和調(diào)整。

通常，非功能性需求是通過使用類別來組織的：操作性、修訂性或過渡性。

這使您能夠評估項目的成功、定義重要的用戶期望并控制產(chǎn)品質(zhì)量。

非功能性需求的替代術(shù)語是“約束”、“質(zhì)量屬性”、“質(zhì)量目標”和“服務(wù)質(zhì)量需求”

下面我們將仔細查看基本的非功能性需求列表。

可用性

可用性已被 ISO 定義為在特定的使用環(huán)境下，特定用戶可以使用產(chǎn)品以達到特定目標的有效性、效率和滿意度的程度。簡而言之，可用性是用戶使用您的產(chǎn)品完成給定任務(wù)的難易程度。可用性是基于扎實的研究和測試做出的選擇的結(jié)果。

請注意以下事項：

• 您的產(chǎn)品應(yīng)該清晰直觀。因此，用戶將在第一次交互時熟悉它。

• 產(chǎn)品應(yīng)該快速引導用戶實現(xiàn)他們的目標。

• 仔細執(zhí)行某些可用性原則可以讓您設(shè)計出有效、高效且令人愉悅的產(chǎn)品。

法律或監(jiān)管要求

根據(jù)您感興趣的領(lǐng)域和您的業(yè)務(wù)重點，可能會有各種法規(guī)和法律義務(wù)。請注意，違反這些規(guī)定可能會受到法律處罰。

法律或法規(guī)要求使您能夠描述產(chǎn)品對法律的遵守情況。但是您應(yīng)該熟悉您的產(chǎn)品必須遵守的行業(yè)法律。此外，您應(yīng)該擁有地方當局要求的所有許可證。

例如，在美國，醫(yī)療移動應(yīng)用程序必須符合 HIPAA 要求。基于歐洲的醫(yī)療應(yīng)用程序必須符合通用數(shù)據(jù)保護條例 (GDPR)。在英國，主要的監(jiān)管立法是新的數(shù)據(jù)保護法或 DPA 2018。

可靠性

可靠性是您產(chǎn)品的一項重要的非功能性需求。這通常指定產(chǎn)品是否可以在多次交易或特定時期內(nèi)無故障運行。

要概述有效的可靠性要求列表，您應(yīng)該：

• 定義您希望解決方案執(zhí)行的一致性以及您需要哪些維護和支持以確保它保持這種狀態(tài)。

• 探索相關(guān)解決方案、它們的弱點和功能。

• 分析技術(shù)報告、新聞、新行業(yè)觀點和見解以考慮安全風險。

• 在選擇合適的技術(shù)堆棧時考慮技術(shù)堆棧的常見問題。

表現(xiàn)

性能概述了您的解決方案在各種用戶交互場景中的表現(xiàn)。這指定了并發(fā)用戶數(shù)、系統(tǒng)或查詢響應(yīng)時間、系統(tǒng)在內(nèi)存、磁盤空間和數(shù)據(jù)量方面的容量。

牛奶包裝的 NFR 可以是“一個包裝的生產(chǎn)成本不應(yīng)超過 0.20 美分”

您應(yīng)該注意的主要挑戰(zhàn)清單

• 主觀意見。非功能性需求可以由不同的用戶以不同的方式定義。確保您的文檔包含說明和示例。

• 不一致。非功能性需求可能直接相互矛盾。它們通常會對整個系統(tǒng)產(chǎn)生顯著影響。

• 術(shù)語不清。混淆定義可能會導致對非功能性需求缺乏理解。

• 假設(shè)這個要求是顯而易見的。當您創(chuàng)建具有非功能性需求的文檔時，有些要點似乎是顯而易見的。例如，統(tǒng)計數(shù)據(jù)應(yīng)由 Google Analytics 跟蹤。通常，許多這些“顯而易見”的要求幾乎會立即被遺忘。

如何定義非功能性需求

要定義非功能性需求，我們建議您盡早采用最佳實踐。您將在下面找到非功能性需求文檔的必須實施操作列表。

• 使用定義的分類。這些要求通常分為三組：操作、修訂和過渡。

• 使用一組預(yù)定義的問題。這使您能夠提高開發(fā)團隊的工作效率并節(jié)省時間。

• 與開發(fā)團隊合作。持續(xù)的溝通可以讓您與開發(fā)團隊達成共識。您應(yīng)該促進需求文檔計劃會議并安排對話。此外，我們建議您記錄并分享您的筆記，并將最終草稿放在文檔中。

• 讓利益相關(guān)者參與進來。盡早與所有相關(guān)方討論非功能性需求。

• 使用模板。比較非功能性需求時，軟件產(chǎn)品有很多共同點。因此，收集以前的需求來構(gòu)建完整的項目圖一定會讓您受益。特別是如果您的企業(yè)專注于電子商務(wù)或電子學習應(yīng)用程序開發(fā)。確定您可以在何處重新調(diào)整某些需求文檔的用途，以將其模板化以供將來在其他項目中使用。

• 考慮用戶的反饋。用戶的反饋使您能夠指定新的功能需求或發(fā)現(xiàn)您的一些需求是不相關(guān)的。

• 使用最先進的工具。應(yīng)用自動化測試工具，例如 Selenium、TestComplete、Robot Framework、Xamarin.UITest、Espresso、XCUITest 和 Appium。這些工具將有助于更快地檢查您的產(chǎn)品性能并揭示更多非功能性需求。

• 通過開發(fā)、測試、維護和擴展過程重新考慮需求。此外，您可以用 1 到 10 的等級評估每個要求。

• 假設(shè)利益相關(guān)者一無所知。盡可能多地定義。對于每一點，問“為什么”5 次，以確保您編寫了正確且合乎邏輯的要求。

筆記。“系統(tǒng)應(yīng)該易于使用”不是一個合適的可用性要求。您應(yīng)該通過應(yīng)用特定指標來指定易于使用的術(shù)語。

功能與非功能需求示例

通過真實世界的經(jīng)驗和案例，將更方便地找到功能需求和非功能需求之間的差異。現(xiàn)在，讓我們看一下流行的平臺和應(yīng)用程序，考慮如何編寫它們的功能和非功能需求。

功能需求和非功能需求之間的區(qū)別

上面的信息應(yīng)該已經(jīng)滿足了你的基本好奇心。為了以最方便的方式找出功能性和非功能性需求之間的區(qū)別，讓我們仔細看看下表。

簡而言之

功能需求和非功能需求之間的區(qū)別并不是那么重要。但請注意，應(yīng)考慮這兩種類型。

但我們的經(jīng)驗表明，客戶主要考慮的是功能需求。如果他們過去有過糟糕的體驗，則非功能性需求已被考慮在內(nèi)。