需求是业务的描述,设计是业务的实现。而这样就又扯出来一个概念,什么是“业务”?我们很常见的业务比如电子政务的业务,公文传输、电子签章,这都是业务;那么当我们面对软件开发这个领域的时候,什么是“业务”?编写代码、提取构建就是业务;当我们面临中间件领域的时候,什么是业务?提供接口、提供服务环境,这就是业务。可能大家并没有参加过之前一次有关安全中间件需求、设计评审的工作,有机会我会将那次的文档转发给各位来了解一下,在当时的需求分析、概要设计和详细设计中,描述了完全一样的内容,而绝大多数人的理解(对于概要设计和详细设计)就是,详细设计就是把概要设计用10个字说明的事情改用100个字说明,而我相信这是个错误。需求分析了业务,概要设计描述了实现途径,详细设计描述了代码结构(这里是代码结构,而不是程序结构)。 可能有些晦涩,那么举一个简单的例子,在后续章节中提到一个通讯接口的问题,里面提出了一个概念“通讯协议”。通讯协议只有在开发的过程中才会使用,那么为什么要在需求文档里提出呢?比如我们采用基于HTTP的web service,那么通讯协议是什么?两个层面:传输层面采用了HTTP,数据持久层面采用了SOAP,而HTTP和SOAP已经规定了详细的数据通讯方式,这是一个基础的业务需求,我们用什么做什么事。我们用HTTP和SOAP去做基于HTTP规则的web service通讯。回过头再来看我们的需求分析文档中的内容,我想我在尽量尝试用这个原则去知道需求分析的编写过程,我们面向的业务范畴不同,需求分析内容就不同,并不是出现了代码结构、出现了软件接口,这就变成了设计文档,比如中间产品,他的功能需求就是提供软件接口。
什么是需求,什么事设计?
最新推荐文章于 2024-11-09 14:41:27 发布