©2020-2024 ioDraw All rights reserved,
Privacy Policy
需求规格书编写完成后如何让客户快速、顺利地确认签字？这是个常见问题，每个软件项目经理和需求工程师都遇到过，要解决这个问题要从甲方客户与软件工程师两个方面进行分析和找答案。
从客户方面看，存在两个问题：一是要看得懂需求文档、二是要能放心地签字。提出需求的客户可能不是软件方面的专家，他是从自己熟悉的业务视角提出的需求，但他可能不清楚这个需求实现后的应用模式（原型、操作等），担心自己考虑不周签了字，待开发完成后与设想不同时要担责任，所以迟迟不肯签字（人之常情）。
从软件工程师方面看，已经理解了需求、给出了方案，甚至做出了原型给客户演示，每个功能都是和客户确认过的，客户为什么还有担心而不敢签字呢？
回答这个问题前，再来确认一下需求文档的用途及要求。需求文档有两个基本用途：
■用途1. 需求文档是对用户提出需求的记录、分析、设计（业务）结果，是向客户确认需求和设计成果的依据，也是最终客户验收系统的依据；
■用途2. 需求文档是向技术开发工程师做系统需求交底的资料，是后续设计（技术）、开发、测试的依据；
也就是说这份文档需要同时满足两个方面的要求，即：客户及开发工程师。既要让客户看得懂（偏客户业务的表达）、还要让开发工程师能作为依据（偏软件专业的表达）。这就产生了矛盾。怎么解决这一对矛盾呢？
由于需求文档的内容较多，这里仅用原型的文档例子来说明如何做好需求文档并获得客户的确认和签字。可以根据客户业务的复杂程度，从三个层面向提出需求的客户进行说明。
一、记录形式的结构化
首先“需求规格书”的记录要采用结构化、标准化的形式，这个记录要做到对原型界面上的字段进行一对一的说明，由于是“一个字段、对应一条说明”，不存在有含义隐蔽的、难以理解的大段文字说明，这样客户就容易理解、确认，可下图所示的是一组记录需求规格内容的模板样例（需求规格书，简称4件套）。
注：需求规格书（简称4件套）的使用方法参见第13章功能的详细设计。其中：
■模板1—业务原型：给出界面业务内容的布局、字段的位置。
■模板2—控件定义：用表格方式记录所有字段的名称、字段内容、相关规则等。
■模板3—规则说明：用文章体的方式对该原型内的复杂规则进行详细的说明。
■模板4—逻辑图形：用图形方式表达该功能内用文字难以说明的复杂逻辑关系。
二、业务逻辑的验证
第一层的方法，是对每个原型内的字段、规则等进行了独立的描述，当业务逻辑、多原型之间的关系、业务场景等非常复杂时，仅仅给出单独的原型说明不足以让客户放心，这时可以增加“业务用例”的方式进行多原型的联合验证，以证明多原型间数据逻辑关系的正确，下图为业务用例的设计示意图。
注：业务用例导图的设计方法参见第21章用例设计。
三、应用场景的验证
需求记录的格式标准化了、原型间的逻辑关系清楚了，如果客户还不能完全放心的话，可以在最后进行“应用用例”的验证，应用用例可以向客户展示完成的系统外观是什么样、怎么操作、系统怎么运行、以及系统的易用性是否可以让不同岗位的用户满意等。
注：应用用例导图的设计方法参见第21章用例设计。
上述三个层面的内容说明，对复杂的系统仅仅有文字说明、原型有时还不足以让客户放心，还需要注意需求记录格式的可确认性、系统对复杂业务场景以及系统操作的适用性等。按照上述三个层面的要求做出的需求文档，把原型的功能从里到外都表达清楚了，客户应该可以放心地签字了。这样的记录形式不但满足了客户的签字要求，同时也符合续开发工程师对需求文档的编写粒度、质量的要求。（根据软件项目的复杂程度，确定是否使用业务用例和应用用例的验证）。
当然，还有一个对软件工程师非常重要的要求，那就是平时与客户建立起相互信赖的关系也是非常重要的，客户对你的专业水平、责任心的认可，在签字时也起着看不见的重要作用。
注：以上方法和图形的详细说明详见拙著《大话软件工程—需求分析与软件设计》一书。