浅谈三大文档-需求、概要及详细

当然,初期软件的架构非常重要了。然而无论在软件设计之初,还是在软件的使用过程中,维护过程中,项目经理级别的人物交流等等,等等都离不开的,就是文档。
说到文档,就必须得说需求、概要、详细三大文档。俗话说:万事开头难,这需求分析文档,就是该系统的头儿,它主要解决“做什么”的问题。需求分析时,系统分析员和软件工程师对客户的需求进行充分理解,然后把业务需求理解整理成文档。该文档便供架构师对该系统进行架构,包括后续的画UML图,编写概要设计文档和详细设计文档。
个人认为,需求分析文档中可以有用例描述。用例描述,是用户与开发人员之间最好的语言,一般情况下,开发人员很难向听出来用户想要什么系统,而用户用自己的语言描述半天也表述不清自己要的是啥。而用例图能够使他们两者达成共识。
       
需求分析里面,还应该放置用户特点。俗话说:知己知彼,百战百胜。只有知道了用户的特点,才能对症下药,制定出符合他们的需求系统。

当然需求里面也需要放一些其他的东西,比如关于性能描述,非功能性要求等等,这里不多少说,大家可以去百科里面查。下面说概要。

那么,什么是概要设计文档,写完之后又要给谁看呢?

个人认为,概要设计文档的编写就是要根据需求文档的要求,把系统具体化。将系统的功能进行模块划分,建立模块的层次结构调用关系、确定模块之间的接口和人机界面等等。

那么概要设计文档完成后要给谁看呢?经过昨天激励的讨论,大家一定都知道了。首先,概要设计首先要给项目经理级别的人看的,他通过该文档能够了解该系统的 全局以及该系统的特色和亮点。然后,概要设计也可以拿给用户看,用户经过简单的培训,大体上读懂文档应该没有问题,他们能够通过该文档了解到这的系统是不 是他们所需要的系统;再然后,概要设计还可以起到唬人的作用。比如公司之间外包项目,可以拿概要设计文档对自己项目的两点和难点吹嘘一番,给人眼前以震惊 的感觉。

我们知道了概要设计文档要给谁看,那我们的概要设计要包含哪些内容呢?

概要设计文档需要有该系统的功能介绍,但是不是功能的具体实现。当然,我们可以在里面放用例图。我们可以将我们建模的用例图放到概要设计里面,使参看该文档的人能够对系统的功能一目了然。

另外,我们更可以把系统的主要功能界面放在该文档中,阅读者多图的吸收能力远远大于文字,简单的几幅功能图片,能够将你系统的主要功能概述出来。

此外,我们也可以将数据库的框架设计、表设计以及系统的整体架构体(也就是包图),放在概要设计里面。目的还是一样,让用户能够从全局了解该系统。

同时,我们也可以将我们的编程规范统一在概要设计文档中。

个人认为,概要设计就好像人的脸一样,它就是系统的脸。通过这张脸,我们能够看到这个系统到底漂亮不漂亮,到底值多少钱,到底有没有面子,能不能唬人。

有了概要设计,下面我们来看详细设计。

详细设计文档一定要细致。因为它主要是给编程开发人员看的,大家要严格根据详细设计文档来编写代码,所以该文档的准确性一定要高,可以说该文档出问题,那么系统就一定会有问题。

详细设计文档中,要包含各个层次之间的接口。比如我写UI层的代码,那么我就必须知道BLL有哪些类,有哪些方法、及其它的参数,返回值等。那么这些就都必须在详细设计文档中有详细的中文说明、英文名称。

这是接口,那么详细设计中还需要放写什么呢?我们还可以将时序图放在里面。我都知道,时序图是对指定功能的具体实现,将该系统的主要功能的时序图放在详细设计文档中,使开发人员对层与层之间的调用关系,方法名、参数、返回值等更加了解。

另外,系统的其他方面的具体细节,也应该在详细设计文档中声明。比如系统的精度问题、程序必要的功能、性能的描述等。

概要设计文档给系统分了模块,而详细设计就要把这各个模块逐步细化,直到开发人员能够较轻松的看懂为止。

猜你喜欢

转载自blog.csdn.net/xiangxizhishi/article/details/79940225
今日推荐