项目需求说明书,怎么写

1. 项目需求说明书,怎么写

一 ：引言1、编写目的：说明编写这份项目需求说明书的目的，指出预期的读者。
2、背景说明：待开发的软件系统的名称。本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络。该软件系统同其他系统或其他机构的基本的相互来往关系。
3、定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。4、参考资料列出用得着的参考资料，项目相关的计划书，或者合同，批文之类的。
二：任务概述1、目标叙述该项目开发的意图、应用目标、作用范围以及其它应向读者说明的有关该软件开发的背景材料。解释被开发软件与其它有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。2、用户的特点列出本项目的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使用频度。这些是软件设计工作的重要约束。3、假定和约束列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。
三：需求规定1、对功能的规定用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。2、对性能的规定：精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。时间特性要求：说明对于该软件的时间特性要求。
四：运行环境规定
1、设备列出运行该软件所需要的硬件设备。说明其中的新型设备及其专门功能。2、支持软件列出支持软件,包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。3、接口说明该软件同其他软件之间的接口、数据通信协议等。4、控制说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。
五 数据要求数据的逻辑描述：对数据进行逻辑描述时可把数据分为动态数据和静态数据。所谓静态数据，指在运行过程中主要作为参考的数据，它们在很长的一段时间内不会变化，一般不随运行而改变。所谓动态数据．包括所有在运行中要发生变化的数据以及在运行中要输入、输出的数据。进行描述时应把各数据元素逻辑地分成若干组，列如函数、源数据或对于其应用更为恰当的逻辑分组。给出每一数据元的名称（包括缩写和代码）、定义（或物理意义）度量单位、值域、格式和类型等有关信息。

扩展资料需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。
参考资料百度百科-需求分析

2. 项目需求分析怎么写

项目需求分析的概念　　需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程。（这个和我在微软体验到的又不太一样，微软的需求分析大多是市场人员和用户协助小组的人去评估用户的接受程度，这一点也可以理解，因为公司的性质有根本差别）在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段结束后，要求得到：1.SRS文档(System Requirement Specification); 2.DRM 文档；3.Acceptance Plan. 从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。
　　狭义上理解：需求分析指需求的分析、定义过程。 一、为什么要需求分析　　需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
　　需求分析之所以重要,就因为他具有决策性,方向性,策略性的作用,他在软件开发的过程中具有举足轻重的地位.大家一定要对需求分析具有足够的重视.在一个大型软件系统的开发中,他的作用要远远大于程序设计. 二、需求分析的任务　　简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.三、需求分析的过程　　需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
　　问题识别
　　就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
　　分析与综合
　　逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
　　制订规格说明书
　　即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
　　评审
　　对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。 四、需求分析的方法　　需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
　　原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
　　原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
　　原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
　　在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
　　追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

3. 项目需求怎么写?(java web)

A、三种编写方法

　　1、 用好的结构化和自然语言编写文本型文档；

　　2、 建立图形化模型，这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系；

　　3、 编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。

　　多种编写方法可在同一个文档使用，根据需要选择，或互为补充，以能够把需求说明白为目的。

　　B、应有成果

　　　1、 各业务手工办理流程文字说明；

　　　2、 各业务手工办理流程图；

　　　3、 各业务手工办理各环节输入输出表单、数据来源；

　　　4、 目标软件系统功能划分（示意图及文字说明）；

　　　5、 目标软件系统中各业务办理流程文字说明；

　　　6、 目标软件系统中各业务办理流程图（模型）；

　　　7、 目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。

　　　8、 目标软件系统用户界面图、各式系统逻辑模型图及说明

　　C、文档工具推荐

　　　1、 调研结果《需求分析说明书》格式参照开发文档模板；

　　　2、 单位组织结构图、功能模块分解图用VISIO绘制，或直接用WORD中的画图工具；

　　　3、 业务流程图用VISIO中的FLOWCHART模板绘制；

　　　4、 系统逻辑模型使用ROSE绘制活用VISIO中的UML模板绘制；

　　　5、 软件用户界面用VISIO中的WIN95 USER INTERFACE模板绘制；

　　　6、 数据物理模型用POWERDESINER绘制；

　　D、需求文档编写原则

　　　1、 句子简短完整，具有正确的语法、拼写和标点；

　　　2、 使用的术语与词汇表中所定义的一致；

　　　3、 需求陈述应该有一致的样式，例如“系统必须..”或者“用户必须..”，并紧跟一个行为动作和可观察的结果。；

　　　4、 避免使用模糊、主观的术语，减少不确定性，如“界面友好、操作方便”；

　　　5、 避免使用比较性词语，如“提高”，应定量说明提高程度

4. 用户需求说明书文档模板怎么编写？

用户需求说明书模板 文档标识：当前版本：1.0当前状态：草稿发布日期：2009-1-1发布ü修改历史日期版本作者修改内容评审号变更控制号目录1 引言... 31.1 编写目的... 31.2 项目背景... 31.3 术语定义... 31.4 参考资料... 32 综合描述... 32.1 产品介绍... 32.2 目标范围... 32.3 用户特性... 42.4 约定假设... 43 用户需求（可剪裁）... 43.1 总体需求（可剪裁）... 43.2 内容需求（可剪裁）... 54 功能需求... 54.1 数据需求（可剪裁）... 54.2 接口需求（可剪裁）... 64.3 权限控制需求（可剪裁）... 64.3.1 系统安全要求（软硬件）... 64.3.2 用户角色... 64.3.3 角色权限控制... 65 非功能需求... 65.1 用户界面需求（可剪裁）... 65.2 性能需求（可剪裁）... 75.3 压力需求（可剪裁）... 75.4 主流技术应用需求（可剪裁）... 75.5 安全需求（可剪裁）... 75.6 故障处理需求（可剪裁）... 75.7 环境需求（可剪裁）... 75.8 产品质量需求... 75.9 其他需求（可剪裁）... 86 需求优先级... 87 附加说明（可剪裁）... 81 引言 1.1 编写目的 本节描述编写该用户需求说明书的目的，并指出预期的读者。1.2 项目背景 本节描述用户需求说明书中所定义的产品的背景和起源，以及同其他系统或其他机构的基本相互关系等。当在已有的系统上进行特性开发时，如果新特性与已有系统的特性之间存在关系，则应在本节说明其相互之间的关系。1.3 术语定义 本节可列出本文件中用到的专门术语的定义、外文首字母组词的原词组等。1.4 参考资料 本节列举编写用户需求说明书时所参考的资料或其他资源，这可能包括用户合同、公司规范、技术书籍等。在这里应该给出详细的信息，包括资料名称、版本号、作者、日期、出版单位或资料来源，以方便读者查阅这些文献，可用以下格式表示： 资料名称版本号作者日期出版单位/资料来源备注                        2 综合描述 2.1 产品介绍 本节简要描述产品的特性。2.2 目标范围 本节简要描述产品的应用目标、作用范围等。2.3 用户特性 本节可能包括本产品各类最终用户的特点，如操作、维护等人员的知识水平和技术专长等，也可能包括用户组织关系结构图以及组织、部门、岗位的隶属关系与职能。这将是后续工作的重要依赖条件。2.4 约定假设 本节列举出在对软件用户需求说明书中影响需求陈述的假设因素（与已知因素相对立）。这可能包括将要使用的组件、特殊的用户界面设计约定、产品预期使用频度等。如果这些假设不正确、不一致或被更改，就会使项目受到影响。3 用户需求（可剪裁） 每一项需求必须进行唯一标识，并给出该项需求的优先级。需求优先级的定义，一般需要根据用户意见结合商业价值、交付成本、交付日期、复杂程度、风险等因素来进行考虑。高优先级需求表示本系统产品中必须实现的需求，中优先级需求表示必须但是根据时间情况有可能会被推迟到下一版本的产品中去实现的需求，低优先级需求表示如果没有充足的时间或资源就可以被放弃的需求。具体描述请参考《需求跟踪矩阵》！需求编号方式可以根据项目实际情况进行自定义，也可以采用“项目代号”＋“-”＋“R”＋“需求类型”＋“序号”的形式。其中“R”表示Requirement，“需求类型”可用下表表示，“序号”以自然数表示，位数不限。 需求类型英文名称中文名称FFunction功能PPerformance性能DData数据UUser Interface用户界面IInterface接口SSecurity安全MMalfunction故障处理OOther其他示例：OLTP-RI5表示为OLTP项目的第5项用户界面需求。3.1 总体需求（可剪裁） 描述项目总体需求，简述项目特性等内容。3.2 内容需求（可剪裁） 按照内容（如产品包、组件等）展开用户需求。4 功能需求 详细列出系统各模块/主题/子系统的功能需求。提示：将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称（可考虑加上需求的优先级别）。在描述中要简要阐述该需求项将依赖于哪些需求项。 功能类别标识符子功能名称描述Feature AFunction A.1…Feature BFunction B.1…Feature CFunction C.1…产品包提示：针对本功能进行说明描述（包含其要做什么、什么流程、相关的财务、特殊要求、需要的数据等），可以采用相关的图表来更容易地表达信息。① 功能描述：描述需求项的功能。② 业务描述：描述该需求项的业务流程、相关的对象的状态、涉及到的业务角色等。③ 数据描述：描述需求项的数据项、数据精度、输出的格式等要求。④ 输入描述：描述该需求项的相关依赖（包括业务依赖和需求项的依赖）和输入条件。⑤ 输出描述：描述需求功能执行后，相应的输出产物、数据、对象状态等。4.1 数据需求（可剪裁） 详细列出系统的数据需求，可能包括数据类型、载体、格式、数值范围、精度、规模等需求。4.2 接口需求（可剪裁） 详细列出系统的接口需求，可能包括与其他系统之间的接口、数据通信协议、内部模块之间的接口等需求。4.3 权限控制需求（可剪裁） 4.3.1 系统安全要求（软硬件） 提示：说明对本产品系统的功能方面的安全的要求，如用户名密码加密、系统访问安全等。4.3.2 用户角色 提示：阐述本产品的各种角色及其职责。各种角色的具体行为将在功能性需求中描述。角色例如：系统管理员（SuperAdmin-Lowest Level）内部操作管理员（OperatorAdmin-Mid Level）外部操作管理员（ResellerAdmin-Midhigh Level）终端用户管理员（UserAdmin – High Level） 角色名称职责描述          4.3.3 角色权限控制 提示：描述上述各用户角色的权限控制要求5 非功能需求 5.1 用户界面需求（可剪裁） 详细列出系统的界面需求，可能包括图形用户界面标准、产品系统风格、屏幕布局或解决方案的限制、快捷键、错误信息显示标准等。5.2 性能需求（可剪裁） 详细列出系统的性能需求，可能包括时间特性要求、软件灵活性、容错性、容量需求等。提示：说明本产品的整体性能必须达到程度，特别是一些关键功能点。5.3 压力需求（可剪裁） 提示：说明本产品使用必须满足的压力峰值要求5.4 主流技术应用需求（可剪裁） 提示：说明本产品需要使用何种主流技术。如果不清楚或不明白可以不填后面由项目开发组提出技术方案再进行选择。5.5 安全需求（可剪裁） 详细列出系统的安全需求，可能包括安全设施需求和安全性需求等。安全设施需求是指产品使用过程中可能发生的，与损失、破坏或危害相关的需求。定义必须采取的安全保护或动作，还有那些预防的潜在的危险动作。明确产品必须遵从的安全标准、策略或准则。一个安全设施需求的范例如下：“如果油箱的压力超过了规定的最大压力的95%，那么必须在1秒钟内终止操作”。安全性需求是指与系统安全性、完整性或与私人问题相关的需求，这些问题将会影响到产品的使用和产品所创建或使用的数据的保护。定义用户身份确认或授权需求。明确产品必须满足的安全性或保密性策略。一个安全性需求的范例如下：“每个用户在第一次登录后，必须更改他的最初登录密码。最初的登录密码不能重用。5.6 故障处理需求（可剪裁） 详细列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。5.7 环境需求（可剪裁） 详细列出各种环境需求，可能包括开发环境、测试环境、运行环境等需求。具体内容可能涉及到网络、服务器、数据库、前台、测试工具等的软件、硬件方面。5.8 产品质量需求 描述产品预期达到的质量要求，包括多个质量特性，以下的质量属性仅为参考，各项目可以根据需要补充或删除某些质量特性。 主要质量属性详细需求正确性 可靠性 健壮性 性能、效率 易用性 清晰性 安全性 可扩展性 兼容性 可移植性 … 5.9 其他需求（可剪裁） 详细列出在前文中没有包括的所有需求，可能包括用户对可维护性、可补充性、易读性、可移植性等方面的特殊需求，或者国际化或法律上的需求。6 需求优先级 根据用户的需要程度，初步列出各需求的优先级，参见《需求跟踪矩阵》。7 附加说明（可剪裁） 描述该用户需求说明书采集的方法，如访谈、现场体验、惯例综合等。参见的竞争产品和相应的用户需求获取文档，如用户故事、需求采集表等类似文档。Download: template-requirement-analysis.rarREF:http://www.mspsw.cn/wp-content/upload_s/2009/06/requirement-analysis-template.doc软件设计文档国家标准(GB8567--88)GB8567——88