当用户轻描淡写地谈到“卡”时，你必须打断她，并问道： 1.包括贷记卡和准贷记卡吗？ 2.包括人民币卡和其他币种卡吗？ 3.包括主卡和附卡吗？ 4.包括正常卡和已销户卡吗？ 当用户轻描淡写地谈到“卡数”时，你必须打断她，并问道： 1.包括贷记卡和准贷记卡吗？ 2.包括正常卡和已销户卡吗？ 3.主卡和附卡合起来算几张卡？ 4.双币卡算几张卡？那种只有美元币种而没有人民币种的卡怎么算？ 当用户轻描淡写地谈到“账户数”时，你必须打断她，并问道： 1.指的是卡总数，还是开户机构总数？ 2.如果用户在某开户机构开的卡都销掉了，这个账户数还计入吗？ 当用户轻描淡写地谈到“额度”时，你必须打断她，并问道： 1.是用户额度还是某张卡的额度？用户额度怎么算？ 2.是各张卡的额度总和，还是各张卡中的最高额度？ 3.如果用户爸爸给了用户一张附属卡，附属卡额度是否与我们正在谈的“额度”有关？ 4.已销户卡的额度算不算进来？ 5.如果用户的卡是双币卡，这个额度以哪个为准？ 6.如果用户只有 美元卡，这个额度怎么算？
如果把各字段做成一行排列在一起，那么当中间某个字段的长度改变、或者在中间增删字段时，其后面所有字段的位置也都将改变，这个文件的解析程序就要大改 如果用XML的话，字段长度、增删字段都不会有这种问题，只不过数据量会大很多，在网络传输中可能会影响效率
对于一个很长的流程，务必要考虑 超时处理机制 最好能做到： 当发生超时后，系统可以自动处理，而不必让用户手动进行强制的、野蛮的操作(如强行叉掉窗口)。 超时的认定机制还分两种： 1.流程启动以后，过了一段时间后未看到预期行为，为超时 2.流程启动以后，在某个时间点后仍未看到预期行为，为超时
1.数据类型，字符串还是数字，还是日期 2.是否可能为空 3.如果为空，是""，还是NULL 4.如果是字符串，最大多少字节 5.如果是数字类型，是整数还是浮点数 6.如果是数字类型，是正数还是负数 7.如果是浮点数，精度是多少 8.如果是一些代号，那么可枚举的范围是什么？空用什么表示？代号大写还是小写 9.如果是货币，是什么币种，是以元为单位还是以万元为单位 10.如果是日期，格式是什么
如题 如题 如题
做字典相关的需求分析时，要确认用户对字典代号是否区分大小写
你应该想到： 这些步骤中，如果某个步骤失败，该怎么处理？ 如果要恢复，是从上次失败的地方开始，还是从另一个地方开始？ 如果没出过错，用户仍可以重新做一次吗？ 如果可以，用户可以选择从哪个地方重新做吗？ 用户可以在某个步骤结束或未结束时中止这个流程吗？
因为它既是需求，也是对系统的功能说明；进行系统维护、更新的时候，只有它才能全面地反应系统到底做了什么
尤其是两个系统进行数据交互时，要注意这种问题 1.如果一条数据为空，是彻底给空，还是给一个只含主键的空记录，还是给一条错误信息？ 2.如果一个容器内的数据都空了，是彻底给空，还是给空容器？
请求文件中每个请求都带这样一个栏位，应答则将这个栏位原样送还。这样可以让程序迅速地匹配请求和应答。 要用附加键，不要用业务键。因为随着需求的变更，原业务键可能要与其他的业务键形成联合键，也可能该业务键已失去作为键的资格