需求说明书该不该写的很详细？解决方案

需求说明书该不该写的很详细？
需求说明书一般都是这样写的：
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.判断为可写可不写的不要写。
------解决方案--------------------
这个东西开始时不要太详细，开发模型要是迭代的过程。
项目开始时，先做出一个粗略的需求，但要可能的需求都考虑进去，并且安可能的最复杂的情况考虑。系统设计的一个子需求，不用做得特别细，但要掌握它的复杂度和深度。
当然你说的文档，这就要不断完善，不同的阶段也会不同。
------解决方案--------------------
如果需求说明书要作为合同附件以界定项目范围，那么必须对功能性需求尽可能的列举，但至于细节其实还可以不用写的那么详细
如果这个说明书要面向开发和客户的，那么这个文档实际上是起到开发者和客户之间的桥梁作用，个人倾向于楼上所说的迭代开发方式，因为需求不可能一次性就能说清楚，必定是在项目不断开展的中不断显露出来，一开始太详细没有必要，建议用用例的方式写