求帮写一个C++程序的文档（包括需求分析、总体架构、详细设计、调试记录、项目说明） 程序我已经写好

一般按照以下步骤进行：
1 需求分析：
明确程序要实现的最终效果，需要哪些资源，并进行进度规划。
2 概要设计：
对程序进行模块化，确定各个模块功能，及各个模块间的交互。
3 详细设计：
对每个模块具体如何实现进行设计，确认模块实现方式，对内及对外接口定义。
4 代码实现：
按照设计规划，实现具体代码。
5 测试：
对各模块进行测试，最终测试整体。解决存在的问题，最终形成有效程序。

在大多数软件项目中，要末不作详细设计，要么开发完成后再补详细设计文档，质量也不容乐观，文档与系统往往不能同步，使详细设计文档完全流于形式，对工作没有起到实际的帮助。
·
详细设计是相对概要设计而言的，是瀑布开发流程的一个重要环节，在概要设计的高层设计的基础上，从逻辑上实现了每一模块的功能，是编码阶段的主要参考资料，是从高层到低层、逐步精化思想的具体实现。
详细设计文档的内容包括各个模块的算法设计，
接口设计，
数据结构设计，交互设计等。必须写清楚各个模块/接口/公共对象的定义，列明各个模块程序的
各种执行条件与期望的运行效果，还要正确处理各种可能的异常。
·
在开发过程中，由需求及设计不正确、不完整所导致的问题是项目进度拖延、失败的一个主要因素，而软件系统的一个重要特性就是需求和设计的不断构建和改进，在写详细设计文档过程中，
详细设计实际上是对系统的一次逻辑构建，可以有效验证需求的完整性及正确性。
如果不写详细设计文档，一般就从概设直接进入编码阶段，这时开发人员所能参考的资料就是需求规格说明书及页面原型、数据库设计等，不能直接进行开发，需要进行信息的沟通，把页面原型不能体现的设计讲清楚，这样既容易遗忘，也容易发生问题，详细设计文档可以作为需求人员、总体设计人员与开发人员的沟通工具，把静态页面无法体现的设计体现出来，包含整体设计对模块设计的规范，体现对设计上的一些决策，例如选用的算法，对一些关键问题的设计考虑等等，使开发人员能快速进入开发，提高沟通效率，减少沟通问题。
对于系统功能的调整，后期的维护，详设文档提供了模块设计上的考虑、决策，包括模块与整体设计的关系、模块所引用的数据库设计、重要 *** 作的处理流程、重要的业务规则实现设计等等信息，提供了对模块设计的概述性信息，阐明了模块设计上的决策，配合代码注释，可以相对轻松读懂原有设计。
·存在的问题要由专门的人写，是比较麻烦的，也是很需要时间的，会对进度造成压力，也容易形成工作瓶颈，使设计人员负担过重，而开发人员无事可作。对于现在一般的以数据库为中心的管理系统而言，这个工作始终是要作的，区别只不过是不是形成专门文档，形成文档可能会多花一两周时间，但相对于规避的风险和问题来说，也是值得的，另外由于现在高级语言的流行，所以更详细的设计应该直接体现在代码的设计上，而文档则只体现设计上的一些决策，协调整体设计与模块设计的关系，把页面原型所不能体现的设计情况文档化，所以所花费的时间是有限的。
设计内容容易过细，但设计阶段是不能考虑特别清楚地，时间也不允许。
对于这个问题，一个对策是上边所提到的，文档只体现设计上的决策，页面原型所不能反映的信息，详细设计只体现总体设计对模块设计的一些考虑，例如对功能的数据库设计等等，而具体的实现实现，则到代码中再去实现，相关的设计也仅体现在代码中。
需求、设计需要不断的被更新、构建，则设计文档需要不断的重新调整，文档的维护需要跟上，否则文档和系统的同步就很难得到保障了，且造成多余的工作量。文档的内容易流于形势，质量糟糕，不能成为开发人员的参考手册，一是要建立起相关制度，如有修改，先改文档，后作开发，从工作流程上切实保障文档与系统的同步，二是要规范文档质量，对文档该写什么，不该写什么，标准是什么，粒度是什么，语法应该如何组织，有明确的标准和考虑，同时，建立审计文档评审、审核制度，充分保障系统的使用。·
首先是文档的内容，根据项目和团队的不同，详细设计文档的内容也有所不同，一般说来，粒度不宜过细，不能代替开发人员的设计和思考，但要把有关设计的决策考虑进去，包括与其他模块、整体设计的关系、 *** 作的处理流程，对业务规则的设计考虑等，有一个标准为，凡是页面原型、需求规格说明书所不能反映的设计决策，而开发人员又需要了解的，都要写入文档。
其次是文档所面向的读者，主要为模块开发人员、后期维护人员，模块开发人员通过详细设计文档和页面原型来了解所开发的功能，后期维护人员通过实际系统、模块代码、详细设计文档来了解一个功能。
再有就是谁来写文档，因为文档主要考虑的是设计上的决策，所以写文档的人应该为负责、参加设计的技术经理、资深程序员，根据团队情况和项目规模、复杂度的不同，也有所不同。
还需要保证文档的可读性、准确性、一致性，要建立严格的文档模板及标准，保证文档的可读性及准确性，同时建立审核及设计评审制度，来保障设计及文档的质量，另外在工作流程中要强调，要先设计、先写文档，再进行开发。

程序说明书包括如下七个内容：
1程序名称；包括反映程序功能的文字名称和标识符。
2程序所属的系统、子系统或模块的名称。
3编写程序所需使用的语言。
4输入的方式和格式：当程序有多种输入时，分别对每种输入方式与格式做出具体而细致
的说明。
5输出的方式与格式：当程序有多种内容按不同方式输出时，分别说明不同内容按不同方
式输出时的格式。
6程序处理过程说明：包括程序中使用的计算公式，数学模型和控制方法等。
7程序运行环境说明：对程序运行所需要的输入输出设备的类型和数量，计算机的内存及
硬盘容量，支持程序运行的 *** 作系统等内容进行说明。
由于种种原因，在实际工作中不太重视程序说明书的编写工作。这既不利于程序的设计工作，更不利于对程序的修改和维护工作。因为系统投入运行后，需要经常根据情况的变化进行调整和修改，如果没有完善的文档资料，维护、修改就很难进行。

项目需求分析怎么写
项目需求分析的概念需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1SRS文档(System Requirement Specificatio郸); 2DRM 文档；3Acceptance Plan 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。

狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析需求分析就是分析软件用户的需求是什么如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死

需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位大家一定要对需求分析具有足够的重视在一个大型软件系统的开发中,他的作用要远远大于程序设计 二、需求分析的任务简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求三、需求分析的过程需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审

问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型, *** 作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标

分析与综合

逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型)

制订规格说明书

即编制文档,描述需求的文档称为软件需求规格说明书请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交

评审

对功能的正确性,完整性和清晰性,以及其它需求给予评价评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法需求分析的方法有很多这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论

原型化方法是十分重要的(是软考等常考的知识点)原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能

原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个
软件的需求分析怎么写啊？
1 引言

11　编写目的:编写此文档的目的是进一步定制软件开发的细节问题,便于用户与开发商协调工作本文档面向的读者主要是项目委托单位的管理人员希望能使本软件开发工作更具体

12　项目背景

121项目委托单位:公司

122开发单位:公司

13　定义

14参考资料

2 任务概述

21　目标:

<1> 决策支持:根据公司的要求及时提供所需报表及文件,并在适当时候对各部门领导给予销售及进货等方面的提示

<2>提高效率:利用软件进行管理,避免人工管理的失误以及 延迟性,从而实现高效率的管理

22　运行环境:

<1> 硬件方面:Pentium级处理芯片

1兆显存的兼容显卡

256色,800600的兼容显示器

标准兼容打印机

<2>软件方面: WIN95 *** 作系统

23　条件与限制:

编程用计算机一台

完成期限2000/7/1

无资金供给

3 数据概述

数据流程图如下:

31　静态数据:包括系统登录密码,各数据库所在位置,系统分析原始数据

32动态数据:包括各数据库内各项显示数据,用户登录信息,系统时间

33　数据库描述:

人事管理数据库:公司内人员的个人详细信息,包括档案信息

销售管理数据库:当日销售记录及以前的销售统计,用于销售分析

财务管理数据库:公司内部账目及收支情况详表

技术管理数据库:公司所需各技术档案的详细记录(包括文档)

34 数据字典:

<1>数据流词条描述:

1数据流名:登录信息

来源:用户的输入

去向:系统内部检验部分

组成:用户名,密码

流通量:每次登录输入一次

2数据流名:登录结果

来源:系统

去向:用户

组成:返回信息

流通量:每次登录返回一次

3数据流名:输入修改信息

来源:用户

去向:系统判断部分

组成:根据各数据库内容而不同

流通量:依用户输入而定

4数据流名:反馈信息

来源:系统判断部分

去向:用户

组成:系统经判断后发回的字符数据

流通量: 依系统当前信息而定

5数据流名:识别信息

来源:系统内部检验部分

去向:系统判断部分

组成:系统各数据库的标识信息

流通量:用户每次输入流通一次

6数据流名:处理信息

来源:系统判断部分

去向:各数据库处理部分

组成:读取/修改标识,读取/修改的变量名称

流通量:用户每次输入流通一次

7数据流名:读取修改

来源:系统判断部分

去向:系统各数据库

组成:读取/修改标识,读取/修改内容

流通量: 用户每次输入流通一次

<2>数据文件词条描述:

1数据文件名:人事数据

简述:存储人员信息

数据文件组成:人员的各项信息(以CString类型为主)

2数据文件名:销售数据

简述:存储当日及从前的销售记录

数据文件组成:销售的各项信息

3数据文件名:财务数据

简述:存储财务管理信息

数据文件组成:财务管理的各项记录

4数据文件名:技术数据

简述:存储公司内部使用的技术档案信息

数据文件组成:技术档案名称,内容

<3>加工逻辑词条描述:

1加工名:检验


项目目标与任务需求分析应该怎么写？
项目目标与任务需求分析=项目的目标和任务，目标和任务是什么就写什么了
项目需求报告要怎么写？
听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。听棠所说到的几点，感受特别深：“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。
如何做需求分析
随着技术的不断发展和用户对网站功能性的需求不断提高，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比，网站项目的设计和开发越来越像一个软件工程，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代，建立规范的、有效的、健壮的开发机制，才能适应用户不断变化的需要，达到预期的计划目标。

网站项目管理（WPM）的含义为Web-based Project Management，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器、网络和Web

服务器等关键主体，主要体现在网站设计、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店、虚拟邮局、客户关系管理。）等项目管理中。

按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制：

1 需求分析及变更管理

2 项目模型及业务流程分析

3 系统分析及软件建模

4 界面设计、交互设计及程序开发

5 系统测试和文档编写

6 客户培训、技术支持和售后服务

需要说明的是，这些阶段虽然具有一定的延续性，但是并非完全隔断的，例如需求变更管理和测试工作、文档编写都是贯穿整个项目过程的，许多工作时交叉进行或同时进行的。

（一）如何做好需求分析及变更管理？

业务员与客户进行的沟通，撰写需求分析报告是项目展开的基础。项目是以客户的需求为中心，而不是为技术而迁就需求。

一：让客户畅所欲言，罗列出所有的需求

让用户将所有的想法尽可能的阐述清楚，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引”起客户的潜在需求而增加设计开发的工作量，从而被今后客户无止境的变更拖入泥潭，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳、分析先都扔到一边去，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作。

很明显，假如客户的需求做的都不完整，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问，而你原来想当然的以为了不起就是1万独立IP访问的访问流量，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器、数据库还是程序全部要重新开发！

二：透过现象分析潜在的需求

很多情况下客户并非专业人士，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意。

客户往往对需求的概念是非常模糊的，大多时候给出的需求都是笼统而且尺度难以控制的，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。

比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑，客户通常能够接受分阶段实施的开发过程，在需求分析时，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外，也为今后业务的进一步深入打下
做程序，项目需求分析，一般做多久。
国内很多老一辈的根本不注重这一点。但国外的，很小的开始实战写需求了。因为他们一直认为需求是相当重要。每次都做项目前都是，乱七八 *** 的需求分析，像个草搞。偶尔做一下，改一下。改一下需求，那么，原来的框架，编码都要改。而我同学他们的虽然做需求做了一个月多，但却是按需求很顺利的一气搞定。我问的是：无论是多大，还是多小的项目，都要把需求写清楚再做。
java 项目需求文档要怎么写？
需求文档一般分两类

需求调研报告

需求分析报告

调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。

分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：

项目的背景

项目的目标

项目的范围

用户特点

相关技术、规范标准等

相关约束

用户的组织结构、角色等

用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等

总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出

---