本文主要談談對軟體需求分析和創新專案提出意見或建議。
但又一想，在團隊裡面，不是自己乙個人，每個成員的想法都不同，先要各抒己見，再找每個人意見的相同點成為大家的共同目標，這樣會不會好一
些。就想我們想要了解使用者的需求，
他們的語言表述方式各不相同，難就難在我們對使用者需求的抽象。軟體產品的利益相關者不止使用者，還有顧客、市場分析人員、監管機構、軟體團隊、系統/應用整合商、軟體團隊以及軟體工程師。軟體開發不可能滿足以上所有人的要求，但所有人的需求和意見都需要了解，才能開發出乙個有市場的軟體。
獲取使用者需求可採用多種使用者調研方式，這些方式都包括「引導、捕捉、分析」需求。每種方式都有
自己的優缺點，我認為快速原型模式能較快的獲得使用者的反饋，以便於獲得使用者精確地需求，但也有問題，如果是因為軟體設計人員自己加入了自己的需求，則會使得使用者的需要受到影響，從而不斷地使得使用者需求改變。競爭性需求分析中nabcd模型，較好的反映了現在軟體開發需求分析所需要注意的環節。
創新有改良型和顛覆型，對於我們剛開始做專案來說，改良型相對容易，借前車之鑑，實現功能的增加和程式提速、程式移植新平台。其實有好的創意實現顛覆型的創業也不是沒有可能。比如阿里巴巴顛覆了人們的購物方式，推動電子商務市場。這其實是殺手功能的強大作用。但依照現在的**來看，外圍功能也不能太弱。友好的互動介面可以增進顧客對軟體的喜歡。人們剛開始使用乙個軟體時或多或少會覺得軟體有不好用的地方，大多是不容易找到自己想要找的東西，或許是某種功能，或許是介面跳轉等待時間過長。
其實我們學習計算機剛開始對it行業的創新會有很多誤解。在本書第16章裡提到的幾個迷思，在我剛開始學習計算機時認為都是正確的，不就是這樣嗎？但後來接觸的多了，是真的發現創新專案最好是使用的。因為實用，才能吸引人使用。影響產品的競爭因素中，產品行業比較關鍵。就想我之前說的做ui設計的同學，他剛開始並不想做這方面的，後來迫不得已進入這行，結果前景開始有好的轉變。還有像我們玩的遊戲，也是一段時間內某種遊戲比較火熱。
我們現在設計的軟體要與商業模式更好的結合。這樣才能擺脫「作坊」，進一步提公升軟體的使用率，做出真正稱得上世界各國都有使用的軟體！
構建之法2
團結就是力量 善於運用團隊，發現無限潛能。前幾周老師提出結對作業的時候，我覺得只是這麼乙個小小的程式，沒有結對的必要性吧。可越到後來越發現結對的好處，隊友可以找到網盤想不到的問題。尤其是看完書後覺得，結對不是單純的從乙個人變成2個人寫。而是從乙個角色變成另外乙個角色，就像是領航員與駕駛員，在不同的位...
構建之法1 2 16章閱讀感想
這本書可以說是我進入大學以來讀過的最容易理解的一本有關於軟體工程的書，語言平易近人容易理解，讓我對軟體工程在原有基礎上有了翻新的認識，讓我重識認識了軟體工程 知行合一 的思想，加深了我對軟體工程行業整體的理解。閱讀的同時，我也產生了一些疑惑，以下是我在學習過第 一 二 十六章後提出的一些問題和我的思...
讀書筆記 構建之法（CH1 CH3）
人類文明的發展離不開哲學家的思考 科學家的發現和工程師的構建。三個簡單的方程式解釋了什麼是現代軟體工程 1.程式 演算法 資料結構 2.軟體 程式 軟體工程 3.軟體企業 軟體 商業模式 軟體開發的不同階段可以模擬為航空產業 從玩具階段的紙飛機，到業餘愛好的飛屋，再到探索階段的 萊特兄弟的飛機，最後...