项目前期会需要进行需求、目标、范围等的确认，同时在这当中，我们总是会强调要将确定好的内容进行书面签字确认，所以也就是说，项目组要提前将内容进行撰写。
同理项目需求管理也需要有这些操作流程，在进行需求管理时，关于文本撰写这一块也是有其具体讲究所在。下面就将说说到底应该怎样进行需求文档的撰写与修正。
一、初步需求文本撰写
需求类别和模板确定之后，就要分配给项目相关负责人去撰写需求。对中大型项目来说，撰写需求说明书的人应该有多个，所以需要切分工作任务。
切分的原则是：每个任务尽可能独立，任务的安排尽可能并行;每个任务必须要确定完成时间，如果时间不满足项目进度，需调配其它人力资源进行协助;有些项目比较特殊，可能现有项目成员的专业能力无法覆盖，此时需要引入外部专家或者将这部分任务外包出去。
为了把控需求收集的进度，需求撰写计划中要安排几个检查点。假如需求撰写的排期是1个月，那么就可以设置3个检查点。每到一个检查点，各个需求撰写人需将成果汇总到项目经理手里做审查，根据审查的意见或建议迅速调整或整改。
二、内容审查签字确认
当需求文档完成审查之后，即可交付给业务负责人做确认。为了加速业务负责人确认需求文档的时间，可以邀请业务负责人参加需求评审会，或者讲述一遍业务需求，然后再让业务负责人线下确认，如果有修改意见，可约定邮件或者备注形式反馈，同时要跟对方说清楚确认完成时间。
三、反复讨论认证修改
当业务在确认需求说明书的过程中有反馈意见提出时，需尽快讨论并确认意见的合理性，对合理的需求需尽快更新到需求说明书中，再次提交确认，必要时可能需要再次访谈。
例如，自己从业务入手，整理业务的流程，画出业务流程执行的yes线和no线，no线其实就是可规划的几个产品方向。然后针对不同的产品方向做进一步评估，看哪一个方向是眼下可行性最高，价值最大的。拿着选定的产品方向思路，和业务相关的同事去验证，看这个产品是否对她们业务有帮助，在这个过程中，逐渐就明确需求了。
项目需求文档既不属于技术文档也不属于个人报告类，因为需求是客户提出的“想法”，也是项目组之后实现目标的“来源”，因此大家在撰写需求文档时，既需要条理客观，也要经过思维分析后的描述，同时还要注意其中的语言色彩既要让大家能明确知晓是要做什么，又不会容易产生理解误差。
而且就像需求本身也不是一次就能确认的，需求文本作为需要大家明确确认的文档事实，更是如此。