需求最需要关注的是四个因素：人、数据/信息、流程、规则/约束。今天先说说人。
写文档时最先考虑的应该是谁？
教科书里总说，stakeholders，利益相关方，这里有很多人，可能是甲方公司里的所有人。如果需求方前期给的信息足够详细，动笔的时候应该能够列出核心的几个利益相关方，每个利益相关方的业务流程如何，甚至部分业务规则和相关的约束。有些业务流程非常复杂，细节很多，图文混合洋洋洒洒可以写上好几页，这些东西要不要都写上去？考虑到需求分析文档通常是项目方拿下项目的第一步，要注意，很有可能项目还不确定是自己的，做不做还不一定呢。通常这种文档的期限都比较短，一两天之内就要交差，如果提前已经有成型的段落图片积累还好，可如果完全从头开始，怎么才能用相对短的时间交一个还算像样的答卷？这时候在那么多的利益相关者当中更应该考虑谁的感受？
如果有人想找我做一个项目，简要叙述一下需要我做的功能，我首先关注的是，这个项目我能不能接，也就是根据对方提出的功能列表判断我现在有没有这些功能，没有的话实现难度如何，时间如何，划不划算。按着这个思路写下去，那写文档的投入产出比可能不高。甲方看这篇文档看的是，我（甲方的“我”）希望通过这个项目获得什么，这就有点像写BP，不是单纯写技术多牛，业务水平多高，而是让投资人从这里面看到投资回报。因此，如果对方想要流程优化，那就应该写出新旧流程对比，旧流程不足在哪里，新流程如何改进；如果要维护便利或安全性，那就得在非功能需求方面多费些笔墨；如果要信息透明度，那应该着重写数据可视化、统计分析；如果要操作方便，按互联网公司的流行做法，那应该是给个原型或视频，而不是给文档。文字不能简单地夸自己的产品或服务有多好，多棒，多与众不同，尽量避免使用副词、形容词，尽量列举出可量化的指标。就像写简历一样，泛泛地说自己“精通”“擅长”，不如拿出具体的项目成果、奖项、github账号。
所以，下笔前，要想想自己这篇文档的投资回报，再写写读者想要的投资回报。