1704180472
1704180473
（2）需求活动要求
1704180474
1704180475
1）收集相关技术需求，要求收集所需的功能点、约束和处理流程等。
1704180476
1704180477
2）收集用户的特殊需求。
1704180478
1704180479
3）分析用户原业务或工作流程。
1704180480
1704180481
4）分析所需建立的系统业务流程，建立系统范围和目标。
1704180482
1704180483
5）要求使用《CMM需求规格说明书模板》作为需求说明文档。
1704180484
1704180485
（3）需求周期计划
1704180486
1704180487
对本次需求活动拟定一个时间进度表，及各阶段所需完成的内容。
1704180488
1704180489
3.需求评审计划
1704180490
1704180491
1）确定需求评审小组成员及成员要求。
1704180492
1704180493
2）确定需求评审方式。
1704180494
1704180495
3）确定需求评审内容。
1704180496
1704180497
4.需求验收方式
1704180498
1704180499
1）确定验收方式。
1704180500
1704180501
2）确定验收记录表。
1704180502
1704180503
5.需求变更管理
1704180504
1704180505
6.项目组织和资源
1704180506
1704180507
1704180508
1704180509
1704180510
精益求精：卓越的互联网产品设计与管理 2.4.2 解决方案
1704180511
1704180512
建立一套解决方案如同其他事物一样，我们要以事实为基础，以分析为导向，最终得到解决的灵感。乔布斯认为，任何公司都能建立优秀的商业模式，但是总是因为这个不行、那个不可以，使企业的事业最终夭折。这样的现象经常出现在产品管理的方方面面。很多时候我们经常因为没有足够的耐心或者畏惧去思考问题而不断地回避问题，随着问题越来越多，以至于使业务偏离了预先的计划轨迹，最终导致商业模式崩溃。
1704180513
1704180514
任何解决方案都需要以事实为基础。如果你希望成为一个卓越的高级产品管理者，你需要认识到：事实是友善的、客观的，它并不会因为你的忽略而消失，而且正是由于问题的困难，你的工作才更有挑战性，这些困难将把你同其他平庸的产品管理者彻底区分开。实际上，事实是某种可跨越的鸿沟，你的智慧和能力则是桥梁。当我们深入思考某个问题的解决方案时，经常会陷入自己的认知结构困境里面，而很多好的点子隐藏在事实背后，我们只需要加以调查和分析便可以得出。但是很多时候，由于我们对看清楚事实的畏惧而丧失了发现这些点子的机会；人生也是如此。
1704180515
1704180516
解决方案的设计主要包括3个阶段：业务目标、业务能力探索、业务过程模型设计。业务目标即是需求开发计划导入的结果；业务能力的探索可以理解为企业的技术执行能力；业务过程设计主要指针对业务目标进行业务架构设计的过程。下面我来介绍一下业务过程模型的设计思想。
1704180517
1704180518
业务过程模型设计也可以理解为业务模型设计，我们可以根据业务流程的大小来定义业务过程模型。一般情况下，各个业务流程之间总是有所关联的，而我们需要区分对待每个流程。通常情况下，细化流程是一种比较高效的、而且是迟早需要的方法。业务过程可能是手动操作或者是自动执行的业务流，它至少包括一个输入流、一个输出流。当某个业务过程较为复杂时，它极有可能是包括了多个子过程的复合过程，此时，我们同样需要使用到结构化的思想将整个复合过程进行分解和重新组合，使业务结构清晰化。Polickoff等人认为，业务结构的清晰化对项目有至关重要的影响：“缺少体系结构模型，或者开发得很糟的体系结构模型，已经常常作为项目走向灾难的一个警戒信号。”
1704180519
1704180520
案例：货币兑换系统的需求解决方案——改编于《需求分析与系统设计》
1704180521
[
上一页 ]
[ :1.704180472e+09 ]
[
下一页 ]