面向客户的版本分解方法，其目的是以最快的速度为客户提供最需要的可用的软件产品，其基本策略是在严格控制各版本软件工程过程的前提下，通过缩小版本规模尽量将交付时间提前，从而更早的获得反馈，更早的完善重要功能。

　　进行版本分解要考虑的因素主要有：客户需求的迫切程度、软件产品推广实施难度、客户接受能力、在整个系统中基础地位、开发的难度以及成本因素、环境因素、行政约束等。

　　客户需求的迫切程度是最主要的因素，但客户的需求一般在初期阶段不一定是很明确或很正确的，需要需求调查人员的引导和与系统设计人员的沟通。在实施效果上要使客户满意，最主要的是使软件产品尽量对客户或最终使用者来说容易接受，因此应该选择比较成熟、有丰富的实施经验、与现有工作方式接近的功能模块来定义版本，进行循序渐进、简单易学的功能设计；容易通过行政指令制定和强制执行、可操作性较强的功能模块，实施的难度也相对小一些；如果客户在某方面接受的教育培训较多、较成功，在思想意识上有较充分的准备，也是该版本功能设计容易接受的重要基础。

　　版本功能的客户需求越迫切、越容易被使用者接受、实施难度越小，则该版本的开发设计优先级越高，交付期应该越早。当然系统体系结构上的限制使一些基础性的功能必须提前开发，这需要与客户进行沟通协商。系统体系结构的设计必须充分考虑灵活性，有时为了重要功能的早日交付体系结构可以做出必要的牺牲。

　　首先，必须在需求调查的基础上，先建立一个整个系统的框架，这与一般的瀑布式开发过程步骤相似，但需求调查的目的和系统设计的详细程度不同。这里，需求调查是为系统体系结构的设计服务，而不是包罗万象的全面调查，因此，这时需求调查的主要工作不是了解微观的业务流程，而是对系统的各个功能需求的重要性、迫切性、不确定性、复杂性、相关性等进行评估，明确优先级，尽早发现配置实施中的风险。体系结构的设计具备战略性和规范性的特点，主要规定版本演进的方向、设计开发的平台、公共接口和基本的设计规范等，而不必深入到每个模块的具体设计方案。

　　在整体框架确定后，按照功能模块的优先级、相关性进行初步的分解和排序，各个版本在交付时间上可以是串行的或是并行的，每一版本的规模被限制在1~3周的开发周期内，也就是在1~3周时间内要完成该版本软件的详细需求调查、设计、编码、测试和配置交付的全过程，这样一来，对该版本的功能定义必须限制在很小的范围内。对于什么功能必须优先提供，决定权在客户。而对开发周期的估算，决定权在开发人员。如果客户提出的功能要求不能在一个版本内完成，客户与开发人员必须通过协商，对该版本的功能定义进行进一步的细分。

　　如果在开发过程中发现一个版本可能不能在规定开发周期内交付，则采用适当延长时间、削减次要功能或者取消该版本的方法使版本结束的时间不要超出计划时间过多。但是必须注意，不能为及时交付而跳过必要的开发阶段，如需求调查和测试。开发中产生的新需求和新设想将作为未来版本的新特性，当前版本计划的严肃性必须得到保证。

　　每个版本的交付都是一个严肃的过程，用户的使用是对产品的最终检验。为了保证用户的正常使用，完整的配置服务和相应的培训工作必须同时进行，由于软件功能有限，培训的规模也相应的缩减，培训可以是正式的或非正式的，配置人员和培训人员还兼有及时反馈用户使用情况的责任。

　　一个版本交付后，不应立刻开始升级版本的设计，而应该至少间隔１周的时间保证能够得到使用者的反馈意见。根据客户的反馈情况来决定完善该版本、开发升级版本还是在这项功能基本满足客户需要的情况下开发客户更迫切想要得到的其他功能。