如何编写高质量的需求说明书

【IT168 管理】

    一、 需求叙述的特性 

    1、 正确：每个需求必须精确描述要交付的功能。 

    2、 可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。 

    3、 必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。 

    4、 优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。 

    5、 明确：需求叙述的读者应只能从其得到唯一的解释说明，同样，一个需求的多个读者也应达成共识。 

    6、 可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。 

    7、 完整：不应该遗漏要求和必需的信息。 

    8、 一致性：一致性需求就是不要与其他的软件需求或高级别的系统（商业）需求发生冲突。 

    9、 可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。 

    10、 可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。 

    二、 实例

　 例1．“产品应在不少于每60秒的正常周期内提供状态信息”　　这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。 

    弥补缺陷，重写需求的一种方法： 

    1 状态信息 

    1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息。 

    1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比。 

    1．3任务完成时，应显示相关的信息 。 

    1． 4后台任务出错应该显示错误信息。 


    例2．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？ 

    试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。