为了避免需求遗漏或整理误解，需求方和开发商需要集中完成需求分析。
需求分析可以在合同需求的基础进行，但必须包含以下部分：
用例文档
功能的需求说明
非功能的需求说明
需求跟踪矩阵，保证需求变更的及时性
需求分析成果必须经过使用部门的审核，才能归档备案。
数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式
⑴对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由；
⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；
需求类型：可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；
⑵使需求符合系统的整体目标；
⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
假如客户并未去认真搜集最终用户的需求，开发方便需要做到这一点，因为系统最终要满足最终用户的需求。
可以使用第四代语言（例如Visual Basic、Delphi等）来快速生成用户界面，也可以使用FrontPage等网页制作工具来生成用户可视的页面流。 原型的目的往往是获取需求。但有时也使用原型的方式来验证关键技术或技术难点。对于技术原型，界面则往往被忽略掉。