10概念阶段定义产品包需求指南.doc

请输入文档名称
绝密
请输入文档编号

《端到端产品包需求模板》lotus版
《端到端产品包需求模板》office版

模板：定义产品包需求指南（正式模板见上面嵌入文件）
√ Concept概念 __ Develop开发 __ Launch发布 __ Interim临时
__ Plan计划 __ Qualify验证 __ Life Cycle生命周期

前言
a、该模板的目的Objective of this Template:
本操作指导书仅用于指导收集SE和R&D特有的产品包需求。实际需求不应填写在本模板中，所有部门的需求都要填写在统一的端到端产品包需求模板中（正式模板见上面嵌入文件）。
This Template is only to be used as a guide in generating SE and R&D specific offering requirements. Actual requirements are not to be put into this template，All domain requirements will be captured in the "above domain" E2E Offering Requirements template.
产品包需求模板是一个正式文档，它非常清晰地描述了产品包需求。写作时综合市场和内部需求并对其整合、排序形成产品包需求。市场需求是从客户的角度来确定，而产品包需求则从系统的角度来确定。特别地，要包括$APPEALS所述各项市场需求及如下内部需求：兼容性、共用性、成本有效性、可靠性、可服务性、可测试性、地理市场、技术方面、可制造性。
The Offering Requirements template is a formal document that provides a very clear description of the offering requirements. Summarize the offering requirements combining and prioritizing the market and internal requirements. Market requirements are stated from a user view whereas offering requirements are stated from a systems view. Specifically, include the requirements in the categories of $APPEALS (market requirements) as well as the internal requirements for: Compatibility、Commonality、Cost Effectiveness、Reliability、Serviceability、Testability、Geographical market、Technological、Manufacturability。
b、写作主体
PDT应当与系统工程师一起工作，同其他专项业务专家商讨，并确定与市场需求相对应的系统需求。
The PDT should work with the Systems Engineer, consult other subject matter experts as appropriate, and identify the system requirements corresponding to the market requirements.
1 概述 Summarize:
对初步构思的系统结构和标准进行概述 (Summarize the initial thinking system architecture and standards) ；
列出CBB重用机会 (List CBB reuse opportunities)；
对初步构思的产品结构进行概述 ( Summarize the initial thinking product structure) 。
2 产品包需求 Offering Requirements：
产品包需求模板可将市场和其他需求转化为产品包技术系统需求。( The Offering Requirements template enables the transformation of marketing and other requirements into technical systems requirements for the offering. )
根据下表指示，列出概念阶段的市场需求和其它需求，确定相应的产品包需求，置入到《端到端产品包需求模板》中，一个市场需求可能会产生多个产品包需求。《端到端产品包需求模板》使产品包需求能够回溯到市场需求。( According the instruction of the table below, list the Market Requirements and other requirements from the Concept phase and identify the corresponding offering requirements. Posting into the <E2E-Template- End to End Offering Requirements Template> . A single market requirement may generate multiple offering requirements. < E2E-Template- End to End Offering Requirements Template> will enable the offering requirements to be traced back to the market requirements.)

序号
市场需求 ($APPEALS)和其它需求
产品包需求
1.
价格：客户希望对他们所寻求的价值支付多少钱？
1.1.1 定价考虑依赖于竞争市场压力和客户目前通常购买的竞争对手产品。竞争性价格和实际特性成本之间的平衡需根据目标利润仔细权衡
2.
可获得性：客户完成购买的经验—包括购买渠道
2.1.1 产品包需求必须清晰地指出销售渠道。理想的销售渠道来自于过去销售经验，以及询问客户现在和将来的购买经历。
3.
包装：形象评估/包装
3.1.1 产品包的包装必须有说明，不仅要考虑客户，还要考虑安装和维修问题。
4.
性能：需要哪些功能和性能特性？
4.1.1 产品包需求应当概述客户愿意接受的性能接受级别。性能级别应当通过客户在实际使用中对系统的测试来得到确认。
5.
易用性：什么构成易于使用，安装，管理等？
5.1.1 产品包需求清晰地定义了有关使产品包易于使用的可用性需求，因此对于客户或最终用户更具吸引力。
6.
保修：给客户提供整套产品包/服务
6.1.1 产品包需求将就整个产品包保修级别和/或提供给客户的服务提供更为明确和技术的观点。
7.
生命周期：显示系统升级计划和生命终止的路标规划需经过高层管理者批准。哪些生命周期成本考虑影响购买意向？
7.1.1 继续和跟随生命周期路标规划以支持升级过渡计划和系统生命结束计划。来自行销、营销、研发，订单等所有跨部门团队成员举行月度支持会议以管理生命周期问题。
8.
社会接受度：什么形象会引导购买决策，客户如何获得这些信息？

8.1.1 为了取得社会认可，成功进入市场，产品包需求需通过客户反馈和
/或Beta测试以得到验证。

8.1.2 为了解决市场准入问题，是否需要进行国际认证及需要进行哪些国际认证等。（如UL、CE、NEBS等）
9.
杂项—必须考虑的任何特殊产品包特性
9.1.1杂项
10.
其他需求（内部的，但是给客户提供一些价值）

10.1
兼容性：子系统能够集成到整个系统中，并有助于系统的目标。
10.1.1 在同样的产品线范围内，子系统要保持其兼容性，并以这样的身份在整个生命中进入升级路线。.
10.2

共用性：部件能够与不同类型的现有部件进行替换。一个“高共用性”的系统由很多可现货供应或标准部件组成，一个“低共用性”的系统包含很多要从头开始开发的唯一部件。
10.2.1 产品平台、软硬件模块、单板、单元电路的重用。

10.2.2 结构件方面重用

10.2.3 关键器件方面的重用
10.3
成本有效性：如果某个具体的设计被采纳，用户可能会受到总成本的影响。成本有效性需要分析设计成本，也需要分析用户为实现某特定水平的收益实施和操作的成本。
10.3.1 要仔细评估 产品包的期望利润率，同类产品竞争压力和客户习惯购买意向。成本有效性计划的完整评估需利用特性成本有效性分解分析方法。
10.4
可靠性：系统能够在某特定级别不崩溃，或在崩溃前有一段时间仍能工作。
10.4.1 产品包不会使用有未证实的器件。所有的器件至少需在类似的应用/环境中可靠地操作6个月（无论怎样）。可靠的操作意味着供应商有书面证据显示平均无故障时间（MTBF）至少6个月（无论怎样）。

10.4.2 产品包需提供自诊断程序，定时自动执行，并在即将发生故障时通知客户，以使他们能够联系和考虑技术支持。

10.4.3 当发现有即将发生的故障时，产品包具备自动防故障装置，比如它可自己采取措施以隔离问题或转换到一个不同的（冗余的？）硬件或软件（备份的？前一个版本？）进行操作。目的是将对客户的破坏降到最低。
10.5
可服务性：子系统在一定时间内能够被修复（易于维修），或系统运行在最小破坏范围内被修复。远程诊断，并确定维修的零件或装置。
产品包可服务性标准是由客户确定的。为取得可接受的正确判断，需进行关于服务和维护期望以及服务成本和相关的保修的客户访谈。
通过客户访谈和同类产品竞争对手服务交付分析，团队将了解到客户对可服务性的期望。团队应能回答类似这样的问题：客户乐意为服务等待多久？你的竞争对手在服务和维护等方面有哪些交付？
10.6
可测试性：子系统有助于系统具备测试和性能衡量的程度
10.6.1 通过一系列客户认可的性能测试方法测试产品包。某些测试方法通过产品包现有和潜在客户的可用性测试和Beta测试来得到确认。
10.7
地理市场
10.7.1 不同的地理位置有不同的需求，比如电源限制，贸易批准，环境，当在另一个地理位置开发或发布产品包时，这些都是重点要考虑的。
10.8
技术方面
10.8.1 技术在任何产品包中都担任了很重要的位置。解释产品包中用到某特定技术的原因。它是否会使客户工作得更快，更容易，更有效率？该技术与竞争对手的区别？
10.9
可制造性
10.9.1 基于以往的一些经验、教训，这一需求可使产品更易制造， 减少缺陷，降低成本，是建立在经验教训基础之上的。它是起正面的积极作用的，并包括可制造性设计规则。

No.
Market Requirements ($APPEALS) and other requirements
Offering Requirements
1.
Price: How much do customers expect to pay for the value they seek?

1.1.1 Pricing considerations depend on competitive market forces and on competitive products customers are currently accustomed to buying. A balance between competitive pricing and actual offering cost by feature must be carefully considered by determined desired profit margin.
2.
Availability: Customers complete buying experience - including the channels through which they buy

2.1.1 Offering requirements must clearly indicate the channels that will sell the offering. Ideas of what channels comes through historical knowledge of what has worked in the past as well as asking customers about the buying experience now and what will be in the future.
3.
Packaging: Visual evaluation / Bundling

3.1.1 Packaging for the offering must be self explanatory and have considerations that not only deal with the customer, but also installation and repair issues.
4.
Performance: What functionality & performance characteristics are wanted?

4.1.1 Offering requirements must outline the performance acceptance level the customer is willing to accept. The level of performance must be validated by customer through testing of system in real life scenario.
5.
Ease of Use: What constitutes ease of use, installation, administration, etc. ?

5.1.1 Offering requirements clearly define usability requirements involved in making the offering easy to use and therefore more appealing to the customer or end user.
6.
Assurances: Provided by the whole offering/ service to customer.

6.1.1 Offering requirements will provide a more definitive and technical perspective on the overall assurance level of the offering and /or service provided to customer.
7.
Life Cycle: roadmaps that indicate the schedule of upgrades and end of life of systems should be approved by senior management. What lifecycle cost considerations influence the purchase decision?

7.1.1 Life Cycle roadmaps should be maintained and followed by development to sustain plan for transition upgrades and end of life pland for systems. A monthly sustaining meeting should be held to manage life cycle issues by all crosds functional team members from marketing, sales, R&D, fulfillment, etc.
8.
Social Acceptance: What "image" will facilitate a purchase decision and how do customers acquire this information?

8.1.1 Offering requirements should have been validated through customer feedback and/or beta testing for approval of social acceptance in order for successful entry into market.

8.1.2 Types of certificationes(such as UL\CE\NEBS),which are necesarry for solving marketing entry, should be defined.
9.
Misc.- Any unique to offering attributes necessary for consideration
9.1.1Misc.-
10.
Other requirements (internal, but provide some value to the customer)

10.1
Compatibility: ability of subsystems to be integrated into the whole system and to contribute to objectives of the system
10.1.1 Subsystems should maintain compatibility within like offering lines and be transitioned as such into upgrade paths on through end of life.
10.2
Commonality: ability of a component to be used interchangeably with an existing component of a different type. A 'high commonality' system is composed of many 'off-the-shelf' or standard components; a 'low commonality' system contains many unique components which must be developed from scratch.
10.2.1 The reuse of Product Platform, module, Unit and components

10.2.2 The reuse of product structure components

10.2.3 The reuse of key components
10.3
Cost Effectiveness: the total cost to which the user may be subjected if a particular design is adopted. Cost effectiveness requires analysis of cost of the design, as well as the cost to the user to implement and operate the design to achieve a given level of benefit.


10.3.1 The offering must be carefully be evaluated against the desired profit margin, competitive pressures on like products and what the customer is accustomed to paying. Feature cost effective analysis breakdowns must be employed for solid estimate of cost effectiveness planning.
10.4
Reliability: the ability of a system to function at a given level without failing, or to function for a given period of time before failing.
10.4.1 There will be no unproven components used in the offering. All components will be required to demonstrate that they have operated reliably in similar applications/conditions for at least a six month (whatever) period. Reliable operation means that the supplier has documented evidence showing that the MTBF (Mean Time Between Failures) is at least six months (whatever).

10.4.2 The offering should provide self-diagnosis routines that automatically run at regularly scheduled times and alert the customer of impending failures, so they can contact and advise tech support.

10.4.3 When impending failures are detected, the offering should be fail-safe, i.e., it should automatically take measures to isolate the problem or switch operation to a different (redundant?) hardware or a different software version (backup?, previous version?), as appropriate. The objective is to have minimum customer disruption.
10.5
Serviceability: the ability of a subsystem to be repaired within a certain period of time (ease of repair), or to be repaired with minimal disruption to operation of the system. Diagnose remotely and identify repair parts or fixes.
10.5.1 The standards that the offering serviceability will be determined by the customer. Customer interviews on service and maintenance expectations against cost of these services and associated warranties must be performed for an accurate judgment of what is acceptable.
Through customer interviews and competitive analysis of service offerings for like products, the team will know what is expected by the customer in the way of serviceability. The team should be able to answer questions like: How long does is the customer willing to wait for service? What are your competitors offerings in the areas of service and maintenance, etc.
10.6
Testability: the degree to which a subsystem enables systematic testing and measuring of its performance capabilities
10.6.1 Offering should be tested through a variety of methods for measurement of performance capabilities deemed acceptable by customer. Some of these testing measurements are determined through usability testing and beta testing with current and potential customers of the offering.
10.7
Geographical markets
10.7.1 Different geographies have different requirement such as power cords, approvals, environmental situations that are important to consider when developing or launching an offering in another geography.
10.8
Technological
10.8.1 Technology plays a large part of any offering. Explain the reason why this particular technology is incorporated into the offering. Does it benefit the customer to work faster, easier, more efficiently? How does this technology stand apart from the competition's?

10.9
Manufacturability
10.9.1 The requirements to make the product easy to manufacture, with reduced defects, reduced costs, etc. based on lessons learned from experience. This is intend
ed to be proactive, and includes design rules for manufacturability.

1 写作例子 Writing Example
将市场需求转化为产品包需求。例如，某个汽车的一个市场需求可能是，它应能载五名乘客，在高速公路坡道处能快速转入快速行驶。相应的产品包需求就可能根据技术系统需求来表示，如在10秒内加速度从0提到100公里/小时，汽车尺寸和重量，发动机马力和扭矩等级，齿轮比率等等。另外一个例子是，某个房子的市场需求可能是，它要能适合四口之家，在产品包需求中就会被转化为具体房间数量和尺寸，门口或者房间之间的连接。
Translate the market requirements into offering requirements. For example, a market requirement for a car might be that it should carry five passengers and be capable of merging quickly into fast-moving traffic on highway entrance ramps. The corresponding offering requirements, would be expressed in terms of technical system requirements, such as acceleration from 0 to 100 kph in 10 seconds, car size and weight, engine horsepower and torque ratings, gear ratios, and so on. Another example of market requirements for a house might be that 'it should be comfortable for a family of four', which would then be translated into a certain number and size of rooms, and the doorways or interconnections between rooms in the offering requirements.

1 需求评估与排序 Requirements assessment and order
对《端到端产品包需求模板》内容，按照下表指示进行分析评估、排序。 According the instruction of the table below，making requirement analysis , assessment and order for the contents of <E2E-Template- End to End Offering Requirements Template>

主要需求分析评估表 Main requirement analysis and assessment table
风险评估
Risk assessment
1.大容量局要求有高度的稳定性和容错性, 一旦出现故障会引起用户强烈的投诉
High stability and error tolerability are required for an exchange of large capacity, for once there is a fault, strong complaints are possible from the users.
2 人力需求可能无法满足.
Human power requirements may not be satisfied.
3.开发设计周期短
The development and designing cycle is short.
可变性分析
Variability analysis
移动网的建设向3级话路网, 大容量的方向发展, 目前最大容量的VMSC容量已经达到了40万用户(ERICSSON), 大容量MSC需求的可变性不大.
The mobile network construction is developing in the direction of 3-level speech path network and large capacity. The capacity of VMSC, which is the largest at present, has already reached four hundred thousand users (ERICSSON), so there will not be a great variability in respect to large capacity MSC requirement.
对需求的分析理解
Analysis and understanding toward requirements
1.交换机的结构要将对外接口,网交换和业务处理分开
In terms of switch architecture, the external interface, network switching should be separated from service processing.
2.采用高处理能力的处理机, 总BHCA需要达到3000K
Processors with high processing capacity are used, total BHCA is required to be 3000K
3. 采用低功耗, 高集成度的器件, 提高系统集成度, 降低功耗
Devices of low power consumption and high integration are used, to enhance the system integration and lower the power consumption
4. 系统公共资源采用共享的方式管理, 提高利用度.
Management in a shared mode is used for the system public resources, so as to enhance their usability.
难度
Difficulty
l移植交换业务部大容量的C&C08 128SPM平台, 难度中等
The diffi