育才学习网1.项目需求 该 怎么写
如果是一个软件系统的项目，站在项目角度需求管理包括项目需求、用户需求、业务需求、功能需求、非功能需求等内容。而项目管理文档中主要是项目需求，在项目实施文档中主要是用户需求分析报告、软件（或系统）需求规格说明书等。项目需求主要包括：（不同的项目还会有适当增减，由于不清楚你的项目具体情况，所以把总体上项目需求包括的内容都罗列一下）
1. 适用范围（阅读者）
2. 项目背景
3. 项目概述
4. 项目目标及范围
5. 项目工期与预算
6. 项目软件（系统）需求
7. 项目约束（运行环境、开发环境、技术路线、）
8. 项目测试与验收
9. 用户培训
10. 售后维护与支持
11. 其他项目中用户提出的需求
2.项目需求报告要怎么写
听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。
需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。
听棠所说到的几点，感受特别深：
“其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析”
还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。
项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。
客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。这其实也体现了系统的扩展性。
需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。
谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。
3.项目需求分析怎么写
给你个国标，你参考参考。
再下些别人的项目需求说明，看看， 需求规格说明书 1 引言 1.1 目的 需求规格说明书是整个软件开发工作的基础，它用委托单位和承办单位都能理解的语言，清晰明确地描述所开发软件的功能、性能和软、硬件运行环境需求。 1.2 背景 本项目的委托单位： 承办单位： 1.3 参考资料 a. **有限公司**信息系统《项目开发建议书》 b. 《**公司**系统开发合同书》 c. **有限公司**系统《项目开发计划》 d. 《航空工业总公司软件工程规范汇编》，航空工业总公司软件工程化小组编。
1.4 定义 2 概述 2.1 产品描述 2.2 主要功能 要实现的业务管理功能如下： 1. 基本信息管理 1.1 2. **管理 2.1 3. **管理 3.1 4. **管理 4.1 5. **管理 5.1 2.3 实现语言 本系统将采用**数据库管理系统作为系统的后台数据库，web服务器采用**支持的**。前台采用**作为编程语言，**和** 之间采用**专用接口进行联接，服务器与客户机之间采用**进行联接。
2.4 用户特点 2.4.1 现行系统特点 a. 现行系统概况 b. **公司**管理主要业务 c. 现行系统的特点 d. 存在的主要问题 2.4.2系统的目标 2.4.3 用户业务素质 2.5 一般约束 a. 应用范围 本软件主要针对**公司**管理业务进行企业Intranet环境下的计算机辅助管理，部分信息将发布到公司Intranet上，因此本系统的开发将采用Client/Server模式与Browser/Server模式相结合的方式。**处内部采用Client/Server模式，**处以外的信息传递与访问采用Browser/Server模式，通过浏览器实现。
在实际运行过程中，希望**公司的领导能更加重视信息的收集、反馈、维护以及对某些信息传递方面作一些适当的调整，以适应计算机辅助管理的要求。 b. 系统结构 本系统为微机构成的网络管理系统，需要服务器一台，各业务办公室应该有客户机一台，通过公司布线实现网络互联和信息传递；外部环境为企业Intranet。
在服务器上运行数据库管理系统**，负责系统后台数据的管理，在各客户端安装应用软件，实现对后台数据的访问和操作；同时，在服务器上运行web server和应用服务器，在企业Intranet上用浏览器实现对后台数据库的访问。 c. 并行操作 本系统的各个子系统相对独立，都可运行于Windows NT 网络环境下，可进行并行操作。
d. 信息交换协议 系统的服务器上采用** 操作系统，而各个工作站上采用**操作系统，其信息交换协议由**内部所提供的交换功能来完成。 e. 安全保密的考虑 系统开发完成后，将对整个网络（包括服务器和各工作站）设置用户口令，对于不同级别的用户（业务人员），通过系统管理员设置不同的权限，从而保证系统的安全性与保密性要求。
3. 具体需求 3.1 功能需求 3.1.1基本信息管理 本功能属于**厂技改项目申报立项阶段的内容，包括*****的管理。 （1） (2) (3) 3.1.2 **管理 3.1.3 **管理 3.1.4**管理 3.1.5 **管理 3.1.6 技改工作通知书管理 3.1.7 **管理 3.2 外部接口需求 3.2.1 用户界面 a. 屏幕格式 . 菜单：全部采用与Windows98相一致的菜单格式，以便于用户的操作 . 输入：系统的全部数据输入和运行参数的输入均要求采用填空格式的键盘输入，在所有应提示信息处（如：实施单位等），系统应能给出下拉式的提示并能可由用户根据需要进行选择。
同时要有足够的信息提示与校验用户所输入值的有效性与合法性。 . 输出：系统的运行结果均应能通过屏幕进行输出，并要求能将输出的信息灵活地进行屏幕转换，以提高信息的可读性与操作的灵活性。
b. 报表打印格式：原则上按现行人工管理业务中报表格式进行打印输出，个别报表将结合计算机数据处理的特点重新设计报表输出格式。 3.2.2 硬件接口 **处内部系统运行的硬件环境为微机构成的局域网，因此除微机之外还需要网卡和网络连线，所有这些器件在网络连接方面均为成熟技术；**处外部的系统运行环境为**公司Intranet，外部环境由公司计算中心负责维护。
3.2.3 软件接口 本系统的开发采用**大型数据库与**，后台的**数据库管理系统用来存贮和管理各子系统的数据，而前台的**所编制的程序用来操作后台的**，它们之间通过**专用接口来进行联接，服务器与客户机之间采用**进行联接。 3.2.4 通讯接口 本软件涉及到公司多个部门之间进行信息通讯的问题，所以本网络系统所采用的是TCP/IP网络协议。
3.3 性能需求 a. 输入：系统应尽可能使输入的数据越少越好，尽量避免数据的重复输入；数据输入的格式应符合业务习惯，并且直观、方便。 b. 处理：要求系统处理的数据能准确无误，在硬件条件一定的前提下，力求系统处理数据的速度最快。
尤其是在信息统计之处，更要注意这一问题。 c. 系统的屏幕输出应能够满足管理业务所需信息量的要求，并要求输出直观、简洁，具有可重复查询功能与屏幕格式的转换功能。
报表的输出要能满足管理业务的要求，并可实现分页、任选输出，同时打印输出环境也要能适合于不同类型的打印机，以增强系统的可使用性。 3.4 设计约束 3.4.1 需求遵循的其它标准 a. 报表格式：根据现行系统的报表格式，由系统分析员和计划处业务人员共同商量后加以确定。
b. 数据命名：由系统分析员和系统设计员加以制定。 3.4.2 硬件的限制 系统。
4.项目需求怎么写
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、避免使用比较性词语，如“提高”，应定量说明提高程度
5.一个C语言项目需求都包括什么啊
1.引言
1.1编写目的
编写本文档的目的
1.2产品介绍
说明产品是什么，什么用途
介绍产品的开发背景
1.3定义
术语与缩写的解释
1.4参考资料
2.任务概述
2.1目标
项目的目标
2.2运行环境
2.3产品面向的用户群体
描述本产品面向的用户（客户、最终用户）的特征，
说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？
3.数据描述
3.1静态数据
数据库字段等，应从需求的角度写明，下同
3.2动态数据
输入输出数据等
3.3数据库介绍
所使用的数据库
3.4数据词典
数据库的表
3.5数据采集
配置数据库参数等
4.产品的功能性需求
4.1功能性需求分类
将功能性需求先粗分再细分
4.2功能A描述
4.3功能B描述
5.产品的非功能性需求
5.1数据精确度
5.2时间特性
5.3适应性
6.运行需求
6.1用户界面需求
6.2故障处理
7.其它需求
可列表说明：
正确性
可靠性
效率
完整性
可维护性
安全性
易用性
6.项目需求报告要怎么写
项目需求分析，看了听棠的“客户需求何时休”，深有感触，何曾自己不是被这个问题整天困扰：客户需求，为什么总在变阿？做项目真辛苦阿！这样的感叹整天都挂在口上。
客户需求变动确实是一个软件开发永远不变的话题。为什么小的软件企业面对经常变动的需求是如此的狼狈？到底要怎么做才能满足客户的需求？ 听棠的“客户需求何时休”深刻的披露了这个问题存在的根源。
需求分析，不仅仅是拿到客户的需求，更重要的是还需进行分析，了解细节，并就细节跟客户咨询，获取最详细的资料。客户所能提供给你的只是他们想到的功能需求，很多问题并不在他们考虑的范围之内，如果作为项目承担方没有去做分析，简单的按照功能要求去设计、规划，最终出来的系统是很难完全符合客户的业务流程的，这时，自然需要更改，被看成了需求的更改。
其实，都是缺乏分析所一手造成的。问题等到系统出来了才被发现，这样的系统本身就是先天不足的了。
听棠所说到的几点，感受特别深： “其实问题出在开头，客户需求只是软件需求分析的一部分，虽然是比较重要的一部分，但也不要只是去记客户的需求，而是要把客户的需求进行分析” “客户本身是不怎么懂技术的，客户只知道自己的业务需求，而在软件设计时，是在把业务需求抽象到系统中实现的，把业务转变为逻辑时，一切都应该符合逻辑的，但客户的业务思想有时候在软件系统实现时会有问题的，这就需要分析时分析出来的。 少了分析，问题也会在后面的开发中暴露出来，到时可就更麻烦了。”
还有客户的需求本身会有矛盾（这矛盾是指在逻辑角度来讲），客户本身是意识不到的，只有在分析设计时，才会分析出这里的矛盾，而这些问题，如果在期初时，软件负责人不分析，而是纯粹的“听从”客户要求去做，当暴露这些问题时，你怪客户也没用啊。 项目需求分析报告，在了解客户需求时，不要不动脑子，不要一味的点头说“I C”，其实在表面的业务里面可能包含着N多的细节，这些细节是需要你反问客户的，只有当你提的问题越多，最终获取的需求最具体，才能让项目越顺利。
而且有很多问题，都是在你的反问中，客户也才开始思考本来没思考过的问题，客户也会找到一种合理的需求给你，有人会觉得这样了解客户需求未免太麻烦了。 至于一些在技术上会遇到问题的地方，也要告诉客户，别以为到时候再说，客户是不关心你的技术细节的，但你如果给他解释的话，他也会试着理解的。
客户的需求本身是无休止，因为他们本身也在变，但当你期初的分析合理，后面的变动也将在逻辑上变动，相信代价已经不会那么大了。 这其实也体现了系统的扩展性。
需求分析，是一个项目提出方和承担方相互沟通的过程，一方是系统的使用者，一方是系统的制造者，在系统制造过程中，只有双方相互配合，共同对系统进行设计才能最后达到使用的要求。客户是业务上的熟悉者，对业务流程有非常清晰的了解，但是，对于软件需求方面的描述是不了解的，他们所能提供的只是他们最终要达到的功能，但是，这其中包含的业务流程是非常复杂的。
我们拿到客户需求后，应该根据功能、流程进行初步的设计，构造出业务流程图，再让客户进行评审，提出业务流程上不对的地方进行修改。这样来回的交流，最终才能取得较全面的需求，并减少后期的修改。
谨记一点，需求是经常变动的，只有先做好需求的分析，了解业务以后的发展趋势，做好具有拓展性的系统设计，才会给系统更大的扩展空间，从而在需求发生变化的时候可以更从容的修改。 。
7.java项目需求分析怎么写
需求文档一般分两类：需求调研报告、需求分析报告
调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。
分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：项目的背景、项目的目标、项目的范围、用户特点、相关技术、规范标准等。相关约束、用户的组织结构、角色等用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等
总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出