需求与设计的界线

需求与设计的区别究竟是什么？ 教科书上的经典答案是：需求关注系统“做什么”，设计关注“如何做”，其实这是一个很模糊的说法。


无论是在结构化方法中还是在面向对象的方法中，需求分析的结果既包括了“做什么”也部分包括了“如何做”，只不过描述“如何做”时抽象的层次比较高或者描述了某个局部需求的“如何做”。客户在提出系统需求时，可能对“如何做”提出一些约束条件，比如客户要求必须采用三层结构，必须采用某个中间件等等。在需求描述文档中，一般称为“设计约束”。开发人员进行需求分析后的结果包括了系统构成元素（无论是称为模块还是称为包）的分解，包括了数据流程图或类图等，这实际上也是在定义系统“如何做”，只不过这里描述的“如何做”应是从客户的角度比较容易理解的。


在需求中包括了：
Ø 系统的目标、范围以及与外部的接口；
Ø 系统的功能、操作流程、处理规则；
Ø 系统处理的数据，数据有属性，数据之间有关系，这些数据可以解释为实体或者类；
Ø 对于系统可以划分为子系统，子系统中再分为模块，子系统、模块只是对系统功能进行分类的一种方法；
Ø 系统的设计约束；
Ø 系统的运行环境等。
另外在需求中还包括了：
Ø 子系统或模块之间的接口关系；


这一部分往往是和设计有交叉的，系统分解为子系统、模块，以及他们之间的接口关系在概要设计中往往也是涉及到的。在需求中对系统的分解是从功能的角度，是从逻辑分类的角度进行系统的拆分，而在设计时对系统的拆分是从实现的角度，比如在设计时将系统分为界面层、中间层、数据层。


在需求中尽量不描述“如何做”实际上是避免对设计进行太多的约束与假设，这样会限制设计方案的选择。设计可以认为是一种决策行为，是一种选择行为。需求确定以后，解决的方案可能有多种，如果在需求里描述了“如何做”，实际上就限制了设计只能选择某一种方案，而这种解决方案却很可能不是最优的。所谓的解决方案可针对整个系统，也可能针对某个具体的功能。


原则上“做什么”是由客户提出来，由系统分析人员进行文档化，“如何做”是由开发人员来确定的并进行文档化。


“做什么”与“如何做”在现实中是实际上是迭代进行，交织在一起的。在项目立项之前进行的可行性分析，包括了系统目标与范围的确定，包括了技术路线的论证，包括了成本、风险、进度的估算等等，在上述的行为中，包括了简单的需求与设计。在项目立项之后，采集了客户需求，进行需求分析，然后考虑系统的解决方案，此时还可能需要修改或增加需求。二者交叉或并行执行。


在需求和设计之间划一条明确的界线其实很难，理解了二者的根本区别，企业可以自己硬性地规定一条界线：即哪些内容在需求中描述，哪些内容在设计中描述。