java怎么写需求文档 _需求

1. java 项目需求文档要怎么写需求文档一般分两类
需求调研报告
需求分析报告
调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。
分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：
项目的背景
项目的目标
项目的范围
用户特点
相关技术、规范标准等
相关约束
用户的组织结构、角色等
用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等
总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出
2. 来,讨论一下怎么写需求文档吧用例和UP的讨论
UML 中各种图形的重要性排行
先谈谈我的想法。
1、功能需求；
2、非功能需求或技术需求；
我一般把功能需求划分为几个部分：
a、业务过程；
b、业务规则；
c、业务数据；
非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。
1、用例规格说明描述业务过程；
2、业务规则文档描述业务规则；
3、术语表描述业务数据；
4、补充规格说明描述非功能需求（技术需求）；
UP的做法还是很有道理的。这体现了两个原则：
1、分离关注点（每个文档描述相对独立的领域）；
2、减少重复（很多用例都会引用相同的业务规则及业务数据）；
这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。
但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是比较麻烦的，特别是对于用户来说。
而且UP中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中（比如根据子系统划分）。
易理解，
易沟通，
易确认，
易跟踪，
易测试，
易验收
我想我们都应该以这个为目标来进行思考。
推荐链接Java开发新方式：专注UI，快速开发！
3. 项目需求怎么写 A、三种编写方法
1、用好的结构化和自然语言编写文本型文档；
2、建立图形化模型，这些模型可以描绘转换过程、系统状态、和它们之间的变化、数据关系、逻辑流或对象类和他们的关系；
3、编写形式化规格说明，这可以通过使用数学上精确的形式化逻辑语言来定义需求。
多种编写方法可在同一个文档使用，根据需要选择，或互为补充，以能够把需求说明白为目的。
B、应有成果
1、各业务手工办理流程文字说明；
2、各业务手工办理流程图；
3、各业务手工办理各环节输入输出表单、数据来源；
4、目标软件系统功能划分（示意图及文字说明）；
5、目标软件系统中各业务办理流程文字说明；
6、目标软件系统中各业务办理流程图（模型）；
7、目标软件系统中各业务办理各环节数据、数据采集方式、数据间的内在联系分析。
8、目标软件系统用户界面图、各式系统逻辑模型图及说明