需求方案撰写之售前方案

 需求方案撰写之售前方案

      需求素材调研与需求分析都是报告撰写的必然过程，在这里重点强调三种不同用途的需求文档在表述内容、表述方式上的差别与各自的特点。最全面的报告并不一定就是最合适的报告，尽可能采取相对简单的方式应当是基本策略，以满足特定的用途为出发点。
1.4.1  售前方案
      如果你所面对的需求分析是个相对标准的操作过程，大体上可以按照专业书籍提供的方法与步骤进行。但在中小企业的项目中，能够采取这种经典操作模式的项目并不多，所以就要研究中小企业项目过程中的需求所体现的特点与规律。
      原则上来讲，需求分析应当是在项目签约之后进行。因为软件工程是个事前很难描述清楚的命题，开发商为了适应用户的心理，经常以促成签约为目的，为用户提供一份类似于需求报告的系统构造描述性文件，其题材与撰写方式大体上与需求报告类似。
      售前方案应当是需求报告的一种应用特例，它与签约后的需求规格方案在主导思想上存在着很大差别。售前的需求报告基本上是针对用户所关心的焦点问题为中心，而对方案本身的系统性则不太关注。
      在这种情况下，需求分析人员所能支配的时间甚少、所能采取的措施不多、所能得到的素材有限，同时还要做到简明扼要切中要害，该文件的撰写水平如何很可能会关系到项目签约的成功与否。所以，能够胜任售前咨询工作的大都是经验较多、思维敏捷的高手。
      摆脱具体需求的束缚是一种境界，只有在屏蔽掉那些过于具体的事务性需求之后，才有可能尽快地从混沌的需求世界得以超脱。我们把问题从事务归结到对象就是实现归一化设计的出发点。
1.4.2  需求报告
      需求报告的目的是与用户进行沟通。它的目的主要体现在两个层面：首先是告诉用户他所投资的商品大约具备哪些功能、实现哪些预定的管理目标；其次是提供一个可以被双方认同设计任务书，明确描述任务内容与任务边界。
      软件属于无形资产，它不能像实物商品那样进行客观评价，所以事先要把无形的东西按照特定的方式表现出来，为双方沟通寻求一种可见的描述。
      需求报告基本包括以下内容：
      1．技术指标：基于实现的软硬件环境、技术手段、实现策略、部署情况等内容。
      2．术语与对象：各种专业词汇与用户角色的说明。
      3．项目主题：项目所要实现的总体目标与总体任务的边界。
      4．配合关系：双方配合的方式、进程、工作交接的界面等。
      5．主要过程：关键业务与重要节点的构思说明、实现框架、变通方案等；
      6．功能描述：对将要实现的功能描述，用例图、时序图等。
      7．数据描述：数据体系概况介绍，对很多用户来说并没有这种必要。
      8．工期进度：必要时可对工期进度做出说明。
      大体如此，其先后顺序可酌情安排，还要视用户的具体情况决定删改或增补。
1.4.2.1  框构图
      提供一些简洁明了的框图便于实现与用户的沟通。
      •    总体框图：框构图是形成整体概念最简单的表述方式，对用户来说未必十分严谨，但一定要便于用户建立起总体概念。
      •    局部框图：对用户特别关注的部分要提供简单直观的局部描述，让用户对关键的设计部位有所了解。
      •    重要构思：对于特别重要的构思，尤其是脱离了用户原始形态的抽象构思，要给出构思方案的描述，以便征得用户意见，避免出现重大偏差。
      •    专题构思：对于系统中某个特定专题的设计构思。
这方面的篇幅不宜过多，基本能够表达清楚就可以了。
1.4.2.2  用例图
      用例图是需求报告中实现功能描述最直接的手段，也是用户最容易理解的一种表达方式。它将用户的角色与功能进行关联，形象地表述用户对功能设置的各种要求。可以简单地认为这是一种把“菜单项”与“操作员”进行组合的表述方式。
      通过逐级展开的用例图，可以在功能设置与功能组织上大体建立起一个系统模型，这是用户容易理解的表述方式，也是界定任务边界的一种有效方式。
      在用例图的基础上，还要对用例图所表述的功能、约束进行必要的说明，避免造成理解上的二义性。
      由于文档是提交给用户的，在一般情况下应当尽量使用用户习惯的业务术语，尽量避免使用计算机方面的专业术语，这样可以拉近与用户的距离；再有，无论是从内容版式还是封面装订尽量做到规范美观，这是一种工作风范，也能够代表公司的形象。
      提示：这些只是需求报告的基本形式，更多的变化或更深刻的描述还要根据用户的立意、水平、关注点的变化等进行适当的调整。