业务分析人员将创建大量文档，以指导系统的设计，实施和维护阶段。文件有不同，包括业务需求文档（BRD），功能需求文档（FRD），系统需求文档（SRD），项目愿景文档，需求管理计划等。此外，业务分析师可能会为RFP的形成做出贡献，对合同进行验证和评论，并撰写用户手册和其他有关解决方案的说明性文件。
用例描述通常包含以下信息：
- 用例标识符
- 角色（主要和辅助）
- 前提条件
- 后置条件
- 主要成功方案
- 异常路径
- 替代路径
典型的功能需求包含以下结构：
- 条件（如果、何时、同时、在什么期间内等等）
- 主题Subject
- 命令词语（应该，应当，必须等）
- 主动动词
- 目的
- 规则（可选）
- 结果（可选）
功能需求可能看起来像这样：
输入供应商编号[条件]时，只要供应商是当前[业务规则]，系统[主题]就会[命令]在[对象]屏幕上显示[活动动词]供应商名称和地址。 ]进行视觉验证[结果]。
使用用户故事时，将应用相同的方法。用户故事通常具有以下格式：
作为[用户类型]，我想要[某些特定功能]，以便[获得一些好处]。
上面的需求可能呈现为以下用户故事：
作为应付帐款凭证输入者[用户类型]，我希望在输入卖方编号[功能]时显示卖方名称和地址，以便可以直观地验证是否输入了正确的卖方编号[收到的收益]。