產品概要設計

㈠ 概要設計是不是產品經理的工作職責

要看具體情況的。來
產品經理是負責源並保證高質量的產品按時完成和發布的專職管理人員。在產品管理中，產品經理是領頭人，是協調員，是鼓動者。雖然不同企業的產品經理承擔的具體職責各個企業會存在差異，但是，一般而言，產品經理的主要職責包括以下內容：
1、協助部門領導制定產品管理制度與方案；
2、負責向企業高層提供有助於決策企業戰略的市場依據和建議；
3、規劃產品戰略發展方向，制定產品的長期競爭策略；
4、規劃產品年度發展方向，制定產品年度計劃；
5、對所負責的產品進行市場調研並進行分析，提出產品改進計劃；
6、對產品的設計、開發、包裝、渠道、定價、上市等過程進行全程監控；
7、對產品在不同階段出現的問題進行記錄並進行處理；
8、對產品品牌和產品成本進行管理；
9、負責組織產品團隊完成產品的功能設計和實施；
10、負責產品項目的開發，對進度和質量進行監控；
11、優化產品組合，提升產品價值；
12、對產品市場有足夠的把握，充分了解用戶需求；
13、協助企業和部門領導完成有關產品的其它工作；
14、負責與相關部門（銷售、製造、研發等）進行聯絡和協調。

㈡ 需求分析和概要設計有什麼區別

一、過程不同

1、需求分析：是開發人員經過深入細致的調研和分析，准確理解用專戶和項目的屬功能、性能、可靠性等具體要求，將用戶非形式的需求表述轉化為完整的需求定義，從而確定系統必須做什麼的過程。

2、概要設計：是一個設計師根據用戶交互過程和用戶需求來形成交互框架和視覺框架的過程。

二、任務不同

1、需求分析：是軟體計劃階段的重要活動，也是軟體生存周期中的一個重要環節，該階段是分析系統在功能上需要「實現什麼」，而不是考慮如何去「實現」。

2、概要設計：是一個在用戶研究和設計之間架起橋梁，使用戶研究和設計無縫結合，將對用戶目標與需求轉換成具體界面設計解決方案的重要階段。

三、規則不同

1、需求分析：側重表達理解問題的數據域和功能域。對新系統程序處理的數據，其數據域包括數據流、數據內容和數據結構。而功能域則反映它們關系的控制處理信息。

2、概要設計：是把需求分析得到的系統擴展用例圖轉換為軟體結構和數據結構。設計軟體結構的具體任務是：將一個復雜系統按功能進行模塊劃分、建立模塊的層次結構及調用關系、確定模塊間的介面及人機界面等。

㈢ 採用結構化設計時，在概要設計階段結束後，可得到什麼產品

我猜測題主應該是做軟體的。所問的也是軟體結構化設計的問題。
概要設計還不內足以形成一個真容正的產品，這個過程輸出的東西請參考以下文字（摘自網路）：
概要設計也稱為結構設計或總體設計，主要任務是把系統的功能需求分配給軟體結構，形成軟體的模塊結構圖。

概要設計的基本任務：設計軟體系統結構：劃分功能模塊，確定模塊間調用關系；數據結構及資料庫設計：實現需求定義和規格說明過程中提出的數據對象的邏輯表示；編寫概要設計文檔：
包括概要設計說明書、資料庫設計說明書，集成測試計劃等；概要設計文檔評審：對設計方案是否完整實現需求分析中規定的功能、性能的要求，設計方案的可行性等進行評審。

㈣ 概要設計說明書和總體設計說明書的區別

我的理解是，總體設計僅僅描述了產品的形態，如果是網路軟體，可以描述產品以其他子系統在網路中的部署方式、聯系方式。總體設計需要把產品所有可能出現的產品形態列出，這樣可以方便非技術人員(市場、客戶)了解這個產品的功能。
概要設計則是針對一個產品做出稍微詳細的分析，需求提供相關介面、模塊劃分、數據存儲方式等。

我也是最近在做設計才了解的，以上僅是個人理解.

㈤ 需求分析與概要設計的區別是什麼

概要設計說明書與需求分析說明書的區別是什麼 需求說明書主要是項目前期而設計說明書是產品或系統開發前，在功能需求已經很明確的情況下，為實現需求

㈥ 如何做概要設計

概要設計的目標是描述軟體模塊的外觀以及處理邏輯。模塊對外暴露的服務介面，以及需要引用的介面，介面標識，介面的訪問協議，介面描述都屬於模塊的外觀，其他的模塊通過這些介面和模塊打交道，自然需要在概要設計階段對介面做細致的刻畫，初此之外，對於關鍵的模塊，外觀還應該說明模塊的非功能屬性，比如並發處理能力，數據吞吐量以及介面調用的反饋時長等等。處理邏輯是指模塊從輸入到輸出的轉換過程，描述其轉換演算法。無論通過何種圖例和表現形式，只要能夠清晰地說明模塊外觀和處理邏輯描述，就是好的概要設計。 概要設計過程一般包括四塊內容，這四塊內容都是圍繞著外觀和處理邏輯這兩個目標進行。第一部分是模塊劃分，把架構設計中劃分的業務模塊按照開發模式迭代細化，拆分成符合高內聚低耦合的功能模塊。第二部分是介面描述，重點要放在刻畫模塊內外部交互的介面形式。第三個部分是模塊的邏輯描述，最後一個部分邏輯模型設計，包括資料庫的邏輯模型設計以及值對象的概要說明。 模塊劃分 模塊劃分的粒度很難確定，不同的設計師會用不同的劃分策略，相同的一組功能聚集有人會分為2個功能模塊，有的人可能劃分為4個或者更多。模塊的粒度越大，對模塊的維護成本就越大，因為修改模塊的任何一個點，都有可能更新整個模塊；而且越難以解決模塊復雜耦合的問題，隨著產品的維護，模塊內的耦合會越來越嚴重，有些是因為新的需求引起模塊內聯系的增加，而有些是缺少硬約束下採用最直接的方式修改代碼造成的。當然也不是模塊劃分的越小越好，因為小粒度的模塊雖然降低了模塊自身的維護成本，但過多的模塊會增加模塊間關系維護的成本以及系統管理的復雜性。 通常來看，模塊劃分要符合開閉原則和高內聚和低耦合的原則。開閉原則強調的是維護頻度不同的功能不要放在同一個模塊內，比如有些需要本地化的功能可以通過介面和實現分離的方式劃分為業務模塊和二次介面實現模塊。高內聚和低耦合的原則強調的是把內部關聯緊密和外部交互比較單一的功能劃分成一個模塊。 同時鑒於模塊劃分的重要性，建議盡可能把模塊劃分的工作前移到架構設計階段，一方面架構設計團隊的整體素質比較高，另外一方面架構設計師更能夠站在全局的視角合理地劃分模塊。 介面描述 介面描述應該清晰地說明介面的類型，訪問方式，介面的入參和出參。通常在概要設計階段不考慮物理實現，不需要描述的非常詳細，之所以如此關照介面，原因在於通過清晰的介面描述為流程邏輯和後面的詳細設計建立一個硬約束。模塊內的數據流和控制流的入口和出口都能限定在這個約束之內，方便評審的時候能及時發現設計中存在的問題。 邏輯描述 邏輯描述的目標是說清楚從輸入到輸出的轉換過程。根據不同的模塊的特點，可以選用不同的描述形式，對於以數據流為主的模塊，可以使用數據流圖，控制比較復雜的可以使用數據流圖或者IPO圖，而對於規范使用UML的項目可以考慮使用活動圖。 可能有人會很疑惑在設計中沒有談到是用面向對象方法還是結構化的方法，這可是關鍵的方法論問題。確實，軟體研發的壇子裡面除了哪種語言更好的話題以外，最容易挑起紛爭的就是結構化分析與設計和面向對象分析與設計之爭了。我在這里不做結論，只做一個評說。結構化分析設計出現的比較早，那時候軟體的主要使用場景更多是科學計算或者自動化控制，典型的特點是用戶交互界面簡單，更多是批處理的作業方式，更多關注程序的處理過程是否正確高效。隨著PC機時代的到來，人機交互界面在軟體中佔有越來越重要的地位，原來的一套軟體只有一個操作員，而現在可能有很多的使用者，為了清楚地描述不同人群對軟體的訴求，業務用例應運而生，這就是面向對象的起點。不同的基因決定了他們各擅道場，一個擅長於後台計算的產品設計，另一個長於面向客戶服務的產品設計。 在設計中，我們可以根據需求把兩者的特點靈活地結合在一起，比如演算法密集的處理模塊，我們可以採用數據流圖，而對於和外部交互比較復雜的模塊，可以引入用例圖標識模塊支持的使用場景。 邏輯模型的設計 邏輯模塊的設計主要是資料庫的設計和值對象的設計。對於資料庫的邏輯模型，可以統一設計，模塊中添加引用。也可以在模塊中針對所引用的庫表獨立描述。這兩種方式都可以，如果庫表結構比較復雜的建議統一建模，而比較簡單的模型可以採用分開描述，提升模塊設計的可讀性。資料庫建模現在已經比較成熟，這里不再多說。 模塊的輸入輸出，以及中間的數據對象，我們統稱為值對象，在概要設計階段的重點是描述值對象的關鍵屬性。需要注意的一點是值對象要和處理邏輯對應起來，特別是處理邏輯中的數據流，出口入口數據，都要在值對象上加以描述。