本文是我依据负责的两个物流管理信息系统项目的基本设计中的经验总结出来的，加上我参加过的几个项目中别人的设计书中学习到内容，希望对看的人在设计上有所帮助。
基本设计的定位是在概要的初步需求了解后，按照需求对系统做初步的设计。
基本设计书是衔接需求阶段与设计阶段的最重要的文档，既用于对需求的进一步明确的沟通材料、又作为对后续设计担当者的框架性设计指导与限制的材料。 好的基本设计控制住了项目的设计风险，也保证了后续设计开发的质量基础。
做基本设计，在理解需求的基础上，有两点很重要，1是写好基本设计书，2是很好地发表（内部审查时发表获取修改意见，跟用户沟通时发表获得方案的通过与获取在项目实施过程中的支持）
基本设计书写好后，一般都要先在公司内部邀请各方面相关的技术人员、领导分别从商务、技术、业务设计、硬件网络环境、风险等方面进行审查。确定设计方案可行后，再跟用户进行报告或沟通1到3次，对用户提出的修改需求进行改善，细化重点的管理项目。 为追求质量，一个中小型的基本设计书到最终版修改5，6次很正常。
现在开始讲怎样写好基本设计书
信息管理系统的实施都是为了解决客户的某个或少数几个核心的业务问题，提高业务品质或效率，或降低成本等。 所以设计要盯着要解决的核心问题，简单并准确地定位出系统的目的和期待效果。然后紧紧地围绕该目的展开业务流程和功能等的概要设计。
初步写基本设计时，最好找到并多看几份好的类似项目的设计书，利用其框架来填写自己的设计书。
下面是我负责过的一个小项目的基本设计的目录。接下来我会按照这个目录详细展开写需要知道的注意事项和要点。并给出一个删减版的简要例子（斜体部分）。
0、 企业现状、问题及系统实施背景
１、系统实施的目的及效果
２、系统范围、用户规模
３、业务流程设计
２、系统范围、用户规模
３、业务流程设计
４、系统概要功能
５、画面设计（例）
６、环境（硬件/网络/软件）
７、系统实施组织
８、系统开发大日程
９、系统开发费用概算
６、环境（硬件/网络/软件）
７、系统实施组织
８、系统开发大日程
９、系统开发费用概算
１、系统实施的目的及效果
目的和效果其实是用户提出的，我们只是帮其提炼文档化出来。要点是目的要清晰、准确，期待效果要能让用户感知对其企业产生的效益（有时可以用钱来衡量，而且这钱一定是数倍于软件系统的开发实施费用，否则系统项目也无法成立）。
目的：
和现有的****系统整合，将订单功能向经销商延伸。
扩展支持范围，成为***公司各成车部门的综合订单系统。
经销商可以网上下订单、查询订单、产品、库存信息；
上传和查询三包信息。上传经销商库存信息。
扩展支持范围，成为***公司各成车部门的综合订单系统。
经销商可以网上下订单、查询订单、产品、库存信息；
上传和查询三包信息。上传经销商库存信息。
期待效果：
加大对经销商的支持力度，使其可以及时了解产品、库存信息。
支持经销商直接网上下单，削减作业时间，减少***公司的工作量。
及时收集并活用客户三包信息。
支持经销商直接网上下单，削减作业时间，减少***公司的工作量。
及时收集并活用客户三包信息。
２、系统范围、用户规模
系统范围明确它在企业业务流中的定位、跟企业别的系统的分工，系统做什么，不做什么。
如果站在客户企业的较高的管理角度看，我们为他实施的系统只是其管理系统中的一小部分，如果他原来就有系统，则可明确与旧系统的关系，而有些管理领域则可能不远的将来也会实施系统，站在比较宏观的角度描述出系统的定位有助于挖掘本次项目以外的将来的系统实施机会，也能体现我们写出的设计是全局的解决方案。
写系统做什么要按层次，将要实现的功能用几个简单的分类描述清楚。(接近于模块名)
写出系统不做什么有助于降低项目的需求膨胀风险。
经销商范围：
总代理、1级经销商（不涉及2级及以下经销商）
商品范围：
****
库存管理：
不涉及经销商库存
业务模块：
订单管理
订单信息追踪管理
***
总代理、1级经销商（不涉及2级及以下经销商）
商品范围：
****
库存管理：
不涉及经销商库存
业务模块：
订单管理
订单信息追踪管理
***
|
用户数
|
2008年
|
2009年导入
初期用户数
|
导入后半年
想定用户数
|
导入后3年
想定用户数
|
最大想定
用户数
|
|
**部
|
40
|
3
|
40
|
60
|
150
|
|
**事业部
|
280
|
3
|
300
|
500
|
700
|
|
合计
|
|
|
|
|
|
同样的方式设计另一个表格也可以明确系统核心信息的规模，比如订单数等。为后面的系统性能设计做准备。
３、业务流程设计
这里摘录一段对流程的解释。
流程其实就是“工作流转的过程”的缩写，这些工作需要多个部门、多个岗位的参与和配合，这些部门、岗位之间会有工作的承接、流转，因此流程也可以说是“跨部门、跨岗位工作流转的过程”。
基本设计是要给用户看，跟用户沟通的。而流程图恐怕是最好的和用户沟通的文档工具了。 我们要用用户看得懂的流程图描述出用户的业务管理流程。在该流程中明确我们的系统是如何与用户互动实现信息的流通和管理控制的。下面先看个例子。
流程例：经销商订单流程
流程图的纵向用各个部门分隔，表达部门之间的交互， 横向从左到右表示时间的推移，表达各动作的先后顺序。在各个动作的旁边，可以在与用户沟通的时候把讨论出的要点记录下来。
４、系统概要功能
把系统的功能按模块-功能的层次方式列出来（功能构造图）。
订单管理
订单输入
订单审核
订单信息追踪管理
产品库存查询
订单查询
...
订单输入
订单审核
订单信息追踪管理
产品库存查询
订单查询
...
将主要功能的画面初步设计画好。
６、环境（硬件/网络/软件）
硬件和网络的方案要按系统生命周期整体考虑， 根据用户规模及业务规模在几年内可能达到的最大可能负荷来设计。并且考虑客户企业未来数年内可能会增加的其他系统。因为目前技术支持硬件统合。在采用的技术有统一性的情况下，统合的硬件环境可以降低用户的总成本，也可降低维护费用。 这需要帮客户做好系统规划。
另一方面，充分考虑利用用户现有的设施，共用服务器、防火墙、带宽等。
投资上金额比较大的话，可以考虑分期投入，特别是带宽等与系统业务规模有较大关联关系的部分。在前期业务量比较小的期间只投入较小的带宽。
对于比较小的企业， 可以考虑租用空间和服务器托管。
网络安全是十分重要有很敏感的，所以要设计好各级防火墙与服务器的构造，内网与外网的分开，业务系统与网站系统的分开，与财务等内部系统的隔离等要明确。
另外，密码登录管理方式，数据加密方式也要明确。一般性的业务系统可以采用SSL服务器端的数据加密方式。 具有很重要的安全性的系统则可用服务器及客户端两方都控制的SSL认证数据加密，但这种客户端认证加密的数字证书由于收费以客户端数为单位收取，所以几千以上客户端的系统的话费用就很可观，要仔细衡量。
７、系统实施组织
系统按计划开发完成了，不一定项目就能实施成功。系统的实施与客户的参与度有密切的关系。
系统按计划开发完成了，不一定项目就能实施成功。系统的实施与客户的参与度有密切的关系。
业务的设计，基本设计的确认，用户教育，系统初始数据的整理等系统开发以外的工作大大地影响系统的质量，而影响力最大的是客户的管理层。
所以，项目的实施组织图上，一定不要忘了把客户的管理层卷入进来。即不要把项目只看成是系统设计开发的项目，而是客户企业管理提升的一个项目。 一般客户的经理作为项目的总负责人，客户的关联部门甚至客户的客户作为利益攸关者，以客户的主要参与者和本公司的项目经理组成项目推进团队， 再组成系统开发团队，进度管理团队，系统实施团队。
８、系统开发大日程
系统开发计划也要把用户的实施计划与我们的系统开发计划同时考虑。用横道图形象地把计划表达出来。
系统开发计划也要把用户的实施计划与我们的系统开发计划同时考虑。用横道图形象地把计划表达出来。
请参考下例。
９、系统开发费用概算
按一次性费用，运行维护费用分开，软件费用和硬件费用分开的分类方式表达清楚。
需要注意的是软件版权费要考虑清楚用户数等的关系。
以上讲完了基本设计书的写法。 要做好基本设计，还要会与客户的沟通技巧，演讲说明能力等。 以上各个部分
内容相关又有各种的技巧和方法论。 比如业务流程图的画法等。 这些部分以后再另写文章详细说明。
郑福根个人日志搬家。。。
补：
最近工作中，基本设计的后期阶段的界面设计部分，尝试采用【用户所见即所得】的方式进行沟通，效果不错，
简单而言，就是用10%-20%左右的成本， 先将与最终系统相比高仿真的界面做出来，让用户看，模拟使用，再提出修改意见。
BS项目的话，采用HTML静态页面，加上一些基本的动态的脚本语言来实现一些跳转，条件切换等关键流程。（有空再展开）
郑福根日志搬家，给看了有用的人看。