育才学习网1. java 项目需求文档要怎么写
需求文档一般分两类
需求调研报告
需求分析报告
调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。
分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：
项目的背景
项目的目标
项目的范围
用户特点
相关技术、规范标准等
相关约束
用户的组织结构、角色等
用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等
总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出
2. 项目需求怎么写
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、避免使用比较性词语，如“提高”，应定量说明提高程度
3. 来,讨论一下怎么写需求文档吧
用例和UP的讨论
UML 中各种图形的重要性排行
先谈谈我的想法。
1、功能需求；
2、非功能需求或技术需求；
我一般把功能需求划分为几个部分：
a、业务过程；
b、业务规则；
c、业务数据；
非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。
1、用例规格说明描述业务过程；
2、业务规则文档描述业务规则；
3、术语表描述业务数据；
4、补充规格说明描述非功能需求（技术需求）；
UP的做法还是很有道理的。这体现了两个原则：
1、分离关注点（每个文档描述相对独立的领域）；
2、减少重复（很多用例都会引用相同的业务规则及业务数据）；
这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。
但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是比较麻烦的，特别是对于用户来说。
而且UP中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中（比如根据子系统划分）。
易理解，
易沟通，
易确认，
易跟踪，
易测试，
易验收
我想我们都应该以这个为目标来进行思考。
推荐链接Java开发新方式：专注UI，快速开发！
4. java面试官问有没有写过文档（面试java程序员）,我想知道写文档是
我想他的文档是指在项目开发过程中 不同阶段的文档
我们项目组开发基本是基于瀑布模型开发 每个阶段都会输出文档指导后续工作开展
一般se下发需求后 由我们出 详细需求设计文档
代码开发完成了 转测试时我们会写 数据库设计文档 ，操作手册 （这个也算）
还有就是 版本升级说明书 版本功能清单 软件介绍
这个是大概的文档 还有其他的。文档编写时间 主要是代码开发前 与 转测试后
5. 自己写Java文档一般需要有哪些内容
每个非 private 方法的参数说明，像 getter/setter 这样简单的就省略掉。主要是关键方法和类的设计要有说明。另外，一些方法有内部的实现约定，也就是前提条件，这个在技术上没办法验证的或验证它会影响性能等，我们就只在文档中说明，不在代码中检查了。举个例子，java.util.ArrayList 不是一个线程安全的集合实现类，它就在文档中说明了这点，另一个就是 equals 和 hashcode 方法在你覆盖它时应该同时按相同的算法覆盖两个，只覆盖一个就不符合设计约定。再一个就是简要说明你的关键方法和类是如何设计的。
一个好的文档可以用来回答 What, Why & hoW 这三个 W。
6. 想做java方面的项目有没什么需求文档
能否告诉我你的水平如何？若你只是纯粹想做个项目练练手的话，建议你可以做一些需求简单，但技术方面有些挑战的项目，比如，你可以开发一个象棋或者围棋的人机博弈游戏，自己写一个俄罗斯方块，自己写一个搜索引擎，或者写一个聊天工具都是可以的，这些东西我们平时都玩过或者经常用，需求自然也就十分简单和清楚，不会需要花你很多的时间去做需求的分析，而可以把重点放在项目的设计和实现上，项目的设计和实现对初学者来说很重要，想做好而需求分析或系统分析，若扎实了基本技术技能，效果会更好。
转载请注明出处育才学习网 » java需求文档怎么写