结构化设计——需求

    一般情况情况下，在谈到需求的时候我们都认为他只有一个阶段，即需求分析。但实际而言，就需求的处理过程而言，它应当被分为三个相互关联的阶段，即需求调研、需求分析与需求设计。而这也符合我们做事的一贯逻辑思维，即先有调查，才能分析，最后才能根据分析得出需求阶段的成果，即需求设计。这样，做需求时，我们才知道自己处在需求的什么阶段，应该做什么，每个阶段应该有什么样的成果，否则，就像我曾经做需求一样，报告出了一个又一个，原型出了一个又一个，而最后的系统还得一改再改。下面就这个三个方面谈谈具体的实施过程。

一、需求调研
    我们知道，在需求分析之前还有一个阶段叫“可行性分析”，在这个阶段，我们就开始做需求调研了，那在需求阶段还需要再做需求调研吗？不错，在正式的项目开始的之前，我们对于项目就已经有一个评估了，而要做这个评估，则必须对整个项目有一个基本的调研，但这个调研也只是基本的而已，因为我们不可能投入太多的成本去对一个可能要做的系统做全面的估计，这就好比我们对于一个真正的敌人和一个假想敌的态度和投入是完全不一样的一样。
    那么需求调研，我们需求做些什么呢？
    产出：
   

引用

1.需求报告：
        1>.系统边界：即功能需求,包括详细的业务逻辑。这是建立业务流程图，系统流程图，系统状态图，数据流图，及至搭建整个系统，防止需求放大的基础，所以清晰地定义系统边界，详细准确地叙述业务功能至关重要。
        2>.性能需求：系统响应速度/并发量/稳定性/安全性/系统容量（用户，数据等）
        3>.可靠性与可用性要求：系统可靠性建立在系统可用性基础之上，是系统的可用时间与不可用时间之间的比值。
        4>.错误处理：针对系统出现的系统错误，逻辑错误，操作错误，系统应当如何处理。
        5>.约束：业务约束，物理约束（服务器约束，网络约束），开发约束（开发语言，Server容器，开发工具等）
        6>.接口需求：包括用户接口，硬件接口，软件接口，通信接口等，此处的接口即为通信格式标准，如用户接口，即与用户通信时的格式标准，也即客户端显示标准。
        7>.逆向需求：说明软件不应该做什么，一般专注于重要或易发生误解的部分。
        8>.可扩展性要求：说明系统将来的可能需求，以在系统设计时做专门考虑。
        9>.易维护性相关要求：系统维护部分的特殊需求，如日志，错误报告等。
2.层次方框图：描述系统的功能模型，包括系统的主要业务功能架构，即模块结构。
3.业务流程图：专注于业务逻辑调研，描述客户的业务逻辑过程。可参看http://www.hi-blue.com/gb/products/erp_flow.htm。
4.用例图及用例说明：用例图和用例说明在需求调研阶段一般针对比较复杂的业务逻辑，确定业务的逻辑过程，前置条件，后置条件，处理过程等。
5.IPO图（IPO表）：IPO图与用例描述的功能类似，他关注的输入/输出/处理过程。一般用于针对复杂模块进行说明。

    从需求的三个模型（数据模型，功能模型，行为模型）的角度来说，上面的5个输出并不是全部都需要的，只不过为了能够使需求尽可能的准确，详细，我们需要在恰当的地方使用使用恰当的方法，比如说，系统A可能只有一个模块比较复杂，那么，我们可能只在这个模块使用了业务流程图及用命图。总之，一切是为了说明需求。

二、需求分析
    需求调研是为了让我们对客户要做的系统有一个整体的了解，是一个听的过程。接下来，我们便需求整理我们所听到的信息，是一思考的过程。在这个过程中，我们需要完成以下几个方面：
   

引用

1.分析系统功能关系，为建立系统流程图做准备
2.分析系统数据流动关系，为建立功能模型（数据流程图）做准备
3.分析业务逻辑，为建立行为模型（状态图）做准备
4.分析系统数据关系，为建立数据模型（E-R图）做准备

三、需求设计
    需求设计则表现为一个反馈的过程，他建立在思考的基础之上，在对需求调研的产出进行整理之后，我们应当得出以下几个方面：
   

引用

1.原型，无论采用什么设计方法，原型都是最好的需求工具。原型作为最接近真实的用户接口的替代品当然赿真实赿好。因为信息接受的阶段性，我们可能会需要做几次原型的迭代，最开始的原型可以简单一些，因为它本身的失真性比较高，但最后的原型应当是最接近用户接口的成品。需求设计人员应当谨记一句话：用户很多时候也不知道他想要的是什么，只是在你拿出来的时候，他突然就有了灵感，知道你的东西与他想要的有多少差距。
2.层次方框图（或系统边界图），我一直认为这个图应该在贯穿系统设计与开发的始终，因为它可以让系统参与人员对系统愿景有一个整体的了解。
3.系统流程图，这个图用作与用户进行最后的反馈确认比较有用。参考：http://www.pc30.com/xtlct/xtlct.htm。
4.数据流程图，逐层精细的数据流程图对于与用户的细节沟通是非常重要的，对于后期开发也有很大的指导作用。参考：http://zk.educity.cn/rjgc/200608311656531370.htm。
5.状态图，这是一个行为逻辑说明，方便后面建立程序流程图。
6.E-R图，这是数据库设计的基础。
7.需求描述（BRD），如果可以，最好能够提供软件需求规格说明（SRS）,它们综合了系统边界，逻辑和UI，是图文文件，也是总体设计与详细设计的基础文件。

    所以，在与客户进行最后反馈确认的时候，请一定准备好这7份东西，并对上面的东西做一一确认。

四、小结
    需求的三个过程并非一个绝对的顺序过程，其每个阶段也不是一次就位的，需求本身也不是一次性过程，它是三个阶段的循环迭代，嵌套，就好比一个交流的过程，先听，再思考，然后反馈，而听你可能没听清，要重复的听，思考要思考好几次，说也可能一次不能表达清楚，需要不停的循环，直到双方达成共识。为了做好需求，我们可能在需求调研阶段针对某些复杂的业务功能直接进行好几次的分析、设计，直到真正理解客户的需求。
    总之，理解需求，并正确的反应到需求设计中才是整个需求的目的，方法的选择和使用都是次要的。



------------------------------------------------


最后，再PS一点数据流程图与系统流程图之间的区别：
1.数据流程图：数据流程图（DFD）是在系统分析员在系统设计阶段（这里是指数据流图主要发挥作用应该是在系统设计阶段，我个人认为，数据流程图确实就应该在需求设计阶段已经产生了，并为系统设计阶段提供指导），对实际构建的系统分析综合后，提取逻辑模型的一个过程，它更关注于过程内数据的处理，而把具体处理数据的物理过程，物理分布忽略，而系统流程图则更关心这个。
2.系统流程图：系统流程图是在系统分析员在做系统构架阶段，或者说，在接触实际系统时，对未来构建的信息处理系统的一种描述。这种描述是相对简单且完全的，涉及到未来系统中使用的处理部件，如磁盘，显示器，用户输入以及处理过程的先后顺序表示等，标准的系统流程图应该有10种图元，具体的有国家标准。当然，系统流程图还可以用来表示现有的信息系统处理过程涉及的各个部件以及次序。系统流程图是描绘物理系统的传统工具.它的基本思想是用图形符号以黑盒子形式描述系统里面的每个部件(程序,文件,数据库,表格,人工过程等等).系统流程图表达的是信息在系统各部件之间流动的情况,而不是对信息进行加工处理的控制过程，这一点相对于数据流图，它的粒度更粗，反应的层次更高，主要集中在系统硬件这一级，而数据流程图则更加关注软件的逻辑单元之间的数据流动。