为什么要一直维护需求文档直至系统消亡？
因为它既是需求，也是对系统的功能说明；进行系统维护、更新的时候，只有它才能全面地反应系统到底做了什么
Architecture
接口文件的字段规格表中要写好每个字段的序号
要不然万一数起来会死人
系统设置除了写在配置文件里，也可以写在数据库里
而且如果写在数据库里，可以通过友好的UI界面直接进行修改
两个系统如果共用一套用户，要注意是否为一对一
要注意是否存在精确的一对一关系 假设两个系统分别为系统A和系统B 1.A中的某个用户在B中一定有吗？ 2.A中的用户Jude在B中也叫Jude吗？ 会不会冒用？ 3.A中的用户Jude在B中仅对应一个用户吗？ 会不会对应多个？
一种常见的需求变更：是/非模式 变成 0/1/…/N模式
原需求： 如果A， 则 不 杀人；否则，杀人. 新需求： 如果B=1， 杀一次人； 如果B=2， 杀两次人； … 如果B=N, 杀N次人； 原需求只区分了 是 和 非， 没有量化，如果量化，也只是 0 和 1. 所以，当客户以 是 和 非的 模式提出需求时， 我们要主动地问他这个东西有没有可能拓展为 0,1….N的模式。如果代价不大的话，就算客户当时认为 是/非 模式够用， 我们的系统最好也要实现为后一种模式。因为前一种模式蕴涵了后一种（前一种是后一种的特殊情况），反之不然
当用户平静地说“先。。。然后。。。再。。。”时
你应该想到： 这些步骤中，如果某个步骤失败，该怎么处理？ 如果要恢复，是从上次失败的地方开始，还是从另一个地方开始？ 如果没出过错，用户仍可以重新做一次吗？ 如果可以，用户可以选择从哪个地方重新做吗？ 用户可以在某个步骤结束或未结束时中止这个流程吗？
当用户提出业务规则时，我们要注意NULL问题和不在值域问题
1.NULL问题 规则：“如果三个月内有一次逾期，那么。。。” 问题是，如果前2个月的逾期信息为空，那怎么办？ 这不仅是一个预防空指针的问题，而且还是一个需求问题 2.不在值域问题 规则：如果当前逾期，那么。。。 问题：如果当前逾期的标志不是M0-M6,而是 “侬好”，怎么办？
注意：“满X月”、“未满X月”之类的需求要进一步精化
要考虑“月”的认定办法，以及边界情况 要确定采用哪种算法： 1.直接用天数来算。 比如90天就算3个月 2.对月份进行加减，而日份不变。比如 2月1日到3月1日就是一个月，虽然这个月只有28/29天。如果用这种算法，还要注意月末日期溢出的问题，比如3月31日 的下一个月是 4月30日，还是5月1日？(p.s.采用java.util.Calendar API可以保证不会溢出，3月31日 的下一个月就是 4月30日) 还要注意的问题是：边界情况。 如6月2日到7月1日是否满一月，6月2日到7月2日是否满一月
《软件需求》读书笔记
《软件需求》，Karl E.Wiegers著 1 总论 一定要编写需求文档 需求的三个层次（从高到低）： 1. 业务需求，最高层次的目标要求 2. 用户需求，Use Case 3. 功能需求，必须实现的软件功能 优秀需求的特性： 1. 完整性 2. 正确性，一致性 3. 可行性 4. 必要性 5. 划分优先级 6. 无二义性 7. 可验证性（根据需求能否写出测试用例） 8. 可跟踪性 需求工程的结构： 1. 需求开发，分为四个步骤 a) 问题获取(elicitation) b) 分析 c) 编写规格说明 d) 验证(评审，编制测试用例) 2. 需求管理，即需求追踪、变更控制等 需求文档是用户和开发组之间的契约，对双方同时形成约束 2 需求开发 建议需求开发过程： 1. 定义项目的视图和范围 2. 确定用户类 3. 在每个用户类中确定适当的代表 4. 确定需求决策者和他们的决策过程 …
做字典相关的需求分析时要注意大小写问题
做字典相关的需求分析时，要确认用户对字典代号是否区分大小写