● 需求分析和模块设计（划分）的没有本质的区别。模块设计产生的模块接口协议，可以作为具体模块的需求分析，小的需求分析可以看做是定义函数的输入输出和规则。

　　● 需求分析文档不是越细越好（设计文档更是如此）。细是需要编写和维护成本的，只要可能用到该需求分析文档的人能清楚理解功能的规则即可，相似的功能也可以“参考XXX功能”，简单的功能也可以省略部分要素，复杂的功能可能需要多种图示和多个测试用例辅助理解。

　　● 写需求文档的前提是设计系统解决方案（基于当前业务流程问题，设计新流程，创造价值）。但很多时候没有明确的系统解决方案文档，所以在需求分析文档中，常常包含了部分系统解决方案的内容。设计系统解决方案（下图中的0-业务）、需求分析，以及与软件过程的其他步骤之间的关系，见下图（供参考）。

　　● 缺少强有力的实际客户的反馈，需求分析有闭门造车的嫌疑。实际客户包括直接使用软件的人，也包括间接相关的人（如领导等等），每个人都有自己的利益，需要统筹考虑；客户的反馈和软件的改进是一个持续的过程，需要不断收集、分析、统计用户的意见和实际使用情况。

　　补充

　　用例结构（主要来自一UMLCHINA的培训材料）

　　1）用例名：执行者视角，动词 ( + 宾语)

　　2）执行者：在系统之外，透过系统边界与系统进行有意义交互的任何事物

　　　　● 系统边界：责任边界，非物理边界

　　　　● 任何事物：操作员、维护员、外系统、外部因素、时间

　　3）前置条件：开始用例前所必需的系统及其环境的状态

　　4）涉众利益：用例平衡涉众之间的利益，是涉众之间达成的契约