CSDN论坛 > 其他技术论坛 > 研发管理

那位仁兄有软件需求和设计文档的模板给小弟法发一份?这里急需呀 [问题点数:50分,结帖人softrain]

Bbs1
本版专家分:0
结帖率 98.62%
CSDN今日推荐
Bbs1
本版专家分:0
Blank
红花 2003年10月 软件工程/管理大版内专家分月排行榜第一
2003年9月 软件工程/管理大版内专家分月排行榜第一
Blank
黄花 2003年11月 软件工程/管理大版内专家分月排行榜第二
2003年8月 软件工程/管理大版内专家分月排行榜第二
匿名用户不能发表回复!登录|注册
其他相关推荐
编写测试需求及测试用例
         测试用例的模版其实没有太多的差异,而在我刚开始接触测试时总想找一个好的测试用例模版。通常来说,测试用例模版包括最主要的三项:操作说明,预期结果和否通过。有了这三项,其它的就根据你的需要来添枝加叶了,我blog上面有一个我现在用的测试需求及用例模版,可参考一下。          问题是如何填满这个模版,即如何编写测试需求和用例。有的人把测试需求和测试用例分开来编写的。测试需求作为
功能点需求模板
注意如果使用工具,Jira和TFS都有三层需求结构,分别对应Word目录中的: 一级目录:项目名称 二级目录:Jira-Theme,TFS-Epic 三级目录:Jira-Epic,TFS-Feature 四级目录:Jira-Story,TFS-Story。 注意Jira和TFS都不约而同地采用了三级目录,但是都没有提到如何划分和获取三级目录,以及三级目录的实际物理含义(比如在软件中到底是个页面,还是个表,还是个Controller……)。而本方法可以让需求直接与软件对应起来。
如何撰写一份程序员真正需要的需求文档
总所周知程序员和产品经理之间产生矛盾大多是因为一个叫「需求文档]的东西,那我们应该如何撰写一份程序员真正需要的需求文档来解决这个矛盾呢? 观点:从来不存在一份完美的需求文档可以满足任何程序猿的任何需求。 如果一定要一个答案: 让开发小伙伴认同功能价值,充满成就感是PM最重要责任之一。实操角度看,从宽度(关联性)、深度(逻辑性)、长度(预见性)、量度(价值数据化)4个方面出发去描述
概要设计文档和详细设计文档的关系
详细设计文档包含概要设计文档的全部内容(不是绝对),也就是详细设计文档,其实是在概要设计文档的基础上进一步填充内容而得到的。那为什么还要分概要设计和详细设计文档呢,以房子为例:开发商只开发毛坯房,那么此时整栋楼的设计文档就是概要设计文档。然后房子交到不同住户手上,不用的住户在已有的毛坯房的基础上进行装修设计,此时每一个住户都出一份房屋的装修设计文档,这些文档就是详细设计文档。把整栋楼的所有用户的详...
需求与设计人员如何配合工作
在软件开发的过程中 ,经常出现需求与设计脱节的现象,如设计人员按照自己的理解去设计,没有遵从需求去设计系统;需求人员做完需求定义后,交给设计人员去设计,撒手不管了等等. 为了使需求与设计人员更好的协作,建议采取如下的措施: 需求人员与设计人员一定要分离,否则无法解决需求文档化的问题,但是文档并不能解决所有的沟通的问题,还需要面对面的沟通。 需求评审设计人员一定要参加,设计评审需求人员
软件详细设计说明书、详细设计模板、样例
引言 1.1编写目的 说明编写这份详细设计说明书的目的,指出预期的读者。 1.2背景 说明: a. 待开发软件系统的名称; b. 本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。 1.3定义 列出本文件中用到专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出有关的参考资料,如: a. 本项目的经核准的计划任务书或合同、上级机关的批文; b. 属于本项目的其他已发表的文件; c. 本文件中各处引用到的文件资料,包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位,说明能够取得这些文件的来源。 2程序系统的结构 用一系列图表列出本程序系统内的每个程序(包括每个模块和子程序)的名称、标识符和它们之间 的层次结构关系。 3程序1(标识符)设计说明 从本章开始,逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块,尤其是层次比较低的模块或子程序,其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同,在这种情况下,只要简单地说明这一点即可。 3.1程序描述 给出对该程序的简要描述,主要说明安排设计本程序的目的意义,并且,还要说明本程序的特点(如 是常驻内存还是非常驻?是否子程序?是可重人的还是不可重人的?有无覆盖要求?是顺序处理还是并发处理等)。 3.2功能 说明该程序应具有的功能,可采用IPO图(即输入一处理一输出图)的形式。 3.3性能 说明对该程序的全部性能要求,包括对精度、灵活性和时间特性的要求。 3.4输人项 给出对每一个输入项的特性,包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。 3.5输出项 给出对每一个输出项的特性,包括名称、标识、数据的类型和格式,数据值的有效范围,输出的形式、数量和频度,输出媒体、对输出图形及符号的说明、安全保密条件等等。 3.6算法 详细说明本程序所选用的算法,具体的计算公式和计算步骤。 3.7流程逻辑 用图表(例如流程图、判定表等)辅以必要的说明来表示本程序的逻辑流程。 3.8接口 用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序,说明参数赋值和调用方式,说明与本程序相直接关联的数据结构(数据库、数据文卷)。 3.9存储分配 根据需要,说明本程序的存储分配。 3.10注释设计 说明准备在本程序中安排的注释,如: a. 加在模块首部的注释; b. 加在各分枝点处的注释; c. 对各变量的功能、范围、缺省条件等所加的注释; d. 对使用的逻辑所加的注释等等。 3.11限制条件 说明本程序运行中所受到的限制条件。 3.12测试计划 说明对本程序进行单体测试的计划,包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。 3.13尚未解决的问题 说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。 4程序2(标识符)设计说明 用类似F.3的方式,说明第2个程序乃至第N个程序的设计考虑。
如何写一份程序员爱看的需求文档?
上回分享的从需求到最终的解决方案,产品经理该怎么做?得到了许多人的认可,在这里,非常感谢大家的支持,同时也给笔者很大的信心,接下来分享的文章,希望大家能够喜欢,enjoy~ 产品经理的生涯中,肯定遇到过如下的痛点吧: 1.含辛茹苦地写完了需求文档(PRD),开发人员却将文档束之高阁(一万只草泥马在你的后脑勺奔腾而过……); 2.开发人员反复来回地确认需求、细节逻辑
程序员如何写出一份好的文档?
在实际的软件开发工作中,除了编写代码之外,程序员还会花大量的时间来编写相关的研发文档,这些文档包括:详细设计文档、单元/集成测试文档、软件版本开发报告、软件安装说明、软件升级指导书等。 在《程序员既要写好代码,又要写好文档》(http://www.zhouzhaoxiong.com/142.html)一文中,我提到过:“代码”和“文档”就像是一个人的左膀右臂,一定要让两者均衡发展,而不能够只顾其一
软件详细设计文档模板
1.1程序描述 给出对该程序的简要描述,主要说明安排设计本程序的目的意义,并且,还要说明本程序的特点(如 是常驻内存还是非常驻?是否子程序?是可重人的还是不可重人的?有无覆盖要求?是顺序处理还是并发处理等)。 1.2功能 说明该程序应具有的功能,可采用IPO图(即输入一处理一输出图)的形式。 1.3性能 说明对该程序的全部性能要求,包括对精度、灵活性和时间特性的要求。 1.4输人项
对软件需求分析的理解
上一篇,是从理论层次上描述的需求分析,下面谈谈我对需求分析的看法: 一、需求获取         需求获取是根据客户的特点,采用某种方式尽可能多地获取到业务的基本需求,这些需求是原生,未经过加工的,如有必要,用录音笔进行录音; 二、需求分析        2.1  拿到客户的原始需求后,需要对需求进行分析,了解细节,左右推敲,整理出疑问点,并跟客户进行咨询,最终获取最详
关闭