dfd、erd和use case。這是3種常用的需求建模，它們各有其側重點；它們的共同點是：使用圖形化的手段進行描述。圖形化的好處就是元素之間的關係一目了然，避免自然語言描述上的混沌和零散。
不要用專業詞彙限制使用者的思維。在座談調研時，乙個很容易發生的情況是：需求調研人員在努力地向客戶解釋、比劃乙個軟體上的概念。其結果往往是客戶似懂非懂，反而限制、阻礙了它擅長的業務邏輯和思路：得不償失。
不要當場否定客戶的要求。不少時候，客戶會提出我們本次專案明顯不能實現的要求，此時需求調研人員傾向於立即反駁客戶的要求，並說出很多「道理」來嚇退客戶。其實，這樣做會打斷或阻礙客戶的思維；需求調研人員此時可以順著客戶的思維進行下去，誘導客戶說出更深層次的業務要求。對於本次專案不能實現的問題，我們可以利用其它的機會向他們進行解釋。
大綱需求到詳細需求。初次的需求訪談產生的需求大綱，會帶來大量的需求細節需要澄清。這就要求需求調研人員仔細整理這些需求點，準備好進行下一次的需求訪談。同時，初次訪談形成的大綱可以為調研人員提供足夠的背景資訊，從而在下次訪談中能提出更多、更有針對性的問題。
需求分析 1
需求分析做得好，才能夠使設計的產品滿足市場需求，有了明確的需求才能夠確定產品的id設計方案 結構設計方案 硬體設計方案和軟體方案。1.1功能需求 硬體系統常見的功能需求有 供電方式及防護 輸入與輸出訊號類別及處理 無線通訊功能。明確了功能就可以對要完成的功能選擇不同廠家的晶元來實現所需功能。1.2整...
1 需求分析
主要的功能 商品的管理，瀏覽，庫存，使用者及啟用，購物車，訂單。1 前台使用使用者 a.使用者需要進行註冊，註冊的時候需要準備出所有的核心資訊，使用者id email 密碼 使用者狀態 未啟用 鎖定 正常 姓名 位址 b.使用者可以進行商品的分類瀏覽 方便只分一類 分類資訊 分類編號 名稱 商品資訊...
關於需求分析1
研究生期間做過很多的小管理類專案,對於管理類專案的需求分析,有個體會.個人感覺需求,首先要明確系統的服務物件,要滿足並超出其預期才會有好的結果,服務物件就是系統管理的流程的制定者.雖然看起來很簡單,其實很容易出現意外.依然記得當年本科資料庫的課程設計,老師要求大家做乙個訂票的系統,2個角色,旅客和售...