解决需求问题需要考虑的地方
1、 为什么要开发这个系统？
a) 这个系统的目标（Visions）是什么？这个目标可以衡量吗？比如用具体的时间或金钱来衡量。
b) 目前的业务状况如何？系统必须达到什么程度才算没有白上？
c) 客户对使用系统前和使用系统后的不同或应有的区别心里是否有数？
2、 系统涉及到的人员对系统分别有何要求？（销售系统为例）
a) 客户，没有该系统，客户也可以正常提交购买请求，那该系统到底带给他们什么？
b) 销售者，希望系统为他们解决什么问题？
c) 管理者，系统是否帮助他们更好地决策？
3、 需求分析是否写出有价值的东西？是否捕获到真正需求？
a) 文档规范不规范不是主要问题，需求是否正确捕获？
b) 所有假设出来的角色，是否有存在真正价值？
c) 所有隐含的系统需求是否都是为Visions服务？
d) 用例是否有存在的理由？防止需求的蔓延。
e) 所有“非必要的需求”是否都已经得到充分验证？（如一些“权限管理”）
4、 用例的确定。
a) 所有的“前置条件”和“后置条件”是否可以判断？这2个条件都应该是一种“状态的描述”而不是“动作的描述”。比如应该使用“用户已经被注销”而不是“用户退出系统”来描述“退出登陆”。
b) 所有的“涉众利益”是否都考虑到？如果系统突然无法正常运作，哪些人的利益将受损害？
c) 用例是否能够形成一份所有相关人员就系统的行为所应达成的“契约”？
d) “涉众利益”是否是真实的？必须是涉众自己提供的才是真实的，由设计者“假设”的涉众利益是不真实的。
e) 只要满足前置条件，按路径走，是否一定会达成最终的后置条件？
f) 路径描述中是否存在无法验证的词汇，如“明显的”，“美观的”？
g) 每一步是否都包括了“执行者做什么”和“系统做什么”并区分开来？
h) 是否正确区分开“设计”和“需求”？“如果不这么做，涉众的利益将受到损害”，那么这个就是需求，只有“需求”需要和用户讨论，“设计”不应该与用户讨论。如果用户明确提出该如何“设计”，那么该“设计”应被列为“需求”而不是“设计”。
i) 不要在任何路径描述中带有“暗示性需求”，比如“用户点击一条记录”，暗示了“用户要用‘点击’来选择”，应该使用“用户选择一条记录”，即使用户明确表明要用“点击”，也不应该写在这里。
j) 讨论用例应该多详细没有意义，用例应该尽可能“真实”，而不是尽可能“抽象”或尽可能“具体”。
每个用例是否提供了完整的价值？如果没有，那它应该是其他用例的一个部分而不是单独一个用例，如“查看任务”作为一个用例只有当员工可以对老板说：“今天我的工作是一共查看了N个任务”时才成立，否则它必须作为其他用例的一部分。
http://syeerzy.netyi.net/blog/user1/16/archives/2005/255.html