軟工網絡15團隊做業3——需求分析與設計

Deadline：

2018-4-15 10:00PM，以提交至班級博客時間爲準。
根據如下要求，寫一篇隨筆，並完成《需求規格說明書》

---

需求分析

軟件的最終目的是用來解決用戶的某些問題，需求分析就是要理解要解決的問題，真正明確用戶需求。

1. 訪問軟件項目的真實用戶（至少10個），確保軟件真正體現用戶的需求，爲軟件最終可用奠基基礎。
   • 若是是原有項目，須要對舊項目的全部信息作一個調研，經過採訪之前的開發者，造成採訪文檔，請參考《構建之法》的大馬哈魚巡迴遊的過程性介紹。
   • 用戶調研方法參考《構建之法》第8章獲取用戶需求——用戶調研
     • http://www.cnblogs.com/xinz/archive/2013/02/03/2890786.html
     • http://www.cnblogs.com/xinz/p/3308608.html
2. 參考《軟件需求規格說明書》國標規範文本，撰寫對應項目的軟件需求規格說明書。提供《需求規格說明書》的Git連接。
   • 除形式上知足規範文本要求外，總體內容必須圍繞項目實質展開，對所要開發的項目確保盡力作到清晰完整準確。
   • 使用一致的圖形符號和文字描述內容。
     • 分析和設計方法：http://www.cnblogs.com/xinz/p/4525232.html
     • 在線做圖工具ProcessOn：https://www.processon.com/
   • 全部的縮寫須事先定義。
   • 須要有一個目錄，word排版樣式規範美觀，圖文並茂，通篇文檔有一個統一的樣式風格。
   • 將本身置於讀者的立場——若是對軟件項目不熟悉的人員，經過閱讀這份文檔，可否徹底讀懂軟件要作什麼。
3. NABCD 寫做，視頻
   • 請同窗們把本身項目的NABCD 都寫出來。
   • 列成詳細的條目，用具體的事實和分析說明。
   • 請分析本身項目的殺手功能是什麼？參考教材的第8章：功能分析的四個象限
   • 把這些要點都組合成爲一段話 -- 當你要向別人兜售你的項目的時候， 你一般只有很短的時間 （電梯演說），可否天然而有條理地把項目說清楚？ 請用你產品中實際的元素代替 <> 中的抽象概念。
        各位領導/投資人/用戶/合做夥伴：咱們的產品 <foo> 是爲了解決 <目標用戶> 的痛苦, 他們須要 <Need>，可是現有的方案並無很好地解決這些需求，咱們有獨特的辦法 <Approach>，它能給用戶帶來好處 <Benefit>，遠遠超過目前市場上的競爭對手 <Competitor>。 同時，咱們有高效率的 <Delivery> 方法，能很快地讓大部分用戶知道咱們的產品，並進一步傳播。
     [ 附加題]把上面的這段話錄製爲視頻，上傳到視頻網站，並把連接發到團隊博客上。
4. 團隊協做，增強分工，須要描述每一個成員的具體分工及佔整個文檔任務的工做量比例。

參考

• NABCD參考 （參見 http://www.cnblogs.com/xinz/archive/2010/12/01/1893323.html）
• 同窗們的實際做業例子：
  • http://www.cnblogs.com/dasusu/p/4830168.html
  • http://www.cnblogs.com/MR-ZH/p/5879464.html
  • http://www.cnblogs.com/linexu/p/5880155.html
  • http://www.cnblogs.com/liangzhilin/p/5462486.html
  • http://www.cnblogs.com/jjy520/p/5463552.html
  • http://www.cnblogs.com/hgf520/p/5457322.html

原型設計

原型設計可以在表現層將設計合成一個邏輯總體，用戶能和你一塊兒看到將來交互的軟件藍圖、功能和效果，得到較真實的感覺，在不斷討論的基礎上完善將來的設計思想。所以，原型設計能起到有效溝通的做用，漂亮，直觀的原型圖更是讓人賞心悅目。

1. 不要等到全部代碼寫好以後再去驗證需求，請用設計工具描述用戶界面和需求。
2. 原型設計不只要考慮主要功能的頁面排布，同時也要考慮用戶實際操做中的問題，提早爲用戶考慮得當並徵求用戶意見
3. 系統是必須可運行的，可實際使用的——請抱着這樣的同理心去考慮系統。
4. 給目標用戶展示原型，與目標用戶進一步溝通理解需求。

• 思考：他們的痛是什麼？場景是什麼？（用產品以前/以後，有照片或視頻顯示用戶調查的過程，使用了各類調查手段的，加分）
• 參考：
  • 《構建之法》第10章典型用戶和場景
  • http://www.cnblogs.com/xinz/archive/2011/10/30/2229236.html
  • 阿里巴巴衛哲：http://iamsujie.com/8000/8018/ 

原型工具參考

若是是設計原型，採用專門的原型設計工具，可以事半功倍，工具參考：

• 移動應用原型與線框工具-墨刀
• 原型設計界的PS -Axure RP，Axure
• 網頁和移動端的設計sketch
• 一款簡潔高效的原型圖設計工具mockplus
• 致力於高保真原型製做工具Justinmind
• 一款免費的帶有手繪塗鴉風格的原型設計軟件balsamiq mockups
• 更多選擇，請參考：https://www.zhihu.com/question/19592829

做業參考

原型設計界面簡潔，用戶體驗極佳。分工比例部分的泳道圖十分清楚地展現了各個同窗的工做任務，Github上數十次Commit也展現了他們和諧的團隊協做。

• http://www.cnblogs.com/thousfeet/p/7702651.html

任務分解WBS

一個團隊項目要在一段時間內完成諸多任務，知足用戶需求，實現團隊目標，從哪裏入手？
WBS（Work Breakdown Structure）即工做分解結構，是根據項目目標把工做分解成許多井井有條的、可交付成果的工做任務，而後用邏輯圖形或樹形結構表示出來。

1. 請給出團隊項目的WBS；
2. 團隊成員估計各自任務所需時間
3. 參考：http://www.cnblogs.com/zhengrui0452/p/6653964.html

編碼規範

根據結對編程的經驗，你們已經意識到編碼規範的重要性。
討論制定團隊的編碼規範，知足代碼風格規範和代碼設計規範（參考書第4章4.1-4.3內容）http://www.cnblogs.com/xinz/archive/2011/11/20/2255971.html

系統設計

在設計階段，咱們要清楚：軟件是怎麼解決這些需求的？
一個好的分層式結構，可使得開發人員的分工更加明確。一旦定義好各層次之間的接口，負責不一樣邏輯設計的開發人員就能夠分散關注，齊頭並進。

1. 如何才能最大限度地實現這些需求，這就是架構設計要解決的問題。請給出系統的架構設計
2. 完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖（若是必要）

參考

• 分析設計方法：http://www.cnblogs.com/xinz/p/4525232.html 
• http://www.cnblogs.com/bugphobia/p/4946840.html
• http://www.cnblogs.com/bugphobia/p/4946844.html
• http://www.cnblogs.com/bugphobia/p/4946849.html

---

評分基準

• 按時交 - 有分（詳細評分細則見下表）
• 晚交 - 0分
• 遲交兩週以上 - 倒扣本次做業分數
• 抄襲 - 倒扣本次做業分數
• 如對分數有意見，只給一次向助教申訴的機會

評份內容	評分項	分值	備註
需求分析	訪問用戶	5 + 5	（i）若是是原有項目須要在博客中展現採訪文檔，須要有每位用戶的採訪反饋，很多於10人（ii）若是是新項目須要給出用戶調研的證據，如調查問卷須要給出問卷連接和統計結果，很多於10人，基礎分5分，有照片或視頻顯示了用戶調研過程的能夠再加5分！
	給出需求規格說明書的git連接	10	a-e每項2分
	給出項目的NABCD	10	要有具體的事實和分析，每條2分
	給出項目的殺手功能	2
	將NABCD要點組織成一段話	5
附加題	把上面的這段話錄製爲視頻，上傳到視頻網站，並把連接發到團隊博客上	5
原型設計	請用設計工具描述用戶界面和需求	10	在博客上給出原型設計的結果和原型設計用到的工具，須要圖文並茂
任務分解WBS	給出團隊項目的WBS	5
	團隊成員估計各自任務所需時間	3
編碼規範	制定團隊的編碼規範，給出Git連接	5	知足代碼風格規範和代碼設計規範
系統設計	給出系統的架構設計	5
	完成團隊項目的數據庫設計，並在隨筆中提供相應ER圖	5	若是所選項目不須要涉及數據庫那麼不須要作這一項，可是要給出不須要數據庫的支持理由
其餘	排版	3
	評論區回覆	[-5, 5]
	團隊的分工	5
	成員的完成狀況	2
	我的的感覺	10