需求说明书该不该写的很详细？

[pisces_008]

需求说明书一般都是这样写的：
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个字符”


还是说，在写需求的时候，需要把功能中的字段类型、长度限制等约束全部需要加上
请问大家是如何写需求文档的呢？
能否提供需求文档以供参考

[luyun2011]

用尽可能简短的语言写得越详细越好啊，让开发者明白你到底要实现怎样的功能，以在最短时间内尽可能达到客户的需求

[mingpei0703]

一般都要求比较详细，同时又要不显得啰嗦！

[leezy_2000]

楼上几位有点纸上谈兵。
关键是一味求详细，时间开销承受不起。
比如说：你只有10个人月，如果一味求详细，需求说明书砸进去3个人月不成问题。

详细到一定程度后，要改的东西就越来越多，后面开销还有。
这样你就准备天天加班吧。

所以这是个尺度问题，大概可以把握几个关键点：
1.外部需求的对应项目要全，不能漏。
2.基本输入输出性的信息一定要全，要不然影响接下来的设计。
3.考虑投入时间，整个项目的20%以下会比较好。
4.考虑客户的偏好，组织结构等。
5.判断为可写可不写的不要写。

[数字巫师]

首先应看到需求说明书的目标阅读对象是谁
如果只是项目组内部，则简洁概要性的描述，只为需求定性、需求索引
更多的精力放在设计阶段

如果用于给客户签字，则必须足够详细，避免二义性以及争议
如果之前没写过，可以参考 ISO的体系文档，先熟悉一下



---------------------
<项目管理与系统架构>
讨论群号: 179369939

[yijianxuan1203]

必须详细，用尽可能简短的语言写得越详细越好，让开发明人员明确的知道要实现怎样的功能。否则开发成本要提高

[pisces_008]

有没有相关的模板可以让我看看啊

[_三皮_]

不一定很详细，但要把握尺寸，在下面2点找个平衡点，说明书是否详细要看QA的要求的。
1、要为客户着想，最终软件要是客户想要的功能。
2、要为项目组着想，hold住项目实现有困难的功能

[疯魔症]

这个东西开始时不要太详细，开发模型要是迭代的过程。
项目开始时，先做出一个粗略的需求，但要可能的需求都考虑进去，并且安可能的最复杂的情况考虑。系统设计的一个子需求，不用做得特别细，但要掌握它的复杂度和深度。
当然你说的文档，这就要不断完善，不同的阶段也会不同。

[pisces_008]

[Quote=引用 7 楼 zwb0540822 的回复:]

这个东西开始时不要太详细，开发模型要是迭代的过程。
项目开始时，先做出一个粗略的需求，但要可能的需求都考虑进去，并且安可能的最复杂的情况考虑。系统设计的一个子需求，不用做得特别细，但要掌握它的复杂度和深度。
当然你说的文档，这就要不断完善，不同的阶段也会不同。
[/Quote]
你的意思是需求可以稍微写的糙一点，但是我们这项目时需要外包的
需求必须得详细吧？
如果是自己研发，当然在详细设计的时候，可以在详细描述
但是，需求是不是还是需要竟可能的详细？

[pisces_008]

[Quote=引用 8 楼 sudianbo 的回复:]

不一定很详细，但要把握尺寸，在下面2点找个平衡点，说明书是否详细要看QA的要求的。
1、要为客户着想，最终软件要是客户想要的功能。
2、要为项目组着想，hold住项目实现有困难的功能
[/Quote]

需求当然是要客户所需要的功能
为了项目组着想，需求就更应该详细啊
比如，用户名，长度是多少，汉族和少数名族的名字不一样吧
需求，是不是还是需要详细，尽可能的减少沟通成本？

[spgoal]

如果需求说明书要作为合同附件以界定项目范围，那么必须对功能性需求尽可能的列举，但至于细节其实还可以不用写的那么详细
如果这个说明书要面向开发和客户的，那么这个文档实际上是起到开发者和客户之间的桥梁作用，个人倾向于楼上所说的迭代开发方式，因为需求不可能一次性就能说清楚，必定是在项目不断开展的中不断显露出来，一开始太详细没有必要，建议用用例的方式写

[黑泡泡选手]

嗯，楼上说得不错，想迭代开发而不可得，无奈矣！