跳去內容

軟件需求

出自維基百科，自由嘅百科全書

軟件需求係軟件工程上嘅重要概念，講緊要製作嗰隻軟件有咩需求，即係隻軟件要解決啲乜嘢問題。郁手製作之前，軟件工程師梗會思考吓呢啲需求，界定隻軟件整嚟係要解決咩問題，達到咩目標，亦可能要講清楚啲假設同埋分析終端用家有咩需要同期望。諗掂呢啲嘢之後，軟件工程師就要講清楚隻軟件嘅主要特徵，以及呢啲特徵會點樣解決手上嘅問題。佢哋往往仲要寫低一系列文件，記錄軟件需求思考階段定立咗嘅諗法。

喺軟件工程中，軟件需求係成個 project 溝通嘅焦點。開發人員、測試人員同埋持份者（客戶同用家呀噉）都要攞住同一份軟件需求文件，對齊目標，確保大家理解一致。缺乏清晰嘅需求，就好容易出現各自解讀，最後整出嚟嘅系統唔符合用家期望，嘥時間同精神。

確立咗軟件需求之後，工程師就要進入軟件設計工序。

用家、系統

[編輯]
睇埋：用家體驗

喺軟件工程中，用家需求[1]係指終端用家希望系統達成嘅功能或者目標，通常以自然語言表達同埋比較籠統[註 1]。相比之下，系統需求[2]就會詳細描述系統應該點樣實現用家需求，會包括功能、介面、效能同埋技術限制等比較技術性質嘅資訊，不過系統需求寫嗰陣唔會包含具體執行細節，唔會包括設計模式或者源碼等嘅資訊。用家需求往往可以透過多種唔同嘅系統需求去實現。譬如而家要製作流動應用程式，而用家需求係要可以用隻 app 買外賣，針對住呢個需求，設計團隊可以有好多種唔同嘅系統需求去實現，例如係：

  • 系統需求 A：用家可以喺 app 上揀餐廳、揀餐點，然後填寫送貨地址，落單；
  • 系統需求 B：用家可以掃 QR code 嚟快速打開餐廳嘅網站，再用事先記低嘅付款資料直接落單；

等等。有工作者指，軟件工程嘅核心目標就係攞住用家需求，制定點樣衡量啲需求係咪成功達到[註 2]，諗出一個個設計，編寫源碼同系統，令系統可以實際滿足用家真正想要嘅功能[3]。

非功能需求

[編輯]
睇埋：可用度

功能需求係指終端用家期望軟件具備嘅具體功能。雖然每隻軟件都有佢獨特嘅功能需求，但無論隻軟件係用嚟做乜，軟件工程師通常都會期望佢具備某啲通用嘅特性。呢啲唔係功能本身，但對軟件整體質素嚟講重要嘅要求，就係所謂嘅非功能需求[4][5]。

非功能需求嘅例子有以下呢啲：

  • 可測試度：指一隻軟件要容易做測試－喺整好咗隻軟件嘅原型之後就要做測試搵吓隻軟件有冇錯處；舉個簡單例子，軟件工程師可以要隻軟件記低啲 log（要隻軟件記住自己行嗰陣喺邊個時間點發生咗咩事），而呢點會幫軟件工程師手搵出錯處喺邊[6]。


紀錄咗隻軟件行嗰陣發生咗嘅事嘅 log，當中每件事都掕住個時間；喺軟件工程師測試隻軟件嗰陣，呢啲資訊可以幫到手估計隻軟件行起上嚟到底係乜嘢出咗錯。


  • 可返用度：指隻軟件或者隻軟件啲組成部份可以攞去返用－喺軟件工程師做嘢嗰時，佢哋要設計完一隻軟件跟住去設計下一隻，而事實表明咗，有好多演算法同子程序都係唔同嘅軟件都會用到嘅，所以一位軟件工程師做嘢嗰陣成日都會諗起而家整緊嗰隻軟件可以用返某啲打前整過嘅軟件用過嘅嘢；因為噉，軟件工程師通常都會特登將隻軟件整到裏面啲嘢可以輕易噉攞去返用[7]。例子可以睇吓電子遊戲製作當中嘅遊戲資產。
  • 頑健度：指個程式有幾能夠預測同應對一啲佢自身以外嘅差錯，包括輸入嘅資料唔啱款（例如係輸入需要係浮點數但用家俾咗個字符）、要用嘅資源（好似係記憶體）唔夠用以及係用家方面嘅出錯呀噉。一個強健嘅程式能夠喺佢自己以外嘅嘢出錯嗰陣有方法應對－簡單講可以想像成「if 有問題，then 用噉噉噉嘅步驟嚟應對」，至少唔會搞到輕機[8]。
  • 易用度：指一個普通嘅用家有幾易可以正確噉運用呢個程式。一個易用嘅程式會寫得好清楚、冇啲唔等使嘅指令、仲會有好多附加嘅內文嚟解釋每段指令係為乜而存在嘅；呢啲因素令到經驗冇咁豐富嘅編程員或者冇份寫嗰個程式嘅編程員能夠一睇就知嗰個程式做緊啲乜嘢，第時有其他人接手隻軟件嗰陣就冇咁撈絞。人機互動（HCI）呢門專係研究點樣令電子架生更加易用嘅電腦科學領域對易用度有詳細嘅研究[9]。


冇縮排冇注釋： 有縮排有注釋：
def find_max (L):                                   
max = 0
for x in L:
if x > max:
max = x
return max

# 入嘅嘢：一列冧巴，叫佢做「L」。
# 出嘅嘢：L 入面最大嘅冧巴。

def find_max (L):  # 定義乜嘢係「去搵 L 嘅最大值」。
   max = 0         # 設最大值做 0。
   for x in L:     # 為咗 x 喺 L 入面。
      if x > max:       # 如果 x 大過最大值。
         max = x         # 設最大值做 x。
   return max      # 俾返個最大值出嚟。
# 有縮排有注釋嘅程式易睇好多，
# 對第時接手嘅編程員嚟講會易用啲。


四大工序

[編輯]
睇埋：軟件工程

需求獲取

[編輯]
内文：需求獲取

需求獲取呢個階段，主要目的係搵出用家、持份者同埋系統本身對功能同約束條件有啲咩期待。呢個階段要做嘅，係由含糊嘅諗頭做起始，逐步搵清楚軟件需求，可以用到好多唔同嘅資訊來源，諸如係訪問持份者、參考現有系統、分析商業規格文件... 等等[10][11]。

需求獲取嘅過程唔係做一次就搞掂，而係要經過反覆思考、驗證、再深入理解。設計團隊好多時會由一啲抽象或者模糊嘅描述做起始點，例如「我想個系統易啲用啲」噉，然後再逐層加細節，慢慢清楚到底易用係指咩：係唔使 log in [12]？定係指自動補全？又或者指唔好有太多畫面跳嚟跳去？呢種逐步添加細節嘅過程，係需求獲取階段嘅核心特色[13]。

需求分析

[編輯]
内文：需求分析

需求分析講緊項目初期收集並釐清用家同持份者嘅需求（需求獲取）後，要將呢啲需求轉化為可以實作嘅系統規格。要做需求分析嗰陣，軟件工程師要分析現有系統、建立用例、畫出流程圖以及需求規格文件。喺呢個過程中會遇到唔少困難，譬如係用家表達含糊、唔同需求間有矛盾、以至需求隨時間改變[註 3]... 呀噉[14]。

故障樹分析可以算係風險分析嘅一環，講緊要分析個系統發生故障（可以睇睇程式出錯嘅概念），可能由邊啲「基層」事件引起。故障樹分析會用到遞歸式嘅分析，可以想像根部係最終故障，例如伺服器輕機，樹枝就係中間原因，而樹葉就係最「基層」嘅出錯事件，例如冷卻風扇壞咗、電源短路、用家撳錯掣等等。好似下圖噉，內有數字嗰啲圓形係基層出錯，而將若干個基層出錯連埋嘅圖形係邏輯門[註 4]而若干個基層錯誤之間同時或個別出現，就可以引致根部所代表嗰個大錯誤。有咗故障樹圖，工程師跟住就可以規劃容錯機制[15]。

需求說明

[編輯]

軟件需求說明（英文：SRS）係軟件工程中一份份正式嘅文檔，用嚟清晰、有系統噉記錄隻軟件應該具備嘅所有需求。完整嘅軟件需求說明文件通常會包括系統嘅目的（整嚟做乜嘢）、背景資料、用家特徵、功能性質需求、非功能性質需求、限制等等，亦會包括實作性質嘅資訊，譬如係用家介面同埋記憶體限制呀噉。軟件需求文件既係開發團隊嘅藍圖，亦係客戶對成果嘅驗收依據[16]。

由於唔同持份者對資訊深度嘅要求都唔同，需求說明文件往往會拆成幾份：高層摘要版本內容較抽象，偏向描述用家可以做乜、系統會有咩功能等，唔會點用行話，主要寫俾非技術背景嘅持份者或者客戶睇，方便討論整體方向；相比之下，詳細技術版本內容較 technical [17]，主要寫俾開發團隊、測試人員同埋維護人員睇[18]。

大學以至第啲會教授軟件工程技能嘅組織，好多時都會提供軟件需求說明文件嘅樣版，教人點樣寫呢啲文件[19]。

需求確認

[編輯]

需求驗證（參見英文：validate [20]）重點要問以下呢條問題：

團隊做需求分析同說明嗰陣確立咗嘅功能，係咪真係對用家有價值嘅？

驗證要確認寫落嚟嘅需求真正反映到個客真正想要嘅系統功能，重點包括邀請客戶親身參與驗證過程，包括睇原型、試用個系統、俾意見等等，確保開發出嚟嘅產品冇錯誤理解需求，而唔係單靠工程師自己解讀文檔嘅內容[11][21]。

做需求驗證嘅時候，開發團隊好多時會整原型（英文：prototype） 出嚟（可能係紙本或者簡化版系統），搵個客以及持份者親身試用個系統，睇吓需求有冇含糊、矛盾。需求文件冇問題，之後就可以落實開發。原型喺呢個階段特別重要，因為文本描述有限，好多嘢要實際操作先感受得清楚，例如個客話操作流程要簡單，佢試用原型嗰陣可能會發覺某啲位唔好用，同佢原先嘅諗法有出入。

進一步睇

[編輯]

註釋

[編輯]
  1. ↑ 呢點被指係誤解嘅一大來源。
  2. ↑ 可能要搵量化指標嚟衡量呢點。
  3. ↑ 因此，工程師思考需求嘅時候，往往會諗吓啲需求當中邊啲較大機會出現變化。
  4. ↑ 反映與同或等嘅關係。

引咗

[編輯]
  1. ↑ 英文：user requirement
  2. ↑ 英文：system requirement；有別於硬件考量所講嗰種系統需求。
  3. ↑ Maiden, N. (2008). User requirements and system requirements. IEEE software, 25(2), 90-91.
  4. ↑ Software Engineering | Introduction to Software Engineering. GeeksforGeeks.
  5. ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "Characterizing Architecturally Significant Requirements". IEEE Software. 30 (2): 38–45.
  6. ↑ Shalloway, Alan; Trott, Jim (2004). Design Patterns Explained, 2nd Ed. p. 133.
  7. ↑ Lombard Hill Group (October 22, 2014). "What is Software Reuse". www.lombardhill.com. Lombard Hill Group.
  8. ↑ 1990. IEEE Standard Glossary of Software Engineering Terminology, IEEE Std 610.12-1990 defines robustness as "The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions".
  9. ↑ Wegge, K. P., & Zimmermann, D. (2007, July). Accessibility, usability, safety, ergonomics: concepts, models, and differences. In International Conference on Universal Access in Human-Computer Interaction (pp. 294-301). Springer, Berlin, Heidelberg
  10. ↑ Davis, Alan Mark. (2005). Just enough requirements management : where software development meets marketing. New York: Dorset House Pub. ISBN 0-932633-64-1. OCLC 57211148.
  11. 1 2 Abelein, U., Sharp, H., & Paech, B. (2013). Does involving users in software development really influence system success?. IEEE software, 30(6), 17-23，佢哋噉講："... users are typically involved only in the system's requirements definition and validation stage."
  12. ↑ 粵拼：粵化口語音：lok1 in1/lok1 jin1
  13. ↑ Goguen, J. A., & Linde, C. (1993, January). Techniques for requirements elicitation. In [1993] Proceedings of the IEEE International Symposium on Requirements Engineering (pp. 152-164). IEEE.
  14. ↑ Kotonya, Gerald; Sommerville, Ian (1998). Requirements Engineering: Processes and Techniques. Chichester, UK: John Wiley and Sons.
  15. ↑ Ericson, Clifton (1999). "Fault Tree Analysis - A History" (PDF). Proceedings of the 17th International Systems Safety Conference. 原著 (PDF)喺2011-07-23歸檔. 喺2010-01-17搵到.
  16. ↑ Maiden, N. (2011). Exactly how are requirements written?. IEEE software, 29(1), 26-27.
  17. ↑ 粵拼：粵化口語音：tek1 nik4 kou4
  18. ↑ Ramamoorthy, C. V.; Ho, S. F. (1975-04-01). "Testing large software with automated software evaluation systems". SIGPLAN Not. 10 (6): 382–394. doi:10.1145/390016.808461. ISSN 0362-1340.
  19. ↑ SRS Sample，由密芝根州立大學提供嘅軟件需求文件樣本。
  20. ↑ 個詞可作粵拼：粵化口語音：vaa1 lit4 dei4
  21. ↑ Poppendieck, M., & Cusumano, M. A. (2012). Lean software development: A tutorial. IEEE software, 29(5), 26-32，Trends 嗰部份有講 validation 嘅內容。
  22. ↑ Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.

資源

[編輯]
由「https://zh-yue.wikipedia.org/w/index.php?title=軟件需求&oldid=2312829」收