第四次小組報告

盧曉東：在寫軟件設計模式大做業時纔會感受到書上講的東西的含義，沒有好的計劃讓個人進度一度被擱淺，想說作一個小書店的程序，而後想着要用到數據庫存儲數據，而後就上網找怎麼鏈接我在學的SQL Server2012，接着就是配置個人數據庫的TCP/IP協議啦，而後當天晚上電腦運行速度直線降低QAQ個人心在滴血的TAT，配置好了之後又遇到了一個問題，就是我先作程序界面呢仍是先作數據庫的讀取呢？思索了好久仍是決定從讀取數據庫數據開始吧，這樣作界面的時候纔會有數據支持。整個過程我都是一邊作一邊想，沒有制定具體的計劃，也沒怎麼注意細節這些，發現想作好一個程序有時真的特別凌亂，不知道從哪下手，當本身覺得有思路就能夠了的時候，發現不知道從哪裏下手-_-嗯，不說了，還得去繼續思考細節問題

王彥凱：

軟件需求

一、獲取和引導需求

二、分析和定義需求

三、驗證需求

四、在軟件產品的生命週期中管理需求

　　對軟件的需求，也能夠從不一樣角度作下面的劃分：

　　　　一、對產品功能性的需求

　　　　二、對產品開發過程的需求

　　　　三、非功能性需求

　　　　四、綜合需求

用戶調研方法：

一、焦點小組

二、深刻面談

三、卡片分類

四、用戶調查問卷

五、用戶日誌研究

六、人類學調查

七、眼動跟蹤研究

八、快速原型調研

九、A/B測試

 

競爭性需求分析的框架

　　NABCD模型

　　　　N（need，需求）

　　　　A（approach，作法）

　　　　B（benefit，好處）

　　　　C（competitors，競爭）

　　　　D（delivery，推廣）

 

功能的定位和優先級

　　兩種不一樣類型的功能

　　　　殺手功能/外圍功能

　　　　必要需求/輔助需求

　　　　殺手功能：OCR文字識別技術，能夠在屏幕上取詞解釋，擁有獨家權威辭典、等等

　　　　外圍功能：良好的界面設計，在各個平臺上都能運行

　　　　必要需求：單詞短語釋義的準確性（若是達不到這一點，用戶就不會來使用）

　　　　輔助需求：能夠作各類皮膚（這也許能讓一些用戶更喜歡這個軟件，但不是決定因素）

李凱城：

Agile——敏捷開發，做爲CMM神話崩潰後被引入的一套新的軟件開發模式，這幾年來被普遍引發關注，並被寄予厚望。

敏捷流程及其原則告訴咱們個體和交互賽過過程和工具，儘早爲客戶需求作準備和交付有價值的軟件，時時總結如何提升團隊效率才能得到更大的進步。

敏捷流程重視團隊，重視需求，重視效率。

若是說Agile只是比較側重於效率的話，那MSF是在這基礎上更加註重學習跟規劃。

首先，MSF提倡信息共享和溝通，開展項目的時候對項目的信息都要公開，讓你們能瞭解這個項目。

若是信息不能共享，更加達不到分派任務，各司其職。

學習全部的經驗。

這一原則告訴咱們不只要多總結經驗，結合以前的信息共享，經驗一樣也要共享，共同進步。

保持敏捷，效率確定是不可或缺的，同時作好預期規劃，客戶的需求會致使項目的變化，項目的變化要提早作好規劃，不要到頭來白忙一場。

重視團隊合做。

固然，這個在信息共享的時候就開始體現了，團隊的合做，各司其職，才能作到更加敏捷。

奚佳峯：

需求分析方法：

1.獲取和引導需求

軟件團隊須要找到 軟件的利益相關者，瞭解和挖掘他們對軟件的需求，引導他們表達出對軟件的需求。

 不一樣的項目須要不一樣的手段，這一步驟也被叫作「需求捕捉」，形容真正的需求稍縱即逝，須要靠火眼金睛和敏捷的身手來發現並抓住它們。另外，不少時候用戶並不知道本身確切的需求，或者不肯意表達完整的需求，軟件團隊須要設身處地，替用戶着想，引導出需求。有些需求在實現以前，並無用戶明確表達具體的需求（例如：沒有用戶說「我但願有一個偷菜的軟件，我能夠偷別人家的菜」），可是，成功的團隊仍是能夠從「用戶須要和朋友之間玩遊戲，用戶有證實本身能力的需求」這些角度出發，挖掘出需求。另外，軟件團隊能夠分析技術的發展趨勢以及產業的變化、社會發展的大趨勢，推測用戶會產生哪些新的需求。例如，看到全球定位系統（GPS）技術的成熟、地理信息系統的發展、私家車的普及和智能手機性能的不斷提升，咱們能夠推測出利用手機給汽車導航將是一個廣泛的需求

需求還能夠來自各類 管理機構 

例如一些互聯網服務對不一樣年齡用戶的內容管理\「敏感詞屏蔽」、快速刪除網上內容，等等

需求不只來自外界，還能夠來自 軟件企業自己 

軟件企業＝軟件+商業模式。企業所採用的商業模式會對軟件提出需求。一個免費的互聯網服務到達必定規模後，企業就會考慮如何讓這個服務帶來收入，例如一個免費的互聯網電子郵件服務會考慮對用戶收費，支持幾種不一樣等級的用戶，在郵件中附帶廣告，或者在頁面顯示廣告，等等。這些「需求」並非來自用戶，事實上絕大部分用戶都反感這樣的「需求」，可是企業須要一個能維持它生存和發展的商業模式，儘管這個模式的種種需求未必都是對用戶有利的

需求還能夠來自技術團隊自己 

團隊在考慮軟件的代碼、架構、所依賴平臺的長期演化的時候，會提出技術性的需求，包括代碼的遷移、架構的演化、平臺的變化，或者引入新的技術。例如，爲了提升未來的開發效率，一個手機軟件的開發者決定逐步引入跨平臺的語言和框架；一個依賴客戶端/服務器（Client/Server）架構的軟件須要支持新的HTTPS協議；原來後臺的數據服務使用了專用的數據庫和專門的小型機，如今改成基於開源技術的軟件和硬件；軟件前端代碼須要支持某種自動測試工具，以便更有效地進行自動測試，等等

有些需求的目的是要 更好地瞭解用戶的行爲和需求

例如，咱們要在軟件的各個功能點加上收集信息的代碼，並在後臺實現數據收集、整理、報告和數據挖掘（Data Mining）工做。此類技術在一些公司叫Telemetry—遙測技術

2. 分析和定義需求（Analysis & Specification）

這是指對從各個方面獲取的需求進行規整，定義需求的內涵，從各個角度將需求量化（需求實現的最後期限，實現需求大體所需的時間和資源成本，各個不一樣需求的優先級，需求帶來的收益，等等）

3. 驗證需求（Validation）

軟件團隊要跟利益相關者溝通，經過分析報告、技術原型、用戶調查或演示等形式向他們驗證軟件團隊對於這些需求的認知

4. 在軟件產品的生命週期中管理需求（Management）

在軟件的生命週期中，需求在發生變化，技術在發展，團隊成員的能力也在提升。原來認爲重要的事情可能再也不重要，有些功能原來技術上很難實現，如今出現了捷徑，一些相關的法規會發生變化，外部的合做夥伴忽然發生變化，這些都要求咱們不斷對需求進行從新審覈並作出相應的調整

 

 

獲取用戶需求：

用戶最須要的> 
　　用戶表達出來的> 
　　　　軟件團隊能理解的 + 團隊的商業目標> 
　　　　　　　軟件團隊成員具體表達出來的（PM寫Spec）> 
　　　　　　　　　在各類約束條件下，具體執行表達出來的（Dev寫代碼）> 
　　　　　　　　　　　驗證經過的（Test）> 
　　　　　　　　　　　　　經過各類渠道告訴目標用戶（發佈/推廣）> 
　　　　　　　　　　　　　　　用戶終於能用上了，可是他們不滿意

 

競爭性需求分析的框架 —— NABCD模型：

1. N（需求） 
你的創意解決了用戶的什麼需求？這個需求能夠是明確的、公開的（例如：但願能上網玩三國殺）也多是說不清道不明的，例如——之前沒人說：嗯，若是我能找到這樣一個網站，我能夠去偷菜，就行了……咱們要充分了解用戶的痛苦，他們對已有軟件、服務不滿意的地方。可是用戶每每也不瞭解顛覆型的創新。例如，亨利·福特是汽車行業的先驅，若是他深刻用戶（馬車伕），徵詢他們的需求，馬車伕會告訴他：我但願個人馬跑得更快一些

2. A（作法） 
好，你找到了需求，下一步怎麼辦，得看看你有什麼招數，特別是獨特的招數，來解決用戶的痛苦。你不能說我會C++，因此我必定能夠寫好這個軟件。你得有獨特的辦法，例如，有人臉識別技術，會作超大規模的數據處理。那你（你的團隊）會什麼呢？只會冒泡排序？這些招數不光是技術上的，也能夠是商業模式上的（例如，咱們第一個作衆包的服務）、地域的（例如，咱們對本市的公交線路很熟）、人脈的（例如，咱們認識不少大學生）、行業的（例如，咱們有地圖測繪行業的資質），或者是成本上的（例如，咱們能找到更便宜的資源來維護網站）。

3. B（好處） 
這時候你已經有了獨特的作法，那你這個產品/服務會給客戶/用戶帶來什麼好處呢？若是用戶已經有一個解決方案（例如用戶已經在用QQ聊天），那你的新的聊天軟件具體有哪些好處，能讓用戶離開現有產品，使用你的產品呢？這還有一個用戶遷移成本的問題——用戶要花費多少精力、時間、金錢才能獲得你的產品的好處？若是你要求用戶必須有8GB內存、最好的顯卡、10Mbps以上的寬帶鏈接，才能使用你的「更好的」視頻聊天工具，那麼會有多少用戶願意支付這個成本呢？

4. C（競爭） 
競爭對手也沒有閒着，這個市場有多大，目前有多少競爭者在瓜分，你瞭解麼？你的產品若是不是最早進入某個市場的，你還能贏麼？先進入市場的產品，有所謂的先發優點，固然也有劣勢。後面進入市場的產品，有種種不利的因素，可是也有後發優點。

 5. D（推廣） 

在實際項目中經歷屢次的NABC以後，許多人意識到這個框架還應該加一個元素D：Delivery。怎樣把你的創新產品交到用戶的手中？例一，你想到了一個好主意，建一個比hao123更好的導航頁面！咱們姑且認爲NABC都沒問題，那如何把這麼好、這麼簡單的產品交到（Deliver）用戶手中呢？例二，你想到了一個手機的應用，NABC都不錯，那如何把產品交到千萬個用戶手中呢？不少同窗會說，把它提交到應用商店去啊！可是在中國大陸有多少個手機應用商店？你的應用提交上去以後，會在相應的產品類別中名列第幾？有多少人會看到？

楊嘉豪：

第十一章的內容是軟件設計與實現。

在第一節中，講的是關於分析和設計方法，向咱們介紹在「需求分析」、「設計與實現」階段、「測試」「發佈」階段該搞清楚的問題。

在第二節中，講的是關於圖形建模和分析方法。在表達實體和實體之間的關係時，能夠用到思惟導圖（Mind Map）、實體關係圖（ERD）、UCD ;在表達數據的流動時，能夠用到DFD工具；在表達控制流的時候能夠用到FSM工具；前面提到的這些圖形建模方法各有特色，UML卻能夠有一個統一的表達方式，但人們對UML倒是褒貶不一。

在第三節中，爲咱們介紹了在軟件發展過程當中科學家和工程師嘗試過的其餘設計方法，包括形式化的方法、文學化編程等等。

在第四節中，介紹了從Spec到實現的具體過程、把修改集集成到代碼庫中的具體步驟還有開發人員的標準工做流程。

第五節介紹的是開發階段的平常管理。

第六節則說明了代碼完成後還須要注意的問題。

第十二章的內容是用戶體驗。

在第一節中，講的是用戶體驗的要素。在給用戶一個好的第一印象時，咱們能夠用5W1H（who、when、where、what、why、how）來判斷好壞；從用戶的角度考慮問題須要咱們有「同理心」 ； 軟件服務過程當中始終都應該要記住用戶的選擇，作到「軟件用得越多，愈來愈好用」；在用戶體驗這個問題上，還要特別考慮到短時間刺激和長期影響；在設計軟件時要考慮到用戶在使用時不會犯簡單的錯誤；在必要的時候，能夠犧牲軟件質量去追求用戶體驗；諾爾曼闡明瞭設計的三個層次——本能層次、行爲層次、反思層次。

在第二節中，介紹了用戶體驗設計的步驟和目標。用戶體驗設計的一個重要目標就是下降用戶的認知阻力，即用戶對於軟件界面的認知和實際結果的差別；用戶體驗設計的步驟——概要設計、行爲交互設計、界面設計。

在第三節中，介紹了一個好的軟件用戶界面的評價標準。這些標準原則包括儘快提供可感觸的反饋、系統界面符合用戶的現實慣例、用戶有控制權、一致性和標準化、適合各類類型的用戶、幫助用戶識別診斷修復錯誤、有必要的提示和幫助文檔。