1. 程式人生 > >軟件工程網絡15團隊作業3——需求分析設計

軟件工程網絡15團隊作業3——需求分析設計

數據庫 ref 邏輯圖 github上 bre 意見 ket blog task

需求分析

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

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章:功能分析的四個象限
  • 把這些要點都組合成為一段話 -- 當你要向別人兜售你的項目的時候, 你通常只有很短的時間 (電梯演說),能否自然而有條理地把項目說清楚? 請用你產品中實際的元素代替 <> 中的抽象概念。
    各位領導/投資人/用戶/合作夥伴:我們的產品

    參考

    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;

技術分享圖片

詳情參考:https://suibiancha.coding.net/p/Suibiancha/tasks/board

2、團隊成員估計各自任務所需時間

功能 所需時間 負責人
界面設計 4天 黃紹樺、張文博
“查詢”鍵代碼編寫 6天 戴建釗、林健
“歷史記錄”鍵代碼編寫 6天 曾飛遠
代碼測試 3天 周穎強

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

  • 我們將參考華為公司的代碼規範進行編碼。詳情參考如下鏈接:http://www.open-open.com/doc/view/9d112ce0c4ba4af9be72dc84d0fbeba4

    系統設計

    在設計階段,我們要清楚:軟件是怎麽解決這些需求的?
    一個好的分層式結構,可以使得開發人員的分工更加明確。一旦定義好各層次之間的接口,負責不同邏輯設計的開發人員就可以分散關註,齊頭並進。

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

軟件工程網絡15團隊作業3——需求分析設計