如何理解别人写的需求规格说明书？

    在开发过程中，开发人员、测试人员都需要阅读其他人写的需求规格说明书，当阅读别人的需求文档时，我们需要关注什么呢？参见下图的要点：

 

       首先需要了解关于该系统的总体信息，主要包含2条：

       1 明确出该软件与其他系统、人、设备的交互关系。可以通过环境图，帮我们梳理清楚该软件与周边环境的关系，从宏观上对软件所处的位置有所理解。如下图所示：

       2 系统的目标是什么，即解决了客户的哪些问题？或满足了客户最关注的需求是什么？

       如：

     断电管理系统的目标在于提高复电效率、改进客户服务、规范关键性能指标，并满足监管需求和工业最佳实践。

       这是总体上来把握系统的需求。

       上述两个问题回答了该系统是给谁用的？为什么要上本系统？

       

      其次来了解具体的功能需求，针对每个功能需求需要了解：

       1 该功能的输入信息是什么？

       输入的信息来源可能有多个？比如人、设备、其他系统等；

       正常的输入有哪些？

       异常的输入有哪些？

       2 该功能的输出信息是什么？或执行后的结果是什么？

       针对不同的输入，输出有可能有不同的结果。

       3 从输入到输出是如何转换的？

       这有包含2部分内容：

       1）业务逻辑是什么？

       对于业务逻辑的描述可以采用流程图、树状分枝图等来整理之。

       2）操作方法是什么？

       在此过程中，人做了什么，系统做了什么？人和系统的各自职责是什么？

       4 在从输入转换为输出的过程中，需要引用哪些信息？

       引用的信息是已经存在的，不需要在本功能中输入，只需要检索的信息。

       可以通过两栏式的用例描述或顺序图帮我们理解功能需求，例如

  

      再次来了解非功能性的需求，针对每个非功能性需求需要了解：

       1 这些非功能性需求是否可以量化表达？

       2 这些非功能性需求可以分配到哪个功能性需求上去？或者，哪些功能性需求必须满足哪项非功能性需求？

      

       最后要了解需求的优先级。

       需求的优先级可以分为需求级与特性级，特性是对需求的更细的描述，实际安排开发顺序时，应该从特性级的需求优先级着手，高优先级的先开发，低优先级的后开发。

      

       上述的这些信息都了解清楚后，就可以做软件详细设计与测试用例的设计了。

       在我们采用上述方法来理解需求时，能够发现需求存在的大量模糊性描述，有助于澄清需求，减少未来的需求变更。