需求文档怎么写
发布者：刘原林2020-03-16
1.怎么写项目需求文档
系统流程描述
1.1.1 项目名称
项目名称（项目类型）
1.1.2 项目开发者
成员一：**
成员二：***
成员三：***
1.1.3 项目开发环境
MyEclipse + Tomcat5.5和MyEclipse（自带）+ SQLServer 2005
1.1.4 系统功能设定
品红商业网分为2大模块：
1.前台系统
## 设定新闻，商品以及购物相关功能：
NEWS：对新闻的增加、删除和查询操作，并且增加上下条功能进行查询，以及最新新闻的显示与增加。
PRODUCT：对商品的增加、删除、修改和查询操作，并且增加分页技术进行查询，以及最新商品的展示与增加；增设对商品的选购，打印清单、结算功能。
TALKING：用户之间的在线聊天，进行互动交流，洽谈业务，对信息发表自己的看法等，并设有广告介绍，让用户了解最新信息。
MESSAGE：客户留言薄，针对各种商情，业务交流进行离线留言，站外，站内用户可以通过此信息及时了解最新资讯，了解用户反馈信息等。
about：介绍了公司对客户的信心，诚意做出了诚恳的表态。
AFTER：介绍了公司关于商品的售后服务条例等，给客户提供更满意的服务。
COPYRIGHT：介绍了公司的版权信息，以及法律授权及其相关。
2.后台管理系统
## 设定对管理员，用户以及管理员对新闻和商品信息的相关操作。
ADMIN：对用户的查询和删除，对新闻的增加，删除和查询，对商品的增加、删除、修改和查询，都增设了分页技术更有规范的查询。并附有时间，让操作人员在任何时候都能得到精准时间，以提高管理员的时间观念。
1.1.5 项目开发技术
JSP + Javascript + HTML
1.1.6 设计思路
通过相关技术，一一实现对管理员，站外，站内用户，公司新闻信息，商品信息进行实用的操作。
1.1.7 项目背景
本着为客户提供最优质的服务，项目从多角度考虑需求，以求达到客户所需要的功能，实现零距离的操作。
1.1.8 主要模块讲解
1.1.8.1 模块一
1. 名称：管理员模块
2. 简介：管理员的登录，对相应信息操作
实现了管理员对用户，管理员的操作：
1. 对用户的查询，删除（必要的删除），使用分页技术给管理员更好的视觉效果。
2. 添加管理员使用了MD5加密技术，登录及相关操作时的各种精密验证，达到更高的保密性，安全性。
1.1.8.2 模块二
1. 名称：新闻模块
2. 简介：新闻展示，更新，增加和删除
1.对新闻的查询和删除，使用分页技术给管理员提供更好的操作性能
1.1.8.3 模块三
1. 名称：商品模块
2. 简介：商品展示，更新，增加和删除
1. 对商品的查询、删除、增加和更新，分别使用分页技术给管理员提供更好的操作
1.1.8.4 模块四
1. 名称：用户模块
2. 简介：可以进行授权的操作，登录在线聊天进行交流，登录购物台进行选，购。
1.1.8.5 模块五
1. 名称：论坛模块
2. 简介：可以查看所有的论坛信息，并进行筛选，删除不健康、不文明留言
============================================================================
希望能给你 解决1
2.java 项目需求文档要怎么写
需求文档一般分两类
需求调研报告
需求分析报告
调研报告：是记录的用户的原始需求，基本上可以算做是和用户沟通的原始记录。
分析报告：是对调研报告进行归类分析的结果。一个比较全面的文档了，在这个文档里面一般包含以下内容：
项目的背景
项目的目标
项目的范围
用户特点
相关技术、规范标准等
相关约束
用户的组织结构、角色等
用户需要的功能点，这些功能的优先级，业务流程、功能特点，有没有特殊需求等等
总而言之，需求分析报告的下一站是给设计人员的，设计人员看到需求分析报告就知道系统应该包含哪些功能点、权限设计、流程设计等，这些内容都可以直接从需要分析报告里面得出
3.来,讨论一下怎么写需求文档吧
用例和UP的讨论
UML 中各种图形的重要性排行
先谈谈我的想法。
1、功能需求；
2、非功能需求或技术需求；
我一般把功能需求划分为几个部分：
a、业务过程；
b、业务规则；
c、业务数据；
非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。
1、用例规格说明描述业务过程；
2、业务规则文档描述业务规则；
3、术语表描述业务数据；
4、补充规格说明描述非功能需求（技术需求）；
UP的做法还是很有道理的。这体现了两个原则：
1、分离关注点（每个文档描述相对独立的领域）；
2、减少重复（很多用例都会引用相同的业务规则及业务数据）；
这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。
但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是比较麻烦的，特别是对于用户来说。
而且UP中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中（比如根据子系统划分）。
易理解，
易沟通，
易确认，
易跟踪，
易测试，
易验收
我想我们都应该以这个为目标来进行思考。
推荐链接Java开发新方式：专注UI，快速开发！
4.如何编写优质的需求文档
需求文档被用来定义开发任务，协调大规模的研发计划。
对于最终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。
然而，如果你在嵌入式开发领域工作的时间足够长，你就会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。
在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。 从较高的层次来看，书写需求文档的目的就是要提供对所需行为的有效描述。
该所需行为可用一个黑盒系统描述，并需要注意以下细节：工程师可以根据系统所说进行实现测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。最终产生的成果满足终端用户的要求。
黑盒测试 书写优质的需求文档： 最基本的原则是：需求文档应当尽量简洁，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素（可测试性、避免过度设计等等）都将变得顺理成章。
列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤： 1. 定义系统的边界。
这也是黑盒系统所必要的。 2. 定义输入和输出。
这也应当是你看待内部系统的唯一方式。 3. 用最易懂的方式描述系统的预期行为 4. 除了输入和输出之外，你的需求是不是还涉及了系统的其他部分？如果是，那么你的需求就设计过度了。
重构需求，让它变得精简。 5. 你的需求是不是过于模棱两可？加入更多的限定规范。
注意：有些模棱两可的描述并不是坏事，假设描述所包含的所有情况均可被接受，且测试的时候不需要附加的信息加以说明，那么就没关系。你不需要（也不应该）把系统的行为限制得过头。
6. 你的需求是否可测试？（这里指的是黑盒测试）如果不是，你最好返回到第 4 步。如果这种返工发生很多次，那就说明你的黑盒无法正确描述系统，或者你的测试工具不够优秀。
无论是哪种情况，不可测试的需求文档几乎就是一文不值的。 7. 你的需求文档通俗易懂么？如果你的需求文档非常难以读懂，那就说明你写得不好，只能给那些照着你的需求负责实施的人带来无尽的痛苦。
如果是这样，回到第 3 步。 8. 你是不是真的做到了第 4 步？你确认么？再检查一下。
例子：下面的例子，让我们描述一个自制的嵌入式设备的需求，这个设备能从弯曲传感器上读取弯曲的频率，并根据不同的频率值让一个 LED 闪烁。 显然，我们已经完成了步骤 2 和步骤 3 了！ · 输入：从弯曲传感器读取数据。
· 输出：LED。 但是我们跳过了步骤1： · 在这个例子里，我们将把黑盒画到设备的微处理器上。
让我们继续往下进行， 第四步：除了输入和输出以外，我们是否还涉及了其他的系统边界？ · 微处理器并不关心从弯曲传感器读取什么样的数据，从处理器的角度来看，仅需要做的是测量 ADC 脚的电压而已。 · LED 仅由数字输出脚控制。
下面，让我们来修正这个问题： 第0 版本的需求： 1. 该设备应当根据 ADC 脚的不同频率的电压，来切换数字输出端的状态。 第五步： 需求写模棱两可么？ 恩，我们的描述太模棱两可了.输出端切换的速度要多快？ 跟电压的关系如何？ 输入电压的范围是多少？ 让我们加一些更细节的描述吧： 版本0.1 1. 输出端应当由一个自由活动的定时器进行控制 2. 自由运行定时器的频率最高不得高于每秒 10 次，不得低于每秒 1 次. 3. 自由运行定时器的触发频率应当在最高和最低值之间呈线性变化，并与 ADC 端的输入电压成正比. 4. ADC 端的输入电压应当每 100 毫秒读取一次 5. 当 ADC 端的输入电压端被读入时，控制自由运行定时器周期时间的注册值也应当被更新. 6. ADC 输入端的电压有效范围应当被控制在 0 到 1 伏之间. 第六步： 你的需求是可测试的么？ · 首先，自由运行的定时器在这里不需要提及. 因为对它基本上无法进行黑盒测试，它既不是输入也不是输出，而且跟这两者也没有什么联系。
让我们用“数字输出端变化的频率应控制在每秒 10 次和每秒 1 次之间”来代替自由运行定时器的测试标准。 · 对于上述的第四条需求，可能需要一些小修改才能作为测试标准。
让我们用“ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次”来加以描述，这样的描述能让我们预期的测试行为显得更加通俗易懂。 · 需求的第五条也需要一些小修改。
我们如何才能检测电压的输出范围是在 0 到 1 伏之间呢？ 总不能给个 2 伏的电压，然后看看元器件有没有被烧毁吧？ 那么，说“检验系统在 ADC 端输入电压为 1 到 2 伏之间的时候，工作是否正常”，这样就检验就容易多了。需求描述应当是“正面”的，应当描述设备“应该”的行为，而不是设备“不应该”的行为。
否则的话，测试将会无法进行。 版本0.2 1. 数字输出端的切换频率应当控制在每秒 10 次到每秒 1 次之间 2. 数字输出端的切换频率应当在最大值和最小值之间呈线性变化，并与 ADC 端的输入电压成正比 3. ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次 4. 检验当 ADC 端的输入电压范围在 0 到 1 伏之。
