在做MIS项目的时候，经常会碰到没有界面的需求，我们把它们定义为上不了台面，但又不得不做的需求，如：
- 外部接口数据导入后的业务处理
- 对外开放接口，走Web Services协议
- 定时自动做备份
- 定时后台发消息
- 为满足一个非功能性需求而做的二次开发
……
这些需求，我们要把它们纳入到需求规格说明书的功能列表和分册中，一方面在开发中是需要清晰明确的，另外一方面也满足我们对需求的全面管控要求。
找到的例子是关于证券行业开放式基金业务的接口数据处理，这个需求主要特点是：
- 接口说明是基金公司发布的，已有官方解释
- 有个界面已经处理接口数据的读入，但不对业务数据进行加工处理
- 客户需要知道这些业务数据在系统中是如何体现的
- 没有界面，业务数据是在后台做加工
- 做需求是绕不开它，必须要写明白
- 处理的时候又是分散在各个功能模块中
一、首先看需求规格说明书-功能列表：
因为没有界面，所以上不了台面，只能委屈这个需求的功能模块、一级菜单为空，从二级菜单开始填写。接口数据中包含基金的申购，这个业务在系统中有4个功能要对它做处理，分别为：股份数据处理、资金数据处理、股份变动流水的生成和代理费处理。
如果只涉及一个需求的话，这种情况在以后的详细设计报告很好处理，在详细报告中就独立出一个目录来写。如定时XX任务。
如果分散到很多模块处理的话，会比较麻烦一些，只能在各自涉及到的功能模块目录中填写。如本例。
二、然后看需求规格说明书-分册：
- 1. 目录
- 2. 内容
2.1. 基本业务描述
2.2. 主要功能特性列表，这个列表体现的是，在系统处理业务的时候，在什么时间什么地点，按什么流程，如何处理这些接口业务数据
2.3. 功能列表中涉及需求的描述，这里只有展现一个，即F5.1基金申购确认股份数据处理功能，其中业务规则1代表要处理的数据范围，业务规则2代表处理后的结果。如果业务有算法要求，也在业务规则中描述。
三、最后说说详细设计报告中是如何体现（这个没有截图，只是说明一下思路）
针对本例情况，在详细设计报告中是这么处理的：
1、接口数据的读入是在一个有界面的模块中设计。
2、使用了几个存储过程来处理在功能列表中涉及需求的调用。
3、在报告中设专门的目录来填写这几个存储过程的功能描述、参数定义以及处理逻辑
4、在涉及需求的界面功能中，其处理逻辑部分申明调用这些存储过程的时机
5、如果没有使用存储过程的话，在涉及需求的界面功能上，在其处理逻辑部分直接描述即可
