需求最需要关注的是四个因素：人、数据/信息、流程、规则/约束。今天先说说人。
写文档时最先考虑的应该是谁？
教科书里总说，stakeholders，利益相关方，这里有很多人，可能是甲方公司里的所有人。如果需求方前期给的信息足够详细，动笔的时候应该能够列出核心的几个利益相关方，每个利益相关方的业务流程如何，甚至部分业务规则和相关的约束。有些业务流程非常复杂，细节很多，图文混合洋洋洒洒可以写上好几页，这些东西要不要都写上去？考虑到需求分析文档通常是项目方拿下项目的第一步，要注意，很有可能项目还不确定是自己的，做不做还不一定呢。通常这种文档的期限都比较短，一两天之内就要交差，如果提前已经有成型的段落图片积累还好，可如果完全从头开始，怎么才能用相对短的时间交一个还算像样的答卷？这时候在那么多的利益相关者当中更应该考虑谁的感受？
如果有人想找我做一个项目，简要叙述一下需要我做的功能，我首先关注的是，这个项目我能不能接，也就是根据对方提出的功能列表判断我现在有没有这些功能，没有的话实现难度如何，时间如何，划不划算。按着这个思路写下去，那写文档的投入产出比可能不高。甲方看这篇文档看的是，我（甲方的“我”）希望通过这个项目获得什么，这就有点像写BP，不是单纯写技术多牛，业务水平多高，而是让投资人从这里面看到投资回报。因此，如果对方想要流程优化，那就应该写出新旧流程对比，旧流程不足在哪里，新流程如何改进；如果要维护便利或安全性，那就得在非功能需求方面多费些笔墨；如果要信息透明度，那应该着重写数据可视化、统计分析；如果要操作方便，按互联网公司的流行做法，那应该是给个原型或视频，而不是给文档。文字不能简单地夸自己的产品或服务有多好，多棒，多与众不同，尽量避免使用副词、形容词，尽量列举出可量化的指标。就像写简历一样，泛泛地说自己“精通”“擅长”，不如拿出具体的项目成果、奖项、github账号。
所以，下笔前，要想想自己这篇文档的投资回报，再写写读者想要的投资回报。
标签：为什么,很难,项目,流程,甲方,文档,如果,应该 来源： https://blog.51cto.com/13093181/2353237
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。