面向对象之软件需求中的体系构造
这里需要一种特定的思维方式与特有的方法论，正确地理解与恰当地运用经典的需求分析理论是必要的。
1．在思想方式上尽快建立起一个系统的整体框架，大体定位各种具体目标在系统框架中所处的位置及其对总体的作用，同时要分析各个部分之间的相互作用与内在 联系。在这个阶段中，往往重视交流过程而忽视真实的操作过程。实际上，通过亲临现场的走访过程来了解需求所要达到的目的往往会更快地了解命题，同时也能够 更准确地把握设计目标。
2．在总体框架的基础上，分别剖析每个应用节点上所要产生或应用的数据集合与表现方式，尽早搭建各个业务节点之间在数据体系上的内在联系，而不是单纯地从业务层面上理解应用模式。
3．仅仅是从应用的角度建立数据体系只是单向的思维方式，必要时还要从数据体系健全的角度返回来透视应用设计中是否存在缺陷。常规方式往往只是针对设计的基本要求，更多的变化将会来源于业务过程中可能发生的各种变异与特例。
4．数据应用的规律性与具体业务无关，也是审视设计方案的一个重要视角。如果能够从数据应用的普遍模式出发，就能很容易地发现原始需求中那些容易被忽视部 分。比如：在应用功能的描述中，经常会忽视查询、统计、维护、权限控制等各种辅助问题的存在，而这些功能往往是依托于某个具体应用的一种必然需求。
1.3.3.1 前瞻性
在项目交付的过程中出现继发性需求本来是一种司空见惯的现象，但这是检验需求分析质量的一个重要标准。在交付过程中，继发性需求越多，变动越大，说明需求 分析的能力与效果越差。好的需求分析正好与此相反：用户在应用初期对某些功能并不关心，当应用到一定程度之后会发现，很多新萌发的设想在系统中早已存在。
前瞻性是屏蔽继发性需求的一个重要手段，但也是消耗成本的缘由之一，关键是前瞻的方位与尺度要把握好，总体的原则是宜少不宜多，力求准确合理。能够做出合理判断的主要因素包括：
1．事物内在的必然性：比如数据统计常用的专题视角，即便用户不提也要适当考虑。
2．管理者对发展的大体思路：在系统启用后管理者可能会改变的方式、策略等，如果对行业熟悉且对决策者有所了解，在这方面会有一些潜在的需求产生。
3．业务习惯改变所带来的影响：在采用信息化手段之后有些业务模式会有所改变，在这点上要与用户切磋潜在的可能性。
类 似这样的需求在原始素材中会非常模糊，最多是一种隐约存在的感觉，但对需求人员来说，不仅要了解现在该做什么，还要知道此后必然还会做什么。准确捕捉这些 潜在的需求题材应当是一种职业修养，且要特别认真地对待。不要担心这样做会加大开发成本，只要把握适度，前期的有效投入总比事后的持续性改进划算得多。
从另外一个角度上说就是把握好合理边界。对于任何一个简单的需求如果深入解析都会衍生出一大批实物工作量，在这里并不认为需求研究越深入就会越好，关键是 适度，不要从一个误区走向另一个误区。既要有预见性也要有所节制。综合项目规律、经济成本、时间成本、人力资源现状等因素最终确定出相对合理与完善的任务 边界。
如果在前瞻性方面把握得当，将会提升项目的交付能力并缩短交付周期。
1.3.3.2 相关性
在信息系统的构造过程中，能够描述的管理过程必然会通过数据的形式存在。系统构建的过程，就是研究管理目标如何通过对数据的采集、演变、展示来达到业务目的或管理目的。数据是实现管理目标的载体，代码实现则是要解决数据管理与业务目标之间的通道与桥梁的问题。
管理目标是系统设计的表象，是数据体系外在的表现，而数据体系则是解决设计目标最本质的物理存在。研究设计目标的最终目的是形成数据并使数据能够发挥应有的作用，这是系统构造的本质所在。
数据体系应当是一个具备相关性、具备内在关联与相互制约的完整体系，它的结构完全取决于设计人员的构造，而构造的依据则是以兑现系统的设计目标为导向，它的存在形式决定了系统对业务需求的承载能力。
这是一个用户所不能涉及的层面，是源于需求又高于需求的层面。如果过于依赖原始素材，或是把原始素材当作设计目标，那么整个系统的承载能力就会带有先天不足或严重的设计缺陷。
1.3.3.3 完整性
应用系统是个有机的整体，尽管在需求调研的过程中所面对的只是不成体系的基本素材，但经过需求分析之后，将要得到的是关于完整的系统构造的综合描述。要取材于原始素材，但不局限于原始素材。要善于把各自独立的业务节点构造成一个有机联系的业务管理体系。
在一个需求报告中，如果不能就应用系统的业务模型、功能分布形成完整的体系，就应当是撰写人最大的失败。
1.3.3.4 归纳与抽象
尽管对原始素材的归纳与抽象是个必需的过程，但从中很难找到某个可以被固化下来的规律。所以，归纳与抽象是一个只能意会不能言传的方法论。
1.3.3.4.1 库存管理的样例
可以举一个通俗的例子：对于一个库房来说，只有出库、入库两个基本状态，尽管可以在业务逻辑上存在各种不同的表现方式或操作逻辑，但这种基本的库存变动模式并不会有所增加或减少。
再来分析业务模型：进货与销售是库存改变的两个基本的业务形态，而进货退回与销售属于相同的业务模型；销售退回与进货属于同一业务模型；调拨入库与进货类似；调拨出库与退进货业务类似。
依据这种抽象的结果，我们只要设计一组出入库功能就能承载所有库房管理功能，这里并不是一种说教，我们在很多系统中就是以这种抽象的模式兑现了整个项目的管理需求。
1.3.3.4.2 审批流程的样例
再举一个审批流程的设计样例。在真实的业务过程中，总是认为流程是个难以突破的设计难点。通过抽象之后可以看出，流程不过是对某些记录填写一些数据，并制定到操作该数据的下一个责任人，直至流程完结。
基于这种思想我们可以通过流程、节点的参数表来描述数据变化的历程，然后通过一个标准的流程控制界面来实现所有流程及所有节点的审理操作。在后续的章节中，可以看到这个经典方案的构思过程与实现方法。