软件产品需求规格说明书 需求规格说明书模板
如何评审需求规格说明书？
1. 完整性 不能遗漏任何必要的需求信息。
遗漏需求将很难查出。
注重用户的任务而不是系统的功能将有助于你避免不完整性。
如果知道缺少某项信息，用TBD （“待确定” ）作为标准标识来标明这项缺漏。
在开始开发之前，必须解决需求中所有的TBD项。
2. 一致性 一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。
在开发前必须解决所有需求间的不一致部分。
只有进行一番调查研究，才能知道某一项需求是否确实正确。
3. 可修改性 在必要时或为维护每一需求变更历史记录时，应该修订SRS。
这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。
每项需求只应在SRS中出现一次。
这样更改时易于保持一致性。
另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
4. 可跟踪性
用户需求说明书 与 需求规格说明书 有什么本质区别？
需求分析报告：一般是对某个市场或者是客户群来讲的，类似于调研报告，重点是体现出产品要满足哪些功能，哪些是重点、热点：用户的语言与设计人员的语言是不同的，需求开发指南等。
4，要解决什么问题 需求规格相对不是很重要、用户需求说明书是用户的需求 1，你可以有各种方案，这个是用户不关心的。
要是用户需求就已经理解错了，软件规格让用户签字好哪里放什么文本框用什么布局就没有任何意义了。
“需求管理”的文档大体上包含需求管理计划、需求检查表、需求跟踪表（包含矩阵图）：是根据与现场实际客户进行沟通，把客户的需求进行整理、需求变更状态跟踪表，更倾向于写用户需求。
需求说明书，误解的概率就越大。
权衡的结果：基本上是依据项目的规模而定。
3，重点是站在客户的角度讲产品功能，敏捷就取消、这主要看项目管理采用的规范，细一点偏向于软件的概要设计，所以需要有面向不同人员的文档。
缺点：层次越多，具体实现用户需求的时候。
需求管理的时候也需要用到用户需求。
2，信息损失的越多、如果要省掉一个的话，以及与其配套产出的指南型文件。
“需求开发”的文档大体上包含需求规格说明书，需求规格说明书检查表。
需求规格说明书，因为搞系统的时候要始终明白用户在想什么、 优点：是从业务规则讲起的。
如果是CMMI就需要，CMMI中有标准的模板。
是从开发、测试的角度去讲产品功能，里面要包含原型界面、业务接口，需要和用户确认的。
需求规格说明书是系统需求主要是对内的 ...
网站开发需求规格说明书怎么写？
如何理解“规格说明必须容忍不完整和可扩充”。
我们把描述需求的文档叫做软件需求规格说明书，同时为确切表达用户对软件的输入输出要求，还需要制定数据要求说明书及编写初步的用户手册。
需求规格说明书是用户和开发者之间的一个协约。
实际的需求获取过程中，存在若干风险，包括用户参与不足，需求不断增加，需求模棱两可等等，用户由于不明白需求分析的重要性，有时只做一份很简略的规格说明，仅涉及到产品概念上的内容，而希望开发人员在开发过程中去完善，这种情况下的规格说明势必不够完整，需要开发过程中双方不断完善和补充。
另一方面，由于在需求阶段，很多需求细节客户自己未必清楚，因此这一阶段也无法达成一个一成不变的规格说明，必须允许客户在开发过程中不断明确自己的需求，这就要容忍规格说明不完整和可扩充。
《软件需求规格说明书》的目的？
1 是否有需求与其他需求相互冲突或者重复？ 通常一份长达几百页的需求规格说明书都不会是一蹴而就的，它可能是系统分析师几个夜晚的心血之作。
正是因为撰写过程的连续性，可能导致同一份文档中前后名词定义不一致，前后观点上有重叠或差异的情况出现，这需要我们在撰写报告前首先要在思想上形成统一概念， 可使术语列表贯穿整份文档以达提纲挈领之效。
谈及此点，让我想起在“商机管理系统”需求评审会上，火眼金睛的用户们发现了我的需求说明书中关于系统用户角色定义部分出现了前后不一致的情况。
在该报告前文中我定义了该系统有二种角色，即“商机成员”、“商机管理成员”，但在功能需求中我的报告中居然新生出一种“商机监理”角色，导致出现尴尬局面。
事后总结其主要原因是在撰写报告的前期和后期阶段，需求分析的思路有了明显的异动，但却没有把文档前后更新一致，这个教训是深刻的，时至今日记忆犹新。
2 是否清晰、简洁、无二义地表达了每个需求？ “清晰”是让人能够读懂；“简洁”是让人愿意去读；“无二义”决定”读”的效果，是让大家对需求描述的理解能够达成一致 。
需求陈述是“三重门”，这三扇门是否开启决定了需求说明书的质量高低。
我们尤其要拒绝“二义性”的名词术语的出现， 似是而非的概念定义是需求书应该避免的。
换句话说，如果一份需求说明书没能给人以清晰、简洁和无二义的阐述，则需求评审是没有进行下去的必要，同时也无法进行下去。
需求评审的前提是用户读懂了需求说明，并且用户的理解内容就是分析师们所描述的内容。
3 是否每个需求都通过了演示、测试、评审，分析是否得到了验证？ 需求应该是可以测试的，通常通过测试去验证它是不是正确。
比如我们完成了“销售员客户佣金提成规则”需求的撰写，如果需求书未能经过原型测试通过，则需求评审是不能得到通过的。
面对相当复杂的业务需求，经过测试或演示是让用户信任的一个必要过程。
试想一下， 如果连需求都不能很好地被确认，则开发实现阶段更是没有把握控制了。
4 是否每个需求都在项目的范围内？ 划分项目范围和区分系统边界同样是需求说明书的一个任务，不要对需求书作出超范围的论述和延伸，要知道需求书不是分析师卖弄概念、展示时尚的场所，它是软件工程的一个重要环节。
5 是否每个需求都没有内容和语法上的错误？ 按照传统的需求列表方式，需求像菜单一样被一条条列出来，构成需求项的主要栏位包括：需求ID、 需求描述、优先级、来源和状态等。
通常需求首先要经过“拼写检查”，保证没有拼写上的问题，然后通过逐行浏览修改那些在内容或行文上出现问题的需求。
6 在现有的资源内， 是否能实现所有的需求？ 需求规格说明要考虑可行性的问题。
事实上，分析师的关注层面是价值驱动和成本驱动方面。
分析师应该明白不是所有的需求都要去实现，一些看上去很明显与涉及用户有冲突的、费力不讨好的需求应该果断地舍弃。
国内有专家提出，搞需求也要讲“和谐”即是此中道理。
举例而言，企业中的用户可分为三种类型：决策层用户、管理层用户、操作层用户。
每种用户所代表的价值取向是不同的，决策和管理层希望系统处理业务是业务安全优先的，而操作系统用户则是更多地考虑方便性的。
国内某电子贸易公司，从自身业务安全考虑，规定了系统不允许“借货”，意即代理商的产品直接发到客户根本不经过本贸易公司的物流部门。
如果操作层用户提出了这样的“借货”需求，倒是可以方便他的日常处理，但却违背了公司的根本利益。
很显然，这样的需求肯定是有所不为的。
7 每一条特定的错误信息，是否都是唯一的和具有含义的？ 不要忽视错误信息的定义， 它必须具有唯一性。
如果过于笼统地定义错误信息则和没有定义的效果是一样的。
-