需求说明书该不该写的很详细？
需求说明书一般都是这样写的：
6.3.2.3参数设置
设置系统运行需要的基本参数配置。
系统配置参数如下：
标题：设置系统显示的标题。
然后在详细中着重描述：
3.3.2.3.1模块描述
设置系统运行需要的基本参数配置。
3.3.2.3.2功能
1、标题：设置系统显示的标题。
3.3.2.3.3 输入项
名称类型约束
标题文本框必填、最大长度为50个字符
3.3.2.3.4输出项
名称描述返回数据
标题为空提示“必填”
大于50个字符提示“最大长度为50个字符”
还是说，在写需求的时候，需要把功能中的字段类型、长度限制等约束全部需要加上
请问大家是如何写需求文档的呢？
能否提供需求文档以供参考
[解决办法]
首先应看到需求说明书的目标阅读对象是谁
如果只是项目组内部，则简洁概要性的描述，只为需求定性、需求索引
更多的精力放在设计阶段
如果用于给客户签字，则必须足够详细，避免二义性以及争议
如果之前没写过，可以参考 ISO的体系文档，先熟悉一下
---------------------
<项目管理与系统架构>
讨论群号: 179369939
[解决办法]
楼上几位有点纸上谈兵。
关键是一味求详细，时间开销承受不起。
比如说：你只有10个人月，如果一味求详细，需求说明书砸进去3个人月不成问题。
详细到一定程度后，要改的东西就越来越多，后面开销还有。
这样你就准备天天加班吧。
所以这是个尺度问题，大概可以把握几个关键点：
1.外部需求的对应项目要全，不能漏。
2.基本输入输出性的信息一定要全，要不然影响接下来的设计。
3.考虑投入时间，整个项目的20%以下会比较好。
4.考虑客户的偏好，组织结构等。
5.判断为可写可不写的不要写。
[解决办法]
这个东西开始时不要太详细，开发模型要是迭代的过程。
项目开始时，先做出一个粗略的需求，但要可能的需求都考虑进去，并且安可能的最复杂的情况考虑。系统设计的一个子需求，不用做得特别细，但要掌握它的复杂度和深度。
当然你说的文档，这就要不断完善，不同的阶段也会不同。
[解决办法]
如果需求说明书要作为合同附件以界定项目范围，那么必须对功能性需求尽可能的列举，但至于细节其实还可以不用写的那么详细
如果这个说明书要面向开发和客户的，那么这个文档实际上是起到开发者和客户之间的桥梁作用，个人倾向于楼上所说的迭代开发方式，因为需求不可能一次性就能说清楚，必定是在项目不断开展的中不断显露出来，一开始太详细没有必要，建议用用例的方式写
