獲取軟件需求毛新軍國防科技大學計算機學院xjmao@軟件工程內容獲取軟件需求的方法軟件需求的方式和過程明確問題及軟件解決方案Problem

SoftwareSolution導出和構思軟件需求如何從利益相關方導出和構思軟件需求描述初步的軟件需求自然語言描述和可視化建模確認和驗證初步軟件需求1.1何為獲取軟件需求？軟件需求不會無緣無故的產生，也不應是無源之水、無本之木，任何軟件需求都有其出處以及動機，即它從何而來、目的是什么獲取軟件需求是指得到或產生軟件需求獲取軟件需求是需求分析的基礎，是軟件開發的首要工作軟件需求從何而來？軟件開發的動機解決特定行業和領域的問題，體現意義和價值示例：“MiNote”是為了幫助用戶編寫和管理便簽；“12306”是為了幫助旅客解決購買火車票費時費力的問題；“ElderCarer”是為了解決空巢老人在家無人看護的問題。解決軟件利益相關方的訴求軟件系統的受益者，軟件需求的提出者利益相關方有哪些，他們會對軟件提出什么樣的期望和要求示例：“12306”利益相關者是旅客，服務于旅客期望和要求軟件開發者也可以充當軟件的利益相關方許多軟件系統的需求來自軟件工程師，而非最終的用戶示例：如開源軟件，微信軟件，12306軟件等等他們充當軟件的用戶或客戶，構思和提出軟件需求原因是找不到實際的用戶來提出需求開源軟件的許多需求來自軟件開發者，而非最終用戶提出軟件的功能性構思及需求，并以Issues的形式提出1.2獲取軟件需求的方式軟件需求用戶和客戶軟件開發者其他軟件系統互聯網大眾導出構思和創作重用構思和創作已有的系統分解軟件需求來自不同的源頭大模型生成生成思考和討論微信和“12306”軟件的需求從何而來？開源軟件的需求從何而來？飛機控制軟件系統的需求從何而來？要獲取的軟件需求要素Who，誰會關心該項軟件需求，他們有何特點和訴求What，軟件需求的內涵是什么Why，為什么需要軟件需求，想解決什么樣的問題Where，軟件需求歸屬于哪些子系統How，軟件需求包含哪些行為，它們是如何來解決問題的When，什么時候需要該項軟件需求要說清楚一項軟件需求，就需要說清楚有關需求的以上6個方面內容獲取軟件需求面臨的困難需求想不清軟件需求并非簡單地實現應用領域中的業務流程，而是要將業務流程進行改造，形成基于軟件的解決方案軟件的利益相關方雖然對業務流程非常熟悉，但是要對其進行改造、形成軟件需求實則較為困難需求道不明不清楚軟件需求的具體內涵，很難清晰、準確和詳實地講明白軟件需求是什么，從而無法獲取足夠多的軟件需求信息軟件需求不明確，需求內容不詳實，軟件需求質量低等等需求想不到一些軟件系統是全新的，在現實世界沒有可模仿和參照的對象。軟件利益相關方和需求工程師要構思出軟件需求將變得更加困難1.3獲取軟件需求方法訪談和會議(Interview)調查問卷(Questionnaire)現場觀摩分析業務資料軟件原型群體化方法大腦風暴構思（Brainstorming）大模型生成……訪談和會議召開相關的會議走訪相關的人員參加的人員包括：用戶、客戶、需求分析人員、質量保證人員等等從訪談和參與會議的對象中獲得軟件需求調查問卷設計調查問卷了解業務流程、實際操作過程用戶的期望和要求對誰進行調查應用領域中扮演不同角色的用戶如何利用調查問卷從調查問卷中了解業務流程從調查問卷中掌握用戶需求從調查問卷的回答中獲得軟件需求如設計一個問卷，調查車站旅客對12306軟件的期望和要求示例：通過調查問卷來獲取軟件需求設計調查問卷，詢問旅客對12306軟件需求及其優先級需要哪些功能哪些功能優先在火車站尋找旅客開展問卷調查，根據調查的結果確定軟件需求及其優先級現場觀摩業務的過程、步驟和輸出業務的工作流程及細節從現場觀摩中了解業務流程，進而獲得軟件需求如觀摩售票窗口的購票過程分析業務資料收集重要的業務資料閱讀和分析業務資料通過閱讀業務資料來了解業務及其流程，進而獲得軟件需求如銀行國際交易的業務材料，火車調度的業務資料大腦風暴將與軟件系統相關的一幫人組織在一起，非正式、開放地、甚至沒有明確主題的散漫討論，從中捕捉軟件需求的靈感和認識該方法適合于那些需要對軟件需求進行開放構思和自由創作的軟件系統軟件原型需求工程師根據用戶初步需求描述，快速構造出一個可運行的軟件原型展示業務操作流程以及每一個步驟用戶與軟件之間的交互用戶可以通過操作和使用該軟件，分析需求工程師是否正確地理解了他們所提出的軟件需求，發現軟件原型所展示的軟件需求中存在的問題，導出尚未發現、新的軟件需求軟件原型作為需求工程師和用戶之間的交流媒介，有助于直觀地展示軟件需求，激發用戶投入到需求討論和導出之中，因而是一項極為有效的需求獲取和分析方法通過軟件原型有助于幫助用戶導出他們所需的軟件要求示例：基于軟件原型來獲取軟件需求“空巢老人看護軟件”的原型讓用戶使用該軟件原型聽取用戶對原型的意見和建議用戶意見就是潛在的軟件需求群體化方法讓互聯網上的海量和開放群體參與到獲取軟件需求的工作中來，提出他們對軟件需求的想法，并通過組織、匯聚和篩選，從中遴選出有價值的軟件需求集思廣益，吸納更多的人參與到需求創作和構思之中，有助于獲得超出開發團隊和用戶常規想定的軟件需求開源軟件的需求就是采用群體化的方法來獲取的依托社會化群體來集體構思軟件的需求，集思廣益借助大模型技術通過大模型工具(如ChatGPT)生成軟件需求給大模型提示（Prompt）理解和遴選生成的軟件需求成立需求分析的聯合工作小組小組成員利益相關者（如用戶）軟件需求分析人員軟件質量保證人員等目的共同工作加強聯系促進交流增進合作1.4獲取軟件需求的過程明確問題及基于軟件的解決方案導出和構思軟件需求描述初步的軟件需求評審初步軟件需求軟件問題和軟件解決方案軟件功能性和非功能性需求初步軟件需求描述存在問題內容獲取軟件需求的方法軟件需求的方式和過程明確問題及軟件解決方案Problem

SoftwareSolution導出和構思軟件需求如何從利益相關方導出和構思軟件需求描述初步的軟件需求自然語言描述和可視化建模確認和驗證初步軟件需求2.1軟件的目的每一個軟件都試圖去解決特定領域中的問題，并提供基于軟件的問題解決方案軟件需求必須服從和服務于軟件欲解決的問題，只有這樣軟件需求才有意義和價值12306軟件買票難、買票費時等問題明確軟件要解決的問題清晰地界定軟件欲解決什么樣的問題與特定領域及其業務相關聯或提高業務工作效率，或解決業務瓶頸問題，或提升業務服務水平和質量等等示例“12306”軟件與鐵路旅客服務這一領域及業務相關聯，國家鐵路集團有限公司投資研制該軟件的目的是要改變落后的旅客服務和業務模式，提高旅客服務質量，降低旅客服務成本定義軟件欲解決問題開展調研分析，切忌拍腦袋憑空想問題鐵路旅客存在買票難的問題不斷反復論證，尋找適合軟件解決的問題通過軟件來支持旅客在線上買票尋求有意義、有價值的問題買票、退票、改簽、打印等等明確基于軟件的問題解決方案軟件可以起到什么作用完成各種計算，作為一種粘合劑來連接不同的設備和系統，實現不同設備和系統之間的交互和協同，從而來解決問題發揮軟件的優勢，為問題解決提供新穎和有效的途徑不是依靠保姆來進行看護，而是借助于軟件來控制機器人來進行看護明確軟件的范圍和邊界描述軟件的范圍，確定軟件的邊界軟件的范圍說明了軟件需要完成哪些業務領域中的功能軟件的邊界描述了軟件的界限，即哪些要素屬于軟件，哪些不屬于軟件；哪些需求要由軟件來完成，哪些需求由其他設備和系統來完成要開發的軟件系統其他系統一些需求由軟件來實現一些需求由其他系統來提供思考和討論微信軟件想解決什么樣的問題？微信如何借助軟件來解決問題？“空巢老人看護”軟件的范圍和邊界是什么？12306軟件的范圍和邊界是什么？內容獲取軟件需求的方法軟件需求的方式和過程明確問題及軟件解決方案Problem

SoftwareSolution導出和構思軟件需求如何從利益相關方導出和構思軟件需求描述初步的軟件需求自然語言描述和可視化建模確認和驗證初步軟件需求3.1識別軟件的利益相關方軟件需求來自于軟件的利益相關方，要獲取軟件需求，首先要搞清楚軟件系統有哪些利益相關方軟件系統的利益相關方可以表現為特定的人群和組織，也可以是一類系統不僅軟件用戶或客戶可以是軟件的利益相關方，軟件的開發者也可以成為軟件的利益相關方。示例：“空巢老人看護軟件”的利益相關方老人（Elder）與系統通過語音方式進行交互，命令系統為其完成某些事務醫生（Doctor）突發或緊急情景時接受呼叫，與系統進行交互以獲取老人狀況家屬（FamilyMember）突發或緊急情景時接受呼叫，與系統進行交互以獲取老人的狀況管理員（Administrator）對軟件系統進行必要的配置和管理機器人（Robot）其運動受軟件系統的控制示例：“Mini-12306”軟件的利益相關方旅客(Passenger)希望提供購票、查詢車次、退票、改簽等功能和服務售票員(TicketSeller)希望能幫助旅客完成購票、查詢車次、退票、改簽等服務系統管理員(Administrator)設置系統的參數等相關信息，如可提前購買多少天的車票等3.2導出軟件的功能性需求需求工程師可以通過與利益相關方的交互，聽取他們對軟件的期望和要求，從他們那里導出軟件需求采用多種方法來導出軟件需求與用戶或客戶的面談分析業務資料觀察業務流程進行問卷調查軟件原型等構思軟件的功能性需求需求工程師需要充當軟件利益相關方的角色，站在他們的視角，來構思軟件需求針對軟件需求開展創作，結合軟件解決方案，提出可有效促進問題解決的軟件需求需求工程師可以采用大腦風暴構思、群體化方法、問卷調查、軟件原型等多種方式來開展需求構思工作需求工程師需要積極和主動地參與到需求獲取的過程中有創意軟件的特點創意來自于欲解決的新穎問題(Problems&Needs)創意來自于解決問題的獨特方式(Approach)創意來自于給用戶帶來的好處(Benefits)創意來自于你強于對手(Competitors)?CopyrightXinjunMao36提出有創意的軟件極為重要，它決定了軟件的開發是否有意義和有價值創意的潛在技術和應用領域移動互聯網機器人無人系統物聯網可穿戴設備大數據分析……37潛在的技術和方法潛在的應用和需求軟件作為載體和手段示例:軟件創意Instagram:照片和視頻共享、在線服務軟件創始人:KevinSystromandMikeKrieger最多只有13個雇員

，5個軟件工程師成立于2010年10月2012年被Facebook收購收購價格為10億美元38

示例：構思“空巢老人看護軟件”功能性需求老人的視角自主跟隨老人，以對老人進行持續跟蹤和感知，獲取老人信息。提醒服務，提醒老人按時服藥、身體檢查等事宜家屬和醫生監視老人狀況，通過智能手機在遠端監視老人在家的狀況，獲得老人的視頻、圖像和語音等方面的信息通知異常情況，將老人的突發異常信息發送給老人家屬和醫生。遠程控制機器人，通過智能手機在遠端來控制機器人移動，以從不同的角度和距離來獲取老人的圖像、視頻和語音信息視頻/語音雙向交互，實現老人、醫生和家屬間的視頻和語音交互站在軟件利益相關方的視角來構思和導出軟件需求

示例：構思“Mini-12306”功能性需求旅客和售票員的視角注冊和登錄查詢車次購票、退票、改簽等系統管理員的視角設置系統參數如設置售票員的賬號和密碼、設置車票提前預售的天數3.3導出和構思軟件的非功能性需求非功能性需求包括軟件質量要求和軟件開發的約束性要求質量要求，如軟件運行性能、可靠性、易用性、安全性、私密性等屬于外部質量要求，軟件可擴展性、可維護性、可互操作性、可移植性等內部要求約束性要求，包括開發進度要求、成本要求、技術選型等軟件的非功能性需求變得越來越重要在某些情況下它們直接決定了軟件是否能用和可用、是否好用和易用、是否高效和可靠運行、是否便于維護和演化等。示例：“空巢老人看護軟件”的非功能需求類別非功能性需求項需求描述性能EC-Req-Performance-01所有界面操作的響應時間應小于1s可靠性EC-Req-Reliability-01軟件系統每周7天、每天24小時可用；在機器人和網絡無故障的前提下，系統正常運行時間的比例在95%以上EC-Req-Reliability-02系統任何故障都不應導致用戶已提交數據的丟失。發生故障后，系統需在10分鐘內恢復正常使用易用性EC-Req-EasyUse-01老人只需通過語音方式與系統進行交互；家屬、醫生和管理人員通過操作手機App來使用本系統EC-Req-EasyUse-02用戶無需專門培訓只需通讀安裝手冊即可完成安裝安全性認證需求EC-Req-Safety-Authentication-01所有用戶（包括家屬和醫生）均需通過用戶名、密碼相結合的方式經系統驗證通過后方可使用本軟件系統權限控制需求EC-Req-Safety-Authorization-001醫護人員只能在老人處于緊急狀況、需要求助時可控制機器人查看老人的狀況，家屬可以在任何時候查看老人的所有信息運行環境約束客戶端EC-Req-Env-Client-001客戶端APP運行在Android4.4及以上版本服務器端EC-Req-Env-Server-001服務器端的軟件運行在Ubuntu14.04及以上版本；本軟件運行時占用的內存空間不得超過128MB示例：“Mini-12306”的非功能需求非功能性需求項非功能性需求描述性能用戶界面操作的響應時間不超過1秒可靠性軟件系統每周7天、每天24小時可用系統正常運行時間的比例在99%以上任何故障都不應導致用戶已提交數據的丟失發生故障后系統需在5分鐘內恢復正常使用易用性界面簡潔直觀，易于操作安全性系統能夠抵御網絡攻擊，保護數據不被非法竊取私密性系統中的用戶數據不被非授權人員訪問和獲取可移植性App軟件能夠方便地移植到其他的移動操作系統環境運行環境約束App須運行在Android4.4、鴻蒙3.0及iOS17以上版本本地化與國際化支持中文和英文兩種用戶界面借助互聯網大眾來構思軟件需求“三人行必有我師焉，三個臭皮匠頂上一個諸葛亮”利用開源社區中的開發者大眾來推動需求構思，獲得多樣化和有新意的軟件需求基于大模型技術及工具生成軟件需求(1/2)根據用戶的提示，生成軟件需求的描述創建與項目目標一致的需求描述，進而生成用戶使用場景的案例，并推薦軟件系統的產品功能開發者以此為基礎，將抽象、籠統的概念轉化為明確、詳實的軟件需求基于大模型技術及工具生成軟件需求(2/2)進一步細化和完善需求提供軟件需求的細節生成需求的用戶故事合法和非法的軟件需求并非軟件利益相關方提出的每項期望和要求都是軟件需求如果他們提出的要求與軟件及其欲解決的問題無關、沒有實際的意義和價值、或者不存在技術等方面的可行性，那么這些要求不應成為軟件需求軟件需求工程師要有一雙“火眼睛”，能夠鑒別和發現真正有意義和有價值的重要軟件需求，剔除“無意義和無價值”的軟件需求軟件創意示例1：無人值守圖書館要解決的問題找尋圖書困難軟件創意線上借閱線下機器人獲取自動找尋線上基于智能終端的借閱線下基于機器人的服務軟件創意示例2：多無人機聯合搜尋軟件系統要解決的問題快速定位被埋人員軟件創意借助手機定位采用無人機編隊搜索自動生成位置內容獲取軟件需求的方法軟件需求的方式和過程明確問題及軟件解決方案Problem

SoftwareSolution導出和構思軟件需求如何從利益相關方導出和構思軟件需求描述初步的軟件需求自然語言描述和可視化建模確認和驗證初步軟件需求4.1描述初步軟件需求初步的軟件需求之所以稱之為是初步的，是因為這些軟件需求還很粗略，只是一個初步的需求輪廓，不夠具體和詳盡，可能有遺漏，會存在不一致和相沖突等問題，后續還需要對其開展進一步的精化和分析描述需求記錄下來、描述清楚，形成相關的軟件文檔便于不同人員（如需求工程師、用戶、客戶等）之間的交流和討論，及時發現需求理解上存在的偏差，支持后續的需求分析工作初步需求的描述方法自然語言描述軟件原型描述用例圖描述4.2自然語言描述自然語言是最為常用的需求描述手段描述軟件的功能性需求、質量需求和開發約束需求等詳細刻畫需求的具體內容和細節可為各方所理解，便于交流和討論自然語言描述的局限性有二義，不同的人看完描述后可能會有不同的理解不直觀，很難從中厘清軟件系統到底有哪些功能性需求和非功能性需求，這些需求之間存在什么樣的關系示例：用自然語言描述的初步軟件需求(1/2)功能性需求描述軟件系統需要對老人在家的狀況進行分析，以判斷是否出現突發異常情況。一旦出現異常情況，就需要通知老人家屬和醫生質量需求描述老人通過語音方式與系統進行交互，系統正確理解老人語音指令的比率應達到90%以上軟件開發約束需求描述客戶端App軟件須運行在Android4.4及以上版本的操作系統示例：用自然語言描述的初步軟件需求(2/2)功能性需求描述軟件系統應提供查詢車次功能，旅客輸入出發地和目的地及日期，系統應查詢出滿足條件的所有車次質量需求描述系統中的用戶數據不被非授權人員訪問和獲取軟件開發約束需求描述客戶端App軟件須運行在Android4.4及以上版本的操作系統4.3軟件原型描述優勢直觀、可展示和可操作有助于需求工程師與用戶或客戶之間的交流和溝通，便于在操作和使用軟件原型的過程中幫助用戶和客戶確認和導出軟件需求不足以操作界面的形式展示軟件需求的梗概，主要是軟件與用戶之間的輸入和輸出，業務的大致流程，無法描述軟件需求的具體細節示例：空巢老人看護軟件的界面原型界面的整體布局顯示的主要信息提供的主要按鈕空巢老人看護軟件前端APP的界面原型示例：Mini-12306APP的界面原型界面的整體布局顯示的主要信息提供的主要按鈕Mini-12306軟件前端APP的界面原型4.4用例圖描述用途描述軟件系統的邊界以及軟件外部使用者所觀察到的系統功能“觀察到”是指外部使用者與系統存在交互，即信息輸入和輸出圖的構成執行者（Actor）：系統的外部使用者用例（UseCase）：觀察到的功能和交互邊：執行者與用例間、用例之間、執行者之間的關系1.執行者(Actor)何為執行者系統之外的實體，他們使用軟件系統功能、與軟件系統交換信息可以是一類用戶，也可以是其他軟件系統或物理設備執行者是UML中的類代表一類用戶或者外部實體，而非具體的對象實例ActorName示例：“空巢老人看護軟件”的執行者老人醫生家屬機器人管理員…執行者通常對應于軟件系統的利益相關方老人醫生家屬機器人管理員示例：Mini-12306的外部執行者旅客售票員系統管理員旅客售票員系統管理員2.用例(UseCase)用例表示執行者為達成一項相對獨立、完整的業務目標而要求軟件系統完成的功能用例的表現形式表現為執行者與系統之間的業務交互動作的序列對于執行者而言，交互目的或者效果在于達成其業務目標對于待開發系統而言，交互的過程即是某項相對獨立、完整的外部可見功能的實現過程UseCase示例：用例“家屬”所看到的用例監控老人狀況遠程控制機器人監控老人狀況遠程控制機器人家屬用名稱表示執行者，用動名詞表示用例購票退票旅客“旅客”所看到的用例購票退票3.執行者與用例間的關系執行者與用例間關系的內涵執行者與用例之間存在交互執行者觸發用例執行，向用例提供信息或從用例獲取信息觸發用例執行的執行者稱為主動執行者，僅從用例獲取信息的執行者稱為被動執行者執行者與用例間的邊通常為無向邊監控老人狀況遠程控制機器人家屬購票退票旅客用例間的關系包含(Include)擴展(Extend)繼承(Inherit)AB《include》《extend》《inherit》用例間的關系-包含關系如果用例B是用例A的某項子功能，則稱用例A包含用例B包含關系用于提取多個用例中的公共子功能，以避免重復和冗余體現了功能分解和組織的思想監視老人狀況自主跟隨老人《include》購票支付《include》用例間的關系-擴展關系如果用例A與B相似，但A的功能較B多，A的動作序列是在B的動作序列中的某些執行點上插入附加動作序列而構成的，則稱用例A擴展用例B用來區隔正常業務處理功能和帶有例外處理的功能避免例外處理邏輯攪亂或湮滅正常處理邏輯體現了功能增強CreateCoursePlanforQianClassCreateCoursePlan《extend》包含和擴展有何區別？用例間的關系-繼承如果A與B相似，但A的動作序列是通過改寫B的部分動作或者擴展B的動作而獲得的，則稱用例A繼承用例B體現了功能改寫AB擴展和繼承有何本質性的區別？邊界框表示整個軟件系統或子系統的邊界邊界框內的用例構成了系統或子系統的內容，如用例外面的是系統之外的執行者systemActorNameUseCase示例：“空巢老人看護軟件”的用例圖圖中有哪些actor圖中有哪些用例圖中有哪些類型的邊，分別表示什么關系示例：“Mini-12306”的用例圖圖中有哪些actor圖中有哪些用例圖中有哪些類型的邊，分別表示什么關系對用例的進一步詳細描述用例名用例標識主要執行者目標范圍前置條件交互動作為什么需要進一步描述用例的這些信息?它有什么作用？示例：用例描述(1/2)用例名：用戶登錄用例標識：UC-UserLogin主要執行者：家屬、醫生目標：通過合法身份登錄系統以獲得操作權限范圍：空巢老人看護軟件前置條件：使用App軟件之時交互動作（1）用戶輸入賬號和密碼（2）系統驗證用戶賬號和密碼的正確性和合法性（3）驗證正確和合法則意味著登錄成功（4）提示登錄是否成功的信息用戶登錄老人家屬醫生示例：用例描述(2/2)用例名：退票用例標識：UC-RefundTicket主要執行者：旅客、售票員目標：將購買的車票退票范圍：Mini-12306前置條件：已經登錄系統交互動作（1）提供待退票的車票（2）驗證車票的合法性（3）將車票退票，設置車票為“未出售”狀態（4）將車票的費用退回到旅客的銀行卡中退票旅客售票員4.5撰寫“初步軟件需求描述”文檔軟件背景介紹欲解決的問題軟件解決方案軟件的功能性需求描述軟件的非功能性需求描述可行性及潛在風險內容獲取軟件需求的方法軟件需求的方式和過程明確問題及軟件解決方案Problem

SoftwareSolution導出和構思軟件需求如何從利益相關方導出和構思軟件需求描述初步的軟件需求自然語言描述和可視化建模確認和驗證初步軟件需求5.1輸出的軟件制品軟件原型以可運行軟件的形式展示了軟件的業務工作流程、操作界面、用戶的輸入和輸出等方面的功能性需求信息軟件用例模型以可視化圖形符號的方式刻畫了軟件系統的執行者、邊界、用例以及它們之間的相互關系，描述了軟件的功能性需求軟件需求文檔以自然語言的方式描述了初步軟件需求，包括功能性和非功能性的軟件需求5.2評審初步軟件需求中肯性，軟件問題是否反映實際問題，是否有意義和價值合理性，基于軟件的解決方案是否科學和合理。完整性，軟件需求是否覆蓋了利益相關方的期望和要求必要性，每一項軟件需求是否有必要溯源性，每一項軟件需求是否都有其來源準確性，描述是否清晰和準確地反映了軟件需求的內涵正確性，是否正確反映該需求提出者真實想法和關注點一致性，軟件需求文檔