2021敏捷軟體工程需求評審答辯問題總結與建議

這次答辯時間比較緊，本文是以提建議為主，因此會確保足夠的建設性，希望大家在需求部分的後續工作中將相關部分進行必要的優化和完善。以及如有疑問，或者需要進一步溝通的話，歡迎在部落格下留言或私聊諮詢助教及老師。

團隊軟體工程的總體目標：

1. 研發出符合使用者需求的軟體說明：要通過實際的工作收集、推導、提煉需求，並在軟體釋出後通過實際資料驗證需求的確被滿足了。需求來自於實際，而不是自己想象出來的“需求”或者人云亦云的需求（例如：圖書館管理系統）。

2. 通過一定的軟體流程，在預計的時間內釋出“足夠好”的軟體說明：這個軟體不是期末前兩天由兩三個同學熬通宵趕出來的急就章，而是經歷了一定的軟體流程，通過全體團隊成員的努力，在一個學期內逐步完成的。

3. 並通過資料和其他方式展現所開發的軟體是可以維護和繼續發展的說明：例如，對使用者需求有詳細的分析，包括對將來這類軟體發展的趨勢的分析。主要功能都有設計文件，原始碼完整，有修改記錄，並有最後版本。關鍵模組有可以執行的單元測試、壓力測試指令碼，等等。對於已知的bug和將來的工作都有詳細的記錄。

（上述內容摘自《構建之法》第1.2節“軟體工程是什麼”）

在後文中

• 【答辯】標籤指的是在現場答辯時所進行的討論內容（僅作為現場答辯的記錄，對於待回答的答辯內容，需要在後續部落格中進行必要的回應）
• 【問題】標籤指的是課程組稽核後提出的問題（對於提問需要在後續部落格中進行必要的回應）
• 【建議】標籤指的是針對問題建議採取的方案（建議內容僅供參考，請根據實際情況自行做出判斷和決定，如有必要則也在後續部落格中進行回應）

以及，為了方便檢視，此處有石墨文件版本：https://shimo.im/docs/ky6ytCqVX99h3HD8，裡面對不同的型別進行了顏色標註，希望可以幫助到各位。

專案與提問

1. 近取 key：背單詞App

部落格地址：https://www.cnblogs.com/mzztxx/p/14648535.html

視訊地址：https://bhpan.buaa.edu.cn:443/link/A69CA3AA38ED728F74E77F52834822D6

訪問密碼：rgaQ

摘要：

* 專案簡介：一款面向具有專攻背單詞需求同學的工具，利用記憶宮殿原理，生成創新性“詞圖”背單詞，開闢背單詞新模式。（網頁端）
* 創新點：全新背單詞形式--詞圖，結合多種強化記憶理論基礎--記憶宮殿、空間聯想記憶等。
* 專案意義：“通過我們的 APP ，使用者可以對於單詞場景式聯想，形成較為長期且系統的記憶。”

問題與建議：

• N（需求）
  • 【問題】你們對於市場做過哪些調查呢，是否對使用者做過產品使用需求調查？
    • 【建議】如果目前還沒有做到完善的話，那麼請繼續完善起來，並且需要提供具體證明，例如相關調查結果（可不侷限於發問卷）或文獻資料等。
    • 【建議】注意避免想當然，也避免使用一些偏直覺向的依據來說明需求。
• A（路線）
  • 【答辯】該應用是否考慮設立排行榜功能？
    • 計劃建立社群，使用者可以分享自己建立的詞圖
    • 考慮做打卡功能
  • 【答辯】背單詞中所提到的圖片和單詞是官方提供，還是完全使用者自己來上傳？
    • 提供現有備選圖片
    • 鼓勵使用者自己上傳，並提供純色模板
• B（優勢）
  • 【答辯】如果希望背大量單詞，這種背單詞的方法是否操作過於繁瑣，如何保證效率？
    • 軟體的目的就是（通過拖拽等動作）鼓勵使用者對單詞建立長期記憶。
  • 【問題】在本專案中提到的記憶宮殿和A4紙的方式確實非常新穎有趣。
    • 但PC端真的比手機端更會讓人專注背單詞麼，
      • 現在都是電腦手機端同時登入微信和QQ等通訊裝置
      • 似乎電腦端更讓人專注這一說法並不很能站住腳。
    • 【建議】因此，為何使用電腦端，其原因、優劣勢、得與失還是有待進一步思考並挖掘的。
• C（競品）
  • 【問題】如何與市場上的其他同類產品競爭，你們軟體的競爭力具體表現為幾點？
    • 關於需求量大的問題，是否調研或瞭解過身邊的同學們，他們希望有款網頁版的背單詞軟體？手機端的扇貝，百詞斬等已經如此成熟，一個使用了很久的使用者會放棄自己的打卡1000天的記錄麼？你又如何會讓一個新的使用者相信你的記憶宮殿方式會比上述軟體更優，來克服使用者慣性呢呢？
    • 以及，即便該專案需求確實廣泛， 但是使用者是否已經用了一種產品了，你的產品有什麼 “相對優勢”呢？關於這一點是否做過實際調查並獲取翔實的調查結果資料？
    • 【建議】該部分需要更加詳細的進行論證，並且拿出實實在在的調研結果為證，分析現有的不足並凸顯出新產品的優勢所在。
  • 【答辯，待回答】和百詞斬等類似產品的主要區別何在？
• D（交付）
  • 【問題】在專案的Alpha階段和Beta階段分別預期有多少每日活躍使用者？

2. Sunny圖表：資料記錄和圖表生成管理小程式

部落格地址：https://www.cnblogs.com/thSunny/p/14651779.html

視訊地址：

摘要：

* 專案簡介：智慧資料圖表生成器。（微信小程式）
* 創新點：多種資料輸入方式，自動生成圖表，定製圖表模板。
* 專案意義：使用者能便捷記錄資料、生成圖表。

問題與建議：

• N（需求）
  • 【問題】使用者在什麼情況下會頻繁使用手機制作圖表呢，專案的核心預期放在識別表格還是繪製資料圖？
    • 【建議】請站在使用者的角度來分析，在什麼樣的場景下會需要用手機而不是計算機來繪製圖表，明確一下使用者的核心需求是什麼。
• A（路線）
  • 【問題】怎麼解決小程式圖形效能差和手機螢幕小的問題？
  • 【答辯】如何實現語音輸入繪製表格的功能？
    • 微信平臺有語音輸入的API，也有OCR的開原始碼
  • 【問題】部落格中提到的語音資料輸入方式是如何實現呢？包括
    • 語音如何方便的輸入繪製表格資料，是否有語音輸入功能的必要？
    • 若有語音輸入的必要，是準備採用哪個平臺提供的API呢？
    • 對於語音輸入功能付費規則有調研過嗎？
    • 【建議】建議對於上述問題進行更加詳細的考察，完善在後續分析中。
  • 【答辯，待回答】物理實驗對資料的精度和正確性有要求，你們準備如何進行****資料的校驗和精確度檢查？
• B（優勢）
  • 你們的軟體功能能夠給使用者帶來什麼好處？解決他們什麼樣的痛點問題？
    • 【建議】在明確需求的基礎上，可以進一步來說明軟體的主要優勢何在，不是談能給使用者提供什麼功能，而是更加著重去明確好處與所解決的痛點。
• C（競品）
• D（交付）
  • 【問題】一般來說，資料分析和畫圖的操作都是在電腦上完成的，是否考慮完成微信小程式以外的應用端？
    • 【建議】進一步明確此問題
      • 如果確實只實現微信小程式，則需要充分定義操作模式，並確保易用性
      • 如果不只實現微信小程式，則需要對其他端（例如管理端）的需求以及業務相關進行必要的定義，確保可用性
  • 【問題】微信小程式需要對網站進行備案才能正式釋出，備案流程需要一個月以上，你們有備案好的網址嗎？
    • 【建議】確認一下是否具備完成該技術棧的必要條件
      • 如果確實具備已備案域名，則可以正常進行，不受影響
      • 如果暫不具備已備案域名，則需要評估備案時間與本課程的週期，而且考慮到域名備案流程可能存在的不可控性，以及後續環節有進行產品實際推廣的考核需求，故建議慎重選擇微信小程式，與之類似的替代方案有安卓App等，考慮到學習成本的話比較推薦PhoneGap這類web友好的技術棧。
  • 【問題】在專案的Alpha階段和Beta階段分別預期有多少每日活躍使用者？
    • 【建議】進一步明確此類問題
    • 並且請注意，使用者數指的是活躍使用者數，而非總註冊使用者數

3. 題士：刷題軟體

部落格地址：https://www.cnblogs.com/sudorm-rf/p/14652612.html

視訊地址：https://www.bilibili.com/video/av417581301?zw

摘要：

* 專案簡介：針對學生考試刷題、學習交流等需求開發的一款集刷題、題目討論、錯題整理、社群資料分享等功能為一體的刷題軟體。（手機App）
* 創新點：實時進行題目的交流和討論，智慧題目推薦。
* 專案意義：隨時隨地便攜刷題，真正做到想刷就刷。

問題與建議：

• N（需求）
  • 【建議】將使用者調研的結果也補充到需求分析報告中。
  • 【問題】對於服務的管理者而言，是否需要一個平臺來進行網站以及題庫相關的管理？如果需要的話，微信小程式可否勝任？尤其對於題庫規模不小且需要匯入的情況，是否可以支援？
  • 【問題】如果微信小程式無法較為完善的支援上述場景的話，那該如何設計？是否會考慮設計電腦端管理介面？
• A（路線）
  • 【問題】安卓+微信小程式，這個的話專案主要考慮是什麼呢（指的是為什麼要並存）？在工作量上是否過大，不利於掌控？
• B（優勢）
• C（競品）
  • 【問題】部落格中有提到相比小戰考研勝在服務均是免費的
    • 假設之後希望專案盈利，目前有初步的計劃嗎？
    • 【建議】後續對小戰考研等類似產品進行更加深入的調研分析，並相對於當前專案進行一定的對比分析，以便於列出基於推廣與盈利的計劃。
• D（交付）
  • 【問題】微信小程式需要對網站進行備案才能正式釋出，備案流程需要一個月以上，團隊有備案好的網址嗎？
  • 【問題】在定義使用者量時是否是以每日活躍使用者為準，而不是累計使用者量？

4. 知疫：疫情防控視覺化平臺

部落格地址：https://www.cnblogs.com/zjtd/p/14652708.html

視訊地址：https://www.bilibili.com/video/BV1cA411L7mW

摘要：

* 專案簡介：對疫情資料、疫苗接種資料視覺化。（微信小程式和網頁端）
* 創新點：全新的疫苗覆蓋率視覺化展示、智慧生成推薦疫苗接種建議等。
* 專案意義：為疫情防控獻一份力。

問題與建議：

• N（需求）
  • 【問題】具體的目標使用者群體是哪類人呢？從需求上的幾個關鍵字來看包括下述幾類：
    • “對於不關注新聞或檢索能力一般的人群”
    • “存在一定數量的人群對疫苗抱有擔憂”
    • “很多人受制於訊息檢索渠道的限制，對新冠疫苗的瞭解有限，對新冠疫苗有一定顧慮，缺乏全面瞭解一面的渠道”

如上所示的目標使用者群，關心的更多的是疫苗資料的展示，還是疫苗本身的科普資訊？

* 【建議】可以把使用者畫像定義得更清晰。在有更清晰的使用者定位後，可以更有針對性地進行需求設計，明確殺手級功能。

• A（路線）
  • 【建議】在路線部分，觀察到專案要同時做資料展示和資訊查詢的功能，工作量較大，可以仔細衡量不同階段要開發的功能側重點，並做好版本劃分和時間計劃。
  • 【問題】課程組最初提供該選題對資料來源留給團隊自行調研，關於這方面目前有做哪些調研的準備？
  • 【答辯】是否有疫苗接種情況的資料集？
    • 已經找到資料集，全國的接種情況，精確到以省為單位地區，感染率與治癒率
• B（優勢）
  • 【建議】建議強呼叫戶從專案能夠獲得什麼從其他服務裡得不到的好處，以及他們為此付出的代價有多大。
• C（競品）
  • 【建議】建議強調一下專案相比於競爭對手的競爭力是什麼，列出專案最獨特的功能。
  • 【答辯】已有疫情資料視覺化平臺較多，如何保證競爭優勢？
    • 推出展示疫苗接種情況、地區安全等級評價（評價指標暫未確定）這些特色功能
• D（交付）
  • 【問題】針對“3 釋出一週後預期使用者量”，可否進一步細化？是不是指每日活躍使用者？第一個版本什麼時候釋出？釋出後一週、兩週、一月、三月、半年的資料預計如何？除了使用者量，是否可以有使用者留存率、新使用者增長資料的預估？
  • 【建議】專案開發有兩個迭代週期，可補充每個週期預期交付的功能集，並簡單陳述這樣安排功能優先順序的理由。

5. Unity卡牌自走棋：手機遊戲

部落格地址：https://www.cnblogs.com/hairteam/p/14654229.html

視訊地址：https://www.bilibili.com/video/BV1oK411w7nw?zw

摘要：

* 專案簡介：卡牌自走棋手遊。（安卓平臺）
* 創新點：豐富的自由度、遊戲模式及社交、覆盤功能。
* 專案意義：手遊的意義。

問題與建議：

• N（需求）
• A（路線）
  • 【問題】自走棋是一種側重於玩家對戰型別的遊戲嗎？如果是的話，團隊所做的單機版如何保證AI人機的質量？
    • 【建議】如果確實有高質量AI人機的需求，則建議慎重評估一下這個功能的技術門檻與工作量，如果評估後依然存在較大障礙的話，建議慎選此題目。
  • 【問題】遊戲開發工作量很大，你們準備如何在Alpha階段開發出一個MVP軟體？
    • 【建議】明確一下在Alpha階段完成哪些功能，技能體現遊戲的特點，又能確保按時完成
  • 【問題】你們的遊戲機制是什麼樣的，具體是指，這個機制你們是打算自己去設計，還是說基於某種成熟的遊戲機制？
    • 遊戲機制對於遊戲而言是至關重要的。
    • 遊戲策劃是個專業性很強的活，在遊戲大廠中這些都是專人專部門負責的。
    • 【建議】明確下游戲機制上的合理性
      • 如果確實是一個在圈子內比較成熟的遊戲機制，那麼無影響
      • 如果遊戲機制本身存在較大創新，則建議去諮詢相關專業人士，並從他們那裡獲取建議以便儘快解決機制問題，避免後續在遊戲機制上耽誤大量時間影響工作主線
  • 【問題】做3D遊戲的話，你們有負責建模和美工的人員嗎？
  • 【答辯】美工UI設計對遊戲體驗影響較大，在這部分上準備如何解決？花多大精力？
    • 相關美工設計資源可以從Unity開源社群中獲取，較為成熟
  • 【答辯】遊戲內容的設計與定位是什麼？
    • 計劃做輕量級手遊，針對碎片化時間
• B（優勢）
• C（競品）
  • 【問題】目前市面上有其它自走棋類的手機遊戲嗎？
    • 【建議】就競品問題做一些進一步的調研，並進行必要的比對分析
• D（交付）
  • 【問題】在專案的Alpha階段和Beta階段分別預期有多少每日活躍使用者？
    • 【建議】進一步明確此類問題
    • 並且請注意，使用者數指的是活躍使用者數，而非總註冊使用者數

6. 觀隅：資料集管理與視覺化平臺

部落格地址：https://www.cnblogs.com/RiddleMan/p/14654911.html

視訊地址：https://bhpan.buaa.edu.cn/#/link/09297EE2B35E9C79F8F5C7197069DF62

摘要：

* 專案簡介：資料集管理與視覺化平臺（取“觀一隅而知全域性”之意），一款資料集管理與視覺化軟體，可以對常見深度學習資料集進行篩選、視覺化以及結構解析。可以方便深度學習新手快速入門，也可以通過對資料集內容的直觀展示輔助模型的設計與優化。（網頁端）
* 創新點：深度學習資料集視覺化，資料集篩選搜尋。
* 專案意義：為深度學習新手提供更好的學習平臺和環境。

問題與建議：

• N（需求）
• A（路線）
  • 【答辯】團隊成員對深度學習瞭解程度如何？
    • 專案本身與深度學習關係不大
• B（優勢）
• C（競品）
  • 【問題】請詳細談談你們軟體的差異性和對目標使用者的好處。
• D（交付）
  • 【答辯】使用者是否可以上傳資料集？
    • 使用者在本地部署伺服器
      • 【問題】部署在本地的話，是不是需要使用者資料集滿足什麼格式，這部分你們要設計嗎？是否計劃相容現有常見的資料集型別？
      • 【問題】預期以什麼樣的流程進行一鍵式部署呢，類似於tensorboard一樣使用pip安裝嗎？以及團隊成員是否瞭解pypi等相關服務、工具鏈的使用？
  • 【答辯】準備支援幾類資料集，是否可擴充套件？
    • 定義資料集描述格式，可以由使用者進行匯入，配置檔案
    • 【建議】這個軟體應該是面向多種資料的，請從技術和業務流程角度考慮一下如何提升可擴充套件性，使得對於新的資料集也能夠比較容易實現可視
  • 【問題】在專案的Alpha階段和Beta階段分別預期有多少每日活躍使用者？
    • 【建議】進一步明確此類問題
    • 並且請注意，使用者數指的是活躍使用者數，而非總註冊使用者數

7. 考前自救題庫：刷題軟體

部落格地址：https://www.cnblogs.com/sxdjlmy/p/14655134.html

視訊地址：https://www.bilibili.com/video/BV1fX4y1g7pn/

摘要：

* 專案簡介：多功能題庫，包括航概、軍理、資料結構等科目的學習平臺。（微信小程式）
* 創新點：排行榜激勵使用者學習，增加題目標籤，增加你問我答的PK功能。
* 專案意義：為學弟學妹提供更方便的題庫程式。

問題與建議：

• N（需求）
  • 【問題】你問我答PK部分，具體打算如何進行？是基於題庫現有題目還是基於新的自定義題目？
    • 如果是現有題目的話，那麼你問我答中的“你問”，意義何在？
      • 【建議】如果確實是這個意思的話，建議明確出來這樣設計的考慮，以及這樣做可以帶來怎樣的效果，建議基於使用者需求以及典型場景進行“講故事”式的描述。
    • 如果是新題目的話，如何保證題目與題庫主題確實有關？
      • 題目應該與主題多少相關，畢竟最起碼不能在航概題庫裡面刷腦筋急轉彎吧。
      • 以及對於題目，正確性與否如何判斷？這一功能的效用性和質量該如何可持續化維持下去而不是被汙染？或者簡單來說，如果有人提供答案不對的題目，甚至故意製造汙染性題目資料，從系統層面或者業務層面上該如何有效應對？
      • 【建議】如果確實是這個意思的話，建議認真考慮上述問題，評估一下從系統層面或業務層面上解決上述問題的路線，確保有至少一種可行的應對方案。
  • 【答辯】排行榜的“競爭”意義是否必要
    • 暫定依據做題量進行排名，使用者可以自己選擇是否去看
    • 【建議】現在有些類似的資料網站（例如wakatime），使用者可以通過系統設定選擇是否參與榜單排名（實際上一直會參與總排名，只是可以不顯示在英雄榜上），也可以通過系統設定選擇是否檢視排名，在排名這個問題上的設計可以參考一下wakatime。
  • 【答辯】關於使用者題目是否會對官方題目，以及刷題業務本身造成干擾？
    • 可以自行選擇是否檢視使用者題目
  • 【答辯】題目打分與評價是否會影響使用者體驗（在每道題目結束後均需要對題目進行評分）
    • 使用者可以自由選擇是否進行評分，各種選項平鋪列出
• A（路線）
• B（優勢）
• C（競品）
• D（交付）
  • 【問題】微信小程式需要對網站進行備案才能正式釋出，備案流程需要一個月以上，你們有備案好的網址嗎？
    • 【建議】確認一下是否具備完成該技術棧的必要條件
      • 如果確實具備已備案域名，則可以正常進行，不受影響
      • 如果暫不具備已備案域名，則需要評估備案時間與本課程的週期，而且考慮到域名備案流程可能存在的不可控性，以及後續環節有進行產品實際推廣的考核需求，故建議慎重選擇微信小程式，與之類似的替代方案有安卓App等，考慮到學習成本的話比較推薦PhoneGap這類web友好的技術棧。
  • 【問題】對於服務的管理者而言，微信小程式可否勝任管理功能？尤其對於題庫規模不小且需要匯入的情況，是否可以支援？
    • 【建議】進一步明確此問題
      • 如果確實只實現微信小程式，則需要充分定義操作模式，並充分確保易用性（不過感覺對於題庫這樣需要批量匯入功能的應用，微信小程式恐很難勝任）
      • 如果不只實現微信小程式，則需要對其他端的需求以及業務相關進行必要的定義，確保可用性
  • 【問題】請明確一下使用者量是每日活躍使用者數還是累計使用者數？每日活躍使用者更能反映軟體是否能夠吸引到使用者
    • 【建議】進一步明確此類問題，並給出準確指標數字
    • 並且請注意，使用者數指的是活躍使用者數，而非總註冊使用者數

8. AI Bot：問答機器人

部落格地址：https://www.cnblogs.com/DQSJ2021/p/14654671.html

視訊地址：

摘要：

* 專案簡介：打造一個基於大資料的 IT 問答機器人服務，通過運用人工和AI 技術，極大提高問答產品的使用者滿意度。（網頁端）
* 創新點：智慧回答專業問題，高效率、高質量問答平臺。
* 專案意義：能夠讓使用者在提出問題後更及時地被回應，幫助新手在提問題時進一步說明問題，完善問題，提高提問者急需回答的問題的解決效率，幫助提問者找到曾經有人回答過的類似問題。

問題與建議：

• N（需求）
  • 【答辯】是否對問答領域有限制？
    • 計劃領域為多個主流程式語言的相關問題
    • 【建議】定義有限目標，一個範圍，確保工作量可控也確保服務質量可控
  • 【答辯】後期是否考慮接入問答社群？
    • 後臺存在一個問答社群，使用者也可以直接在社群中搜尋
• A（路線）
  • 【問題】目前是否考慮過整體的技術棧？
    • 【建議】如果涉及到模型的話，建議後端採用Python類框架比如Django，或者模型部分單獨封裝並對上層業務系統提供API。
  • 【答辯】基於已有模型和演算法，如何根據使用者的提問找到使用者真正需要的資訊？
    • 前期需要人工介入，將使用者提出的新問題補充入資料集，相當於一個訓練模型的過程
    • 【建議】建議將這件事在技術和業務流程層面上進行確認，確保可行性
• B（優勢）
• C（競品）
  • 【答辯，待回答】基於什麼樣的原理？如何保證效果一定比現有搜尋引擎好？和搜尋引擎有何區別？
• D（交付）
  • 【答辯】如果一個搜尋內容在中文網際網路上不存在該如何應對？
    • 這也就是要處理使用者問了“超出知識範圍的問題”的情況，需要前面所說的，人工介入。
  • 【答辯，待回答】如果產品目標使用者主要是初學者，則需要考慮給出一個簡明的答案，是否會針對這種情況進行優化？