产品概要设计

㈠ 概要设计是不是产品经理的工作职责

要看具体情况的。来
产品经理是负责源并保证高质量的产品按时完成和发布的专职管理人员。在产品管理中，产品经理是领头人，是协调员，是鼓动者。虽然不同企业的产品经理承担的具体职责各个企业会存在差异，但是，一般而言，产品经理的主要职责包括以下内容：
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机时代的到来，人机交互界面在软件中占有越来越重要的地位，原来的一套软件只有一个操作员，而现在可能有很多的使用者，为了清楚地描述不同人群对软件的诉求，业务用例应运而生，这就是面向对象的起点。不同的基因决定了他们各擅道场，一个擅长于后台计算的产品设计，另一个长于面向客户服务的产品设计。 在设计中，我们可以根据需求把两者的特点灵活地结合在一起，比如算法密集的处理模块，我们可以采用数据流图，而对于和外部交互比较复杂的模块，可以引入用例图标识模块支持的使用场景。 逻辑模型的设计 逻辑模块的设计主要是数据库的设计和值对象的设计。对于数据库的逻辑模型，可以统一设计，模块中添加引用。也可以在模块中针对所引用的库表独立描述。这两种方式都可以，如果库表结构比较复杂的建议统一建模，而比较简单的模型可以采用分开描述，提升模块设计的可读性。数据库建模现在已经比较成熟，这里不再多说。 模块的输入输出，以及中间的数据对象，我们统称为值对象，在概要设计阶段的重点是描述值对象的关键属性。需要注意的一点是值对象要和处理逻辑对应起来，特别是处理逻辑中的数据流，出口入口数据，都要在值对象上加以描述。