写软件的 需求分析全方位考虑

需求总是在回答“需要什么”的问题，而实现总是在解决怎样才能做到的问题。需求是所要达到的目的，就是要在事先确定出到达目的地的路径与方法。为了避免误入歧途，就要避免由于需求分析误差产生的误导。
首先要明确，“分析”是一个主动思维的过程，而不是一个总结归纳的过程。很多需求调研人员认为，只要把用户提出的原始需求归纳在一起就是需求分析了，这是一个误区。
针对不同的用途，需求文档可能会表现为不同的撰写方式。
1．售前方案书：在项目签约之前为用户提供的重点功能描述。
2．需求分析报告：为项目双方约定设计任务的基本内容，限定设计任务的边界。
3．需求规格说明书：对系统的设计目标与功能体系进行相对完整的说明，在需求报告的基础上，增加对设计过程的支持与约束。
前两种方案对项目的实现过程影响不是很大，需求规格说明经常是系统架构设计所要参照的重要文件，这是将要阐述的主题。
在分析过程中经常需要注意到的问题有以下几个方面。
1.3.1 把握大局
需求起源与目的都是基于各自工作岗位的具体应用。在需求调研阶段，各个岗位上的工作人员及其相关的管理人员所能反映的情况一般是传统工作模式的翻版。每个工作岗位只是整体流程中的一个节点，该节点上所产生的数据在后续应用中会发挥哪些作用本岗位人员未必就能明了。这种存在与岗位流程之间的内在联系，才是我们需要真正了解的重要元素。
这种需求描述的局限性是显而易见的，尤其是在管理水平相对较低的企业中，这种缺陷所带来的危害就会更加突出。如果仅是依赖这些带有先天不足的素材来构造系统的设计目标，最终落入被用户导引的误区也应当是一种很自然的结局，这当然不是我们所希望的结局。
需求分析的过程就是要通过系统化构思把各岗位上的需求联系起来，这是系统构造的关键所在。我们必须从一开始就要站在总揽全局的高度去俯视每个具体岗位上的具体需求，要对每个具体需求在整个系统中所处的环境、所要达到的目标等问题进行追踪分析。如果我们总是能够通过表面现象找到管理流程在系统分析过程中所存在的断点或盲区，就有可能屏蔽掉原始素材中所存在的那些先天缺陷。
管理过程是个完整的体系，需求素材只是管理在各个业务岗位上的具体反映。通过堆砌素材的方式只能反映事务的表面现象，并不能全面准确地体现出真实的管理目标整体。所以我们需要通过素材来了解项目的具体内涵，素材只是理解管理目标的一个途径，绝不能把用户描述的需求当作设计实现的真实目标。
在充分认识并基本理解管理目标之后，应当形成一个系统构造的总体目标与实现的框架，然后再回过头来探查每个具体实现的合理性与必要性，这就很容易发现原始素材的缺陷与盲点，这将会有助于我们更快速、更准确地接近所要实现的真实目标，从而减少由于素材粗糙而带来的影响。
提示：这里所提倡的整体观、大局观是个最基本的方法论，实事求是对需求分析来说，经常会导致一叶障目的结局。要把所有需求汇聚到一个能够承载用户业务的系统框架，然后再研究各种功能在此框架中的位置与作用，只有在总体框架健全的机制下，才有可能为具体功能的实现提供具有可行性的具体方案。
1.3.2 掌握规律
从通用概念上来说，管理信息系统的宗旨就是要把管理目标的实现过程与实现策略通过数据的方式进行采集、描述与映射。这种基本概念并不会因为行业或项目的不同而有所差别。这是一个似乎没有实际意义的说法，但这确实是一个具有普遍意义的说法，也是需求分析过程中要随时注意到的一个说法。
我们可以从几个特定的角度来分析一下规律性的具体内涵：
1．行业：相同的行业具备大体相同的管理模式与运作模式。
2．专业：在不同的行业中相同的专业具有大体相同的业务内容。
3．流程：在行业与专业不同的情况下，业务管理的流程与模式有可能相同。
4．操作：各种不同的应用系统在操作逻辑上具备相同或类似的方式。
5．事务：无论系统的目标如何，总是由事务构成的，相同的事务在各种企业行为中具有基本相同的实现方式与实现途径。
在需求分析的过程中，借鉴或遵循这些在广义上普遍存在的规律是个最简单有效的捷径，然后才是个性化问题。如果仅仅是面对用户的需求素材苦苦构思，那只是个舍本求末的分析方式。
在映射到信息管理系统的时候，很多规律代表了普遍性的存在，其中兼容性与可重复性的比例要比具体业务的个性化成分多得多，认识并善于应用这些规律是快速构造需求方案的基本素质。这是思想方法层面的问题。
1.3.2.1 内在规律
迅速找到本质的管理目标是一个重要的方法论。比如：在项目过程中，一般会把商品管理与资金管理分布在不同的岗位上，但事情的本质是：任何商品的增减变化，都会必然地影响到库存资本、往来账务等一系列的数据变化，因为从本质上说，商品与资本完全是同一事物相对不同视角的表象差别，而绝对不能认为它们是两个可以独立的业务形态。
这就是事务的本质与内在关系不会由于企业不同、管理观念不同而有所差别的原因。它们在任何企业中都会具有相同的表现方式与表现逻辑。尽管生产企业与流通企业在管理过程上差别甚大，但对于这一类问题的处置方式则完全相同。在这种情况下，我们首先要以事务内在的规律性作为设计的基点，并在此基础之上研究用户的个性化部分。尽管用户需求可能会存在这样或那样的缺陷，但只要我们把握好事务内在的规律性，仍然有把握设计出性能完备的应用系统。如果追随用户所给出的具体需求而背离事务内在的本质，在应用中必然会出现问题。
1.3.2.2 数据规律
绝大多数管理信息系统不过是数据采集与数据表现的实现过程，尽管数据挖掘与决策支持的概念被广泛倡导，但真正能够实现的企业只不过是凤毛麟角。所以说，就一般概念上的管理信息系统而言，不过是相对简单的数据采集与展示体系。
如果基于这样的数据层面考虑，就能从各种管理信息系统的设计过程中发现最本质的内在规律与最基本的共性。在各种管理需求的实现过程中，数据处理基本可以分为5种基本的形态：
1．采集：包括增删改等基本维护。
2．衍生：从某个记录派生出一个新的记录，经过处理后得到新记录。
3．填充：根据业务过程需要在某记录上补充部分数据。
4．查询：得到某个特定条件的数据集合，包括简单的聚合、统计。
5．分析：依据某个管理目标对数据进行相关统计、对比。
在数据层面上，只有通过相对标准的方案对数据进行上述模式的处理，才能基本覆盖管理信息系统的全部应用过程。
以下是三个关键的步骤：
1．数据规律：通过标准的数据处置统筹解决基本命题。
2．需求规律：通过标准的控制方式统筹解决数据与业务之间的接口方案。
3．实现规律：解决把标准设计兑现成具体需求的实现手段。
本设计在数据层面上始终是围绕着这些基本问题进行的。
1.3.2.3 物理表规律
数据在具体应用中也有一些可以遵循的规律。比如：对任何一个物理表来说，数据录入与数据展示方面一般具有可以复用的模式。比如：原始录入、数据卡片、数据维护、数据导入等可被复用的模式。这些模式对项目内容并不敏感，只要改变数据源的指向，就能适应很多项目的设计实现。
物理表的具体用途也有一些规律，比如：
• 参数表：为了达到功能方面的适应性而设计的物理表。这些数据一般由系统管理员或重要的业务责任人来管理，它会影响到相关功能的具体表现。
• 词汇表：也被称为字典表，主要解决数据标准化、规范化并支持快捷录入等方面的问题。特点是字段少、引用频繁。
• 档案表：系统应用所必须依托的基础数据表，特点是覆盖一个专题的概念（如法人、物资、库房等）要形成完备的体系，调用频繁、经常需要维护。
• 业务表：用于记载业务过程与管理过程的物理表，在物理表的数量上会根据业务的复杂程度而增加，在各表中的记录会随着历史过程而增加。录入过程将会体现出用户的管理目标与操作逻辑。
对于相同类型的物理表，在功能、录入、展示等方面都有着类似的设计模式。从这个角度便于实现对设计任务的分类。
1.3.2.4 权限规律
在应用系统中的权限管理大约可以归纳为三种方式：
• 数据权限：针对数据字段进行授权管理及权限实现。
• 功能授权：对菜单、热键、快捷键、工具栏菜单等各种能够启动功能界面的途径上实现功能授权管理及权限实现。
• 控件授权：在功能界面之中，有些控件（如按钮、文本框等）进行授权管理及权限实现。
其中，
 授权管理：为权限管理规则定义方案的过程。
 权限实现：根据权限管理规则实现对各个授权角色的具体实现。
1.3.2.5 操作规律
在操作逻辑方面，针对每个功能所面对的实现目标与操作员，设计实现的方案也会有所差别。其大体的规律性可以归结为：
• 数据录入（采集）：一般会偏重于键盘操作或自动化数据采集设备的应用，尤其是录入工作量繁重的应用系统更是如此。这部分功能往往是大批的业务岗位使用，其对录入速度与简便性方面的关心程度是首要的目标，虽然对鼠标的支持不能忽略，但重点一般不在于此，主要是因为鼠标操作将会对录入效率产生极大的负面影响。
• 查询统计：一般会偏重于使用鼠标的操作逻辑，因为操作这些功能的大多数是管理人员，他们对键盘操作逻辑的关心远远小于录入人员，但仍然要通过键盘解决那些复杂条件的录入问题，这是键盘与鼠标同等重要的业务模式。
• 综合分析：对于综合分析功能的设计要基本屏蔽掉键盘操作，因为操作这些功能的一般是重要的管理者或决策者，他们需要通过最简单的方式得到结果。
用户需求一般不会详尽到如此细致的操作逻辑，但也决定了实现设计对操作逻辑方面也难以做到详尽准确。如果能够从一般规律上对此有所把握，无疑会更加真实贴切地实现用户需求。
对于有过海量数据录入经验的程序员，这些设计理念与实现手段是自然形成的设计习惯；而对于那些没有数据录入经验的程序员，一般会经历与用户之间多次的往复磨合，才有可能接近用户的实际要求。
1.3.2.6 界面规律
界面设计也有一些可以被复用的经典样式。对于一个物理表或数据集来说，录入或展示的主要模式有两种：对于数据集我们基本上是使用数据表格的方式，对于单一记录我们更希望使用卡片的方式。所谓的卡片是指：以单一字段的数据控件为基础，在一个区域（或页面）内完整实现对某个物理表及相关数据的综合录入或展示。
尽管界面设计存在各种变化，但我们可以对基本模式进行抽象、归纳，然后再进行分类、定制，最终形成相对标准的设计样式或应用模板，此时，很多雷同的设计模式就能通过样式引用的方式进行描述，既简单又准确。
比如我们可以规定一些常用的页面样式：
• 单表数据卡片：针对单一表格的数据卡片，这是最基础的设计方式。
• 单表表格+卡片：把数据集与卡片组合起来，便于对表格数据的综合管理。
• 主从式表格+卡片：把相关表的数据组合在一起，给出某个应用的完整状态。
• 单表查询：基于某个物理表的动态查询或静态查询，这是数据展示的基础。
• 主从式数据查询：关联多表的数据查询。
• 查询结果的主从式归纳：将数据查询结果进行分组归纳并形成主从关系。
这些不过是形象的列举，实际中可能是更多、更复杂的形态。界面的规律会基于某个特定的角度，视角的变化将会影响到界面分类的改变。假设我们能够把很多的应用功能与规定的界面模式相联系，那么描述页面设计将会被有效简化。
1.3.2.7 规律与粒度
规律性的存在与否往往与研究对象的粒度密切相关。一般来说，粒度越大规律性就越差；粒度越小其存在规律性的可能性就越大。在需求分析的过程中，要特别注意规律性与粒度之间的辩证关系，尤其是在对待复杂问题的分析过程中，如果能够从某个粒度合理的层面上得到我们所谋求的规律性，那就是找到了一扇通向成功的大门。
如果从系统构成的角度上来看，系统登录、菜单管理、行政机构管理、操作员身份管理等都可以认为是具有规律性的功能；如果把粒度降解到方法级就会发现在数据存储、操作逻辑的层面上仍然具有一定的规律性，继续降解到控件级就会发现更低层次上的规律性会表现得更多一些。
其实“对象”的本身就是一种规律性的具体表现方式。