網上有很多關于pos機需求,需求是最重要的事的知識，也有很多人為大家解答關于pos機需求的問題，今天pos機之家(www.www690aa.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!
本文目錄一覽：
1、pos機需求
pos機需求
無論做什么事都是有流程的。
談到流程，很多人立刻就會想到熟悉的瀑布模型、螺旋模型、迭代開發、敏捷、RUP等一堆軟件工程相關的軟件開發流程，這流程都與項目管理有關，我們可以稱為“管理流程”。
面向對象開發也有一套流程，我們可以稱為“技術流程”。面向對象的技術流程可以概括如下：
需求模型→領域模型→設計模型→實現模型
以上流程環環相扣，上一步流程的輸出就是下一步流程的輸入。
俗話說，萬事開頭難。需求是軟件項目的最開始輸入，肯定是非常重要的，按道理來說也應該是需要重點關注的。
然而，現實情況卻恰恰相反：很多項目都不怎么重視需求！
我們可以經常看到這樣的場景：
需求分析人員/產品經理和用戶溝通了一下，然后把用戶的要求簡單整理一下就交給研發人員了……
項目計劃比較緊，那么就把需求分析階段加快一些吧（實際上就是減少投入時間）……
產品人員給了一個簡單的需求，為了能夠快速交付，沒有怎么分析就開始設計編碼了……
雖然看起來時間是節省了，項目進度是加快了，然而最終的結果卻令人失望——據統計，有將近1/3的項目失敗或者陷入困境是因為需求原因導致的！
這就是所謂的“垃圾進垃圾出（Garbage in，garbage out）”的效果，即：如果最開始的輸入是錯誤的，后面的過程再怎么優秀，最終都會輸出垃圾產品。而且可能是后面越優秀，最終輸出越垃圾，就像你朝一個錯誤的方向跑步，跑得越快離正確的終點越遠一樣。
舉一個雖然惡心但很形象的例子：給你一坨屎，你放到餅干生產線上，最后生產出來的不是餅干，而是像餅干的一坨屎！
你可能會說，錯了我改還不行嗎？
當然是可以的，但你要做好心理準備，還有一個更加令人震驚的事實：修復需求錯誤的成本非常高！
我們假設在編碼階段發現和修復一個錯誤所耗費的人力是1個單位，那么在測試階段修復需求錯誤的成本是5～10，在維護階段（產品正式上線后）修復需求錯誤的成本是20，而如果在需求階段修復需求錯誤，成本只需要0.1～0.2即可。
也就是說，需求錯誤的成本存在這樣的比例關系：維護階段修復=需求階段修復×200！
原因顯而易見：如果需求錯了，那么幾乎是要把軟件項目重做一遍！
相信經過前面的分析，對于需求的重要性你已經有了充分的認識。
請時刻牢記：需求很重要！
但到底什么是需求呢？
簡單的講就是：需求即系統需要做什么。
但很多人會陷入陷阱：需求即功能。
以下給出需求與功能的定義。
需求：對客戶來說有價值的事情。
功能：系統為了實現客戶價值而提供的能力。
因此，區別是需求還是功能的方法很簡單：只要判斷是否對客戶有價值。
我們可以舉些例子:
汽車：“駕駛”是需求，“發動機”、“剎車”、“加速”等是功能。
打印機：“打印”是需求，“進紙”、“設定”、“與電腦連接”等是功能。
POS機：“買單”是需求，“商品掃描”、“金額匯總”、“收銀”等是功能，因為買完單后顧客就能將產品拿走。
……（有興趣的，還可以自己多想想更多的例子）
為什么要分清需求與功能呢？
我們來看一個簡單的場景，用戶找到你說：“我要一只羊！”
這個事夠簡單吧？那你是不是毫不猶豫地就抓一只羊給用戶呢？
如果你這樣做了，并且運氣好，客戶可能非常滿意，但是在大部分情況下，也許客戶很不滿意，為什么？
我們來看“我要一只羊”這個事的多個版本。
一個饑腸轆轆的人說，我要一只羊，用來烤著吃！
一個慈愛的父親說，我要一只羊，給我的小孩做寵物！
一個農場主說，我要一只羊，生小羊！
看了上面幾個場景，相信你就大概明白了：
什么才是用戶的真正的要解決的問題。
如果客戶是用來吃的，也許你更應該提供一頓烤羊肉，或者一只大羊腿，客戶會更加滿意。
如果客戶是用來給小孩做寵物的，那么給一只雪白的漂亮的小羊羔也許他的小孩更高興。
如果客戶是用來生小羊的，那么給一只強壯的成年母羊是更好的選擇。
所以說，區分需求與功能，有助于深入了解客戶的問題，有助于更好地實現需求，提供最有價值的產品。
做好了需求模型，接下來將開始領域模型。
且待下回分解。
以上就是關于pos機需求,需求是最重要的事的知識，后面我們會繼續為大家整理關于pos機需求的知識，希望能夠幫助到大家！
