title: 软件需求编写指南 date: 2017-12-06 05:56:57
 来源：IEEE830-1998(编写指南)
软件需求规格应该包含的范畴
功能性需求 外部接口 性能需求 属性 设计约束 来源：IEEE830-1998(编写指南)章节 4.2
应该定义所有的软件需求 不应该定义设计实现的细节 不应该对软件施加额外的限制，专注于软件需要做什么 来源：IEEE830-1998(编写指南) 应当尽量避免在软件需求规格中编写设计想内容，应当明白，需求是设计的约束条件而不是设计本身。 来源：IEEE830-1998(编写指南)
需求的描写应该是以业务为导向，而不要刻意去划分软件模块，这是软件设计应该做的事情 也不要将某一功能制定到某一功能模块 模块之间的信息或控制流 数据结构 通信协议，除非有特殊要求，否则不应该描述通信协议的具体要求出现了这些设计相关的内容时，说明软件需求规格已经越俎代庖了，这时应该考虑的是软件需求细化过度。
 来源：IEEE830-1998(编写指南) 什么情况下应该将设计写入到需求？只有在某些特定的，对设计有特别要求的情况下，比如网络安全采用的加密方式、性能上的限制、开发标准约束、软件质量约束等。这种情况下，这些需求应该独立成单独的条目或章节。
 来源：IEEE830-1998(编写指南) 好的软件需求的特性是：
正确的，保证软件需求与上级需求是一致的，不冲突的；无二义性的，软件需求应该是清晰的，明确的，没有歧义的，如果存在文字上的多义性，可以使用定义来加以说明；完整的，不要漏掉任何需求或必要的信息，如果对于没有思考清楚或没有调研清楚的需求，可以在归档前使用TBD，但不要在任何归档的需求规格中使用TBD；前后一致无冲突的，需求规格文档内部是一致的，不冲突的；有优先级的，软件需求应该具有优先级，以便进行项目开发的管理；可验证的，所有软件需求都应该是可以编写测试用例的，避免主管描述，如果测试工程师无法根据需求编写测试用例，也就无法进行验证的，说明需求分析不到位；可修改的，需求需要降低内部的聚合性，也就是一个需求条目不应该聚合太多内容；可跟踪的，需求应该具备可追踪性，最基本的方法是要保证需求都具有唯一的ID，同时要避免多个需求合并为一条需求描述。需求规格应该细化到所包含的信息刚好够开发人员和测试人员正确实现的程度，不要因为信息过少而让开发人员和测试人员无所适从，也不应该出现不必要的内容和说明。
“应该把需求细化到什么程度？”这个问题是没有一个简单而正确的答案的。需求细化的目标是让需求理解错误的风险最小化。因此需求编写的细化程度可以根据团队成熟度来决定，团队成熟度越高或有前例可循，则包含的细节可以少一些；如果团队成熟度相对较低，比如说新员工或出现跨地域团队等情形，需求中应该包含更多细节。当然细节的多少并不是说需求中能够缺少必要的需求规格要求，如范围等。
转载于:https://www.cnblogs.com/peapon/p/ruan-jian-xu-qiu-bian-xie-zhi-nan.html
相关资源：软件需求说明书编写规范