要求功能需求的表述规格化。
特别需要说明的一点，在我看来，业务需求、用户需求、功能需求实际上是一样事物的三个视图，分别反映了三个不同视角所看到的景象。例如一个圆柱体，业务需求是从上向下看，用户需求则从外往内看，功能需求则是从圆柱体内部向外看。业务需求、用户需求、功能需求是对同一个事物的表述，因此天然具备概念完整性的特点。当然，需要在我们的需求分析活动中描述出来。
四、需求分析活动的文档
在软件项目组接触到这个项目的时候，通常业务需求已经明确，但用户需求还是非常混乱的。客户提交的需求描述文档混杂有业务需求、用户需求和功能需求。对大多数需求分析活动来说，首先分析用户需求，输出《用户需求说明书》，并提交给客户确认。在《用户需求说明书》中，建议加上对业务需求的理解，例如数据流图，让客户一并确认，并及时纠正理解不当的部分。
一般的，《用户需求说明书》已经可以作为设计活动的输入，但还不能作为编码实现活动的输入。《需求规格说明书》主要表述功能需求。按照标准说法，《需求规格说明书》还应当表述非功能性需求，但在实践中，这部分很少被关注，非功能性指标往往到了测试阶段才真正被重视。
《需求规格说明书》之"规格"，即要求格式化的表述，以便在软件开发过程中不产生歧义。一般使用表格方式，以强制文档作者必须填写所有内容：用例编号(唯一确定需求)、用例操作简要说明、前置条件、操作结果(分为成功、失败)、操作者(角色)。