app需求分析怎麼寫

隨著移動網際網路的發展，以及智慧手機的普及，APP應用市場發展火爆。目前，國內智慧手機使用者已經超過了6億。APP開發將是未來資訊科技的主流。要想在眾多的APP應用脫穎而出並獲得成功，首先就要做好APP開發需求分析，那麼我們應該怎麼做呢？

一、專案定位

在做APP開發之前，首先要明確你的APP是做什麼用的，要實現什麼目的，這一點對於APP開發尤為重要。你的APP開發能解決什麼問題，是工具型還是娛樂型APP應用軟體。

二、目標受眾分析

目標受眾分析就是指你所開發的APP是為誰服務的。根據年齡、收入、學歷、地區等多維度進行目標使用者群體定位，並分析使用者在不同消費場景下的需求，進而滿足使用者需求。

三、APP競品分析

競品分析做得好不好，也直接影響這個產品之後的發展。確定哪些產品是你的競爭對手，通過不同的渠道獲得競爭對手資訊，可以用SWOT分析法對產品的優勢、劣勢、機會和風險等四個方面與競爭對手進行全方位的比較，知道自己有哪些優勢和劣勢。

四、產品功能設計

APP的設計和開發都離不開對APP功能的分析，特別是的APP軟體的方案中要多APP功能進行詳細的說明。根據APP應用的使用場景和操作流程，提煉軟體的功能需求，以及軟體執行的硬體環境。

五、使用者介面設計

APP的視覺設計是APP開發完成以後給APP使用者的外在形象，即APP使用者在使用你的APP是看到的字型的顏色、字型的型別、APP的標識logo等。儘量提供使用者特點鮮明的功能和介面，達到使用者體驗的最佳化，給予使用者良好的視覺體驗。

資源簡介教會你如何寫需求分析報告~~·需求分析說明書 1 、系統功能結構圖（ HIPO 圖） （在該功能結構圖中選一個子系統進行逐層分解） 2 、系統功能說明 （對以上選中的子系統進行功能描述） 3 、現有系統的業務流程圖及說明 （對以上選中的子系統繪製手工系統或舊的計算機系統的業務流程圖並進行簡單的功能說明） 4 、新系統的業務流程圖及說明 （對以上選中的子系統繪製計算機系統下的業務流程圖（重組後的）並進行簡單的功能說明） 採購管理系統分析 採購是企業 物資供應部門 按已確定的物資供應計劃，通過市場採購、加工訂製等各種渠道，取得企業 生產經營活動所需要的各種物資的經濟活動，採購業務的狀況會影響到企業的整體運營狀況。

通常情況，企業的採購業務通常由 採購部 來執行—— 製造部 根據銷售定單制定生產計劃，企業生產 製造系統根據 生產技術部 提供的有關材料定額資料以及 製造部 提供的生產計劃，考慮現有庫存情況， 生成採購計劃。 採購部 根據採購計劃分別進行國內採購和國外採購。

採購管理系統 主要進行 採購訂單 、採購入庫單 和 採購的管理 。採購業務發生後， 採購部 將 採購錄入 採購管理系統 ，採購物料入庫時， 採購部 儲運科根據驗收單在 庫存管理系統 中錄入入 庫單； 財務部 根據採購和物料驗收單據進行採購結算，系統自動生成相關憑證，登記相關庫存帳。

課程設計應該遞交哪些文件？ 課程設計應提交一份課程設計報告，課程設計報告包括以下幾個方面的內容：①封面、②目錄、③ 系統可行性分析報告、④系統分析報告、⑤課程設計小組成員清單。 如何撰寫課程設計報告？ 課程設計報告包括兩個方面的內容，一個是系統可行性分析報告，一個是系統分析報告。

可行性分 析報告簡單的來講我們要求大家寫兩個方面的內容，首先是對企業目前的狀況進行描述，指出企業需要用 計算機來進行管理（即需要資訊系統），然後從經濟上、技術上、管理上闡述企業是否具備了相應的條件 ，最後得出系統是否可行的結論。我們的課程設計是基於系統可行來進行的。

用文字把以上內容描述清楚 就是我們的可行性分析報告。最快執行緒間資料交換演算法有效避免鎖競爭 下載通過IBM儲存解決方案應對資訊爆炸問題HTML5 Audio API開發遊戲音樂您的IT安全來自System X伺服器下載《從有限資源到無限發展潛力》Windows應用商店全新的商機。

這個事情一般是產品總監帶頭，下面人員建議的形式去做；或者獨立產品的負責人去做，去規劃未來一年60%左右的時間需要做的重大事情；其他事情可能是臨時處理問題、應對營銷部門的各種小需求、行業變化帶來的戰略臨時調整、各種對內對外培訓工作；

BOSS對於規劃只是方向上的把握，更多可能是投入產出比，是否能帶來盈利。例如你說要搞購物商城，他有權否定！他要搞金融，那你也得跟他充分溝通想法和難點。 對於騰訊這樣，財大氣粗有成本試錯的公司除外。

一般規劃會存在導向側重點，有的公司就是內部領導說了算，有的需要以市場為導向，有的是顧客就是上帝使用者說了算，下面就個人理解說下做好規劃的幾點建議：

一、前期調研

1、內省；總結歸納今年出現的所有問題和需求，找出待優化部分；（這裡往往存在疑難雜症）

2、競品；做下競品分析，看下別人有哪些牛逼做法（母嬰這類產品太多，應該很好提煉）；或者觀察別人的產品版本的演進過程（升級公告）；

3、公司戰略層面；與高層領導做深層次的溝通，看董事會對明年如何定義，是一個什麼年，有什麼重大戰略；當然你也可以根據競品分析得出的結果去跟他們聊，如果他們沒有計劃的話（例如，明年要做購物推薦、育兒寶典、益智玩具、國外育兒參考、常用物品如奶粉品牌的優缺點對比；）

4、確定產品生命週期的階段計劃，規劃的目的不要僅僅只侷限在明年，在未來的戰略方向，明年處於一個什麼位置，需要達成什麼樣的產出，才可以實現未來的發展。

二、產出規劃

1、給規劃取名，提出口號，定義需要達到目的，，提煉出一個最重要的規劃（例如，明年是商城年，達到使用者可在母嬰社群APP購物的目的，這個目標確認後，相關的採購計劃、選品計劃、經營模式是B2C還是C2C，其他部門也應該隨之跟上；例如明年是使用者體驗年，達到口碑傳播的目的； ）；

2、形成PPT宣講評審，整理出核心的十個模組或功能點； 業務來源是什麼，價值在哪，解決方案是什麼； （讓公司戰略層、研發部門、驗收、運營、瞭解規劃和需配合的事情，是否有難度或疑問，隨時調整）

3、時間進度表，將通過的大的模組有效的分佈在明年的時間軸上；例如每個季度，每月，或者某個時間範圍，所需要達到的里程碑是什麼；

4、給出具體某個模組的，大致概要需求清單或者叫任務清單（例如：母嬰社群要做商城，商城中各模組的上線，需要做哪些事情）

5、指定責任人，將規劃清單產出物指定相關責任人，也給他們做年度規劃時有一個參考；由具體責任人，將任務細節拆分到自己的季度和月度計劃中。（通常季度計劃，月度計劃 會在之前詳細做一次，也就是在年度規劃上進行細化，細化後作為月度的考核指標）

6、風險評估，給出規劃可能出現的風險點，要求企業給到哪些組織支撐，以保障規劃的正常執行。

三、落地執行

1、有了規劃必須每月執行，每月對當月計劃進行核對和變更（便於及時處理因需求變更，人員變動等情況，導致的規劃無法落地）；

2、如果是專案性質的需求，產品經理必須對上線功能點進行跟進和驗收，依據規劃時間點，專案團隊人員必須大部分時間參與，否則就會延期（有單獨專案管理團隊可製作功能點驗收，時間點跟進交給他們就行了）；

3、通過任務拆分的形式，提高執行效率；很多公司都是一個需求做得很大很全，往往會存在延期，如果技術經理能喝產品充分溝通，對需求進行小功能點的拆解，然後逐個完成，這樣效率會大大提升；

4、研發方法，最近很流行敏捷開發，可以參考，但是還是得根據公司的具體情況進行選擇，不要盲目跟風；

四、考核激勵

1、定義規劃的考核指標：確立規劃是否有效的判斷標準！是否存在財務指標，即產品的功能是否影響公司盈利；是否需要在PV、UV或者註冊使用者數上有質的提上；

2、對於重點專案有突出貢獻的人或者團隊，需要有獎勵機制，這樣可以確保規劃路線的穩定；

好了，就說這些，主要還是愉快的讓公司團隊和諧友好的讓美好的事情發生。

開發一個完整app需要掌握哪些知識

1、前期需求規劃與資訊——你需要制定出一個完整的需求文件，功能文件，流程圖，時序圖。

2、互動設計、UI設計——設計出基本且完善的原型圖和app基礎的互動設計效果，之後再根據這些設計出完整的UI介面並學會切圖，一些需要做自適應的素材圖片需要做點9patch。這裡還需要你懂得px,pt和dp之間的換算，螢幕密度的換算和相互之間的係數，以便你的app能完美適應不同解析度裝置。其中互動設計需要你懂得很多人機操作的技巧經驗，掌握Axure等互動工具的使用，UI設計需要你掌握Photoshop和Illustrator等操作。

3、使用ADT之類的開發環境進行app軟體開發，你最基本的也得掌握java語言，熟悉android環境和機制。

4、如果不是單機版的app，需要用到伺服器，那你還得掌握WebService相關知識和開發語言，常用的有ASP.Net,PHP,JSP等。

5、熟悉並能開發資料庫。

6、某些功能需要做演算法，這還需要一定得專業知識，尤其是數學基礎。

7、熟悉API介面開發，這裡包括你自行開發API的能力以及呼叫第三方API的經驗。

8、熟悉TCP/IP,socket等網路協議和相關知識。

9、熟練掌握App釋出的流程，真機除錯技巧，證書，打包，上架。 App開發其實不一定適合一個人搞，太費勁，除非是一個單機版的小應用，或者利用現成的app開發簡單的第三方應用，否則還是讓一個團隊來完成各自擅長的領域。

該文件一般可以包括以下內容： 該產品的遠景目標（vision） 目標市場和客戶（target market and customers）的描述 競爭對手分析（competitive summary） 對產品主要feature的比較詳細的描述 這些feature的優先順序 初步擬定的實現進度安排。

用例（use cases），這可以是較粗略的大致描述，（通俗的說就是使用產品的一個例子）。 產品的軟硬體需求 產品的效能要求 銷售方式上的思路、需求（直銷還是渠道？直銷怎麼做？渠道怎麼做？） 技術支援方式上的思路、需求（提供什麼樣的技術服務？）。

1.1編寫目的· 闡明開發本軟體的目的；1.2專案背景· 標識待開發軟體產品的名稱、程式碼；· 列出本專案的任務提出者、專案負責人專案負責人、系統分析員、系統設計員、程式設計員、程式設計師、資料員以及與本專案開展工作直接有關的人員和使用者；· 說明該軟體產品與其他有關軟體產品的相互關係。

1.3術語說明列出本文件中所用到的專門術語的定義和英文縮寫詞的原文。1.4參考資料（可有可無）列舉編寫軟體需求規格說明時所參考的資料，包括專案經核准的計劃任務書、合同、引用的標準和規範、專案開發計劃、需求規格說明、使用例項文件，以及相關產品的軟體需求規格說明。

在這裡應該給出詳細的資訊，包括標題、作者、版本號、發表日期、出版單位或資料來源。2.專案概述2.1待開發軟體的一般描述描述待開發軟體的背景，所應達到的目標，以及市場前景等。

2.2待開發軟體的功能簡述待開發軟體所具有的主要功能。為了幫助每個讀者易於理解，可以使用列表或圖形的方法進行描述。

使用圖形表示，可以採用：· 頂層資料流圖；· 用例UseCase圖；· 系統流程圖；· 層次方框圖。2.3使用者特徵和水平（是哪類人使用）描述終端使用者應具有的受教育水平、工作經驗及技術專長。

2.4執行環境描述軟體的執行環境，包括硬體平臺、硬體要求、作業系統和版本，以及其他的軟體或與其共存的應用程式等。2.5條件與限制給出影響開發人員在設計軟體時的約束條款，例如：· 必須使用或避免使用的特定技術、工具、程式語言和資料庫；· 硬體限制；· 所要求的開發規範或標準。

3.功能需求3.1功能劃分列舉出所開發的軟體能實現的全部功能，可採用文字、圖表或數學公式等多種方法進行描述。3.2功能描述對各個功能進行詳細的描述。

4.外部介面需求4.1使用者介面對使用者希望該軟體所具有的介面特徵進行描述。以下是可能要包括的一些特徵：· 將要採用的圖形使用者介面標準或產品系列的風格；· 屏幕布局；· 選單佈局；· 輸入輸出格式；· 錯誤資訊顯示格式；建議採用RAD開發工具， 比如Visio，構造使用者介面。

4.2硬體介面描述系統中軟體產品和硬體裝置每一介面的特徵，以及硬體介面支援的裝置、軟體與硬體介面之間，以及硬體介面與支援裝置之間的約定，包括交流的資料和控制資訊的性質以及所使用的通訊協議。4.3軟體介面描述該軟體產品與其有關軟體的介面關係，並指出這些外部軟體或元件的名字和版本號。

比如執行在什麼作業系統上，訪問何種型別的資料庫，使用什麼資料庫連線元件，和什麼商業軟體共享資料等。4.4通訊介面描述和本軟體產品相關的各種通訊需求，包括電子郵件、Web瀏覽器、網路通訊協議等。

4.5故障處理對可能的軟體、硬體故障以及對各項效能而言所產生的後果進行處理。5.效能需求5.1資料精確度輸出結果的精度。

5.2時間特性時間特性可包括如下幾方面·響應時間；·更新處理時間；·資料轉換與傳輸時間；·執行時間等。5.3適應性在操作方式、執行環境、與其他軟體的介面以及開發計劃等發生變化時，軟體的適應能力。

6.其他需求列出在本文的其他部分未出現的需求。如果不需要增加其他需求，可省略這一部分。

7.資料描述7.1靜態資料7.2動態資料包括輸入資料和輸出資料。7.3資料庫描述給出使用資料庫的名稱和型別。

7.4資料字典對於資料流圖、層次方框圖中出現的所有圖形元素在資料字典中都要作為一個詞條加以定義，使得每一個圖形元素都有唯一的一個清晰明確的解釋。資料字典中所有的定義必須是嚴密的、精確的，不可有二意性。

7.5資料採集·列出提供輸入資料的機構、裝置和人員·列出資料輸入的手段、介質和裝置；·列出資料生成的方法、介質和裝置。8.附錄包括分析模型，待定問題圖表等。

想開發app的話可以聯絡我 微訊號：qidi-27773。

軟體需求的定義：（1）使用者解決問題或達到目標所需的條件或能力。

（2）系統或系統部件要滿足合同、標準、規範或其它正式規定文件所需具有的條件或能力。（3）一種反映上面（1）或（2）所描述的條件或權能的文件說明。

實通俗的講，“需求”就是使用者的需要，它包括使用者要解決的問題、達到的目標、以及實現這些目標所需要的條件，它是一個程式或系統開發工作的說明，表現形式一般為文件形式。需求工程的定義：需求分析的過程，也叫做需求工程和需求階段，它包括了需求開發和需求管理兩個部分。

需求開發是指從情況收集、分析和評價到編寫文件、評審等一系列產生需求的活動，分為四個階段：情況獲取、分析、制訂規格說明和評審。這四個階段不一定是遵循線性順序的，他們的活動是相互獨立和反覆的。

需求管理是軟體專案開發過程中控制和維持需求約定的活動，它包括：變更控制、版本控制、需求跟蹤、需求狀態跟蹤等工作。需求開發與管理的一些方法：（1）繪製關聯圖：繪製系統關聯圖是用於定義系統與系統外部實體間的界限和介面的簡單模型。

（2）可行性分析：在允許的成本、效能要求下，分析每項需求實施的可行性，提出需求實現相關風險，包括與其它需求的衝突，對外界因素的依賴和技術障礙。（4）系統原型：當用戶自身對有的需求不十分清楚時，我們可以建立一個系統原型，使用者通過評價原型更好地理解所要解決的問題。

（5）圖形分析模型：繪製圖形分析模型是編制軟體需求規格說明重要手段。

它們能幫助分析人員理清資料、業務模式、工作流程以及他們之間的關係，找出遺漏、冗餘和不一致的需求。這樣的模型包括資料流圖、實體關係圖、狀態變換圖、對話方塊圖、物件類及互動作用圖。

（6）資料字典：資料字典是對系統用到的所有資料項和結構的定義，以確保開發人員使用統一的資料定義。在需求階段，資料字典至少應定義客戶資料項，確保客戶與開發小組是使用一致的定義和術語。

需求管理的方法主要包括以下一些方面：1）確定需求變更控制過程。制定一個選擇、分析和決策需求變更的過程，所有的需求變更都需遵循此過程。

2）進行需求變更影響分析。評估每項需求變更，以確定它對專案計劃安排和其它需求的影響，明確與變更相關的任務並評估完成這些任務需要的工作量。

通過這些分析將有助於需求變更控制部門做出更好的決策。3）建立需求基準版本和需求控制版本文件。

確定需求基準，這是專案各方對需求達成一致認識時刻的一個快照，之後的需求變更遵循變更控制過程即可。每個版本的需求規格說明都必須是獨立說明，以避免將底稿和基準或新舊版本相混淆。

4）維護需求變更的歷史記錄。將需求變更情況寫成文件，記錄變更日期、原因、負責人、版本號等內容，及時通知到專案開發所涉及的人員。

為了儘量減少困惑、衝突、誤傳，應指定專人來負責更新需求。5）跟蹤每項需求的狀態。

可以把每一項需求的狀態屬性（如已推薦的，已通過的，已實施的，或已驗證的）儲存在資料庫中，這樣可以在任何時候得到每個狀態類的需求數量。6）衡量需求穩定性。

可以定期把需求數量和需求變更（新增、修改、刪除）數量進行比較。過多的需求變更"是一個報警訊號"，意味著問題並未真正弄清楚。

4.需求分析評價標準（1）清晰：目前大多數的需求分析採用的仍然是自然語言，自然語言對需求分析最大的弊病就是它的二義性，所以開發人員需要對需求分析中採用的語言做某些限制。例如儘量採用主語+動作的簡單表達方式。

需求分析中的描述一定要簡單，千萬不要採用疑問句、修飾這些複雜的表達方式。 除了語言的二義性之外，注意不要使用行話，就是計算機術語。

需求分析最重要的是和使用者溝通，可是使用者多半不是計算機的專業人士，如果在需求分析中使用了行話，就會造成使用者理解上的困難。（2）完整：需求的完整性是非常重要的，如果有遺漏需求，則不得不返工，在軟體開發過程中，最糟糕的事情莫過於在軟體開發接近完成時發現遺漏了一項需求。

但實際情況是，需求的遺漏是常發生的事情，這不僅僅是開發人員的問題，更多發生在使用者那裡。要做到需求的完整性是很艱難的一件事情，它涉及到需求分析過程的各個方面，貫穿整個過程，從最初的需求計劃制定到最後的需求評審。

（3）一致：一致性是指使用者需求必須和業務需求一致，功能需求必須和使用者需求一致。在需求過程中，開發人員需要把一致性關係進行細化，比如使用者需求不能超出預前指定的範圍。

嚴格的遵守不同層次間的一致性關係，就可以保證最後開發出來的軟體系統不會偏離最初的實現目標。（4）可測試：一個專案的測試從什麼時候開始呢？有人說是從編碼完成後開始，有人說是編碼的時候同時進行單元測試，編碼完成後進行系統測試，這些結論都不完全正確。

實際上，測試是從需求分析過程就開始了，因為需求是測試計劃的輸入和參照。這就要求需求分析是可測試的，只有系統的所有需求都是可以被測試的，才能夠保證軟體始終圍繞著使用者的需要，保證軟體系統是成功的。