选择接口文件的格式时，要注意考虑文件格式适应接口变更的能力
如果把各字段做成一行排列在一起，那么当中间某个字段的长度改变、或者在中间增删字段时，其后面所有字段的位置也都将改变，这个文件的解析程序就要大改 如果用XML的话，字段长度、增删字段都不会有这种问题，只不过数据量会大很多，在网络传输中可能会影响效率
需求分析时要考虑“超时”
对于一个很长的流程，务必要考虑 超时处理机制 最好能做到： 当发生超时后，系统可以自动处理，而不必让用户手动进行强制的、野蛮的操作(如强行叉掉窗口)。 超时的认定机制还分两种： 1.流程启动以后，过了一段时间后未看到预期行为，为超时 2.流程启动以后，在某个时间点后仍未看到预期行为，为超时
对“字段”规格进行需求分析时，要问清楚的地方
1.数据类型，字符串还是数字，还是日期 2.是否可能为空 3.如果为空，是""，还是NULL 4.如果是字符串，最大多少字节 5.如果是数字类型，是整数还是浮点数 6.如果是数字类型，是正数还是负数 7.如果是浮点数，精度是多少 8.如果是一些代号，那么可枚举的范围是什么？空用什么表示？代号大写还是小写 9.如果是货币，是什么币种，是以元为单位还是以万元为单位 10.如果是日期，格式是什么
一个教训：考虑文件名命名规则时，要注意特殊字符问题，如问号，星号等
如题 如题 如题
做字典相关的需求分析时要注意大小写问题
做字典相关的需求分析时，要确认用户对字典代号是否区分大小写
当用户平静地说“先。。。然后。。。再。。。”时
你应该想到： 这些步骤中，如果某个步骤失败，该怎么处理？ 如果要恢复，是从上次失败的地方开始，还是从另一个地方开始？ 如果没出过错，用户仍可以重新做一次吗？ 如果可以，用户可以选择从哪个地方重新做吗？ 用户可以在某个步骤结束或未结束时中止这个流程吗？
为什么要一直维护需求文档直至系统消亡？
因为它既是需求，也是对系统的功能说明；进行系统维护、更新的时候，只有它才能全面地反应系统到底做了什么
需求中遇到“空”的情况时，要确定处理办法
尤其是两个系统进行数据交互时，要注意这种问题 1.如果一条数据为空，是彻底给空，还是给一个只含主键的空记录，还是给一条错误信息？ 2.如果一个容器内的数据都空了，是彻底给空，还是给空容器？
凡是采用请求文件/应答文件作为批量接口的，最好约定一个附加健栏位
请求文件中每个请求都带这样一个栏位，应答则将这个栏位原样送还。这样可以让程序迅速地匹配请求和应答。 要用附加键，不要用业务键。因为随着需求的变更，原业务键可能要与其他的业务键形成联合键，也可能该业务键已失去作为键的资格
报错页面应该提供“返回”按钮
如题 如题 如题