请三位开发人员为“我们公司的一款应用”报价，您会得到三个无法比较的数字，因为每个人猜测的内容都不一样。一份清晰的应用开发需求书可以解决这个问题。它不必很技术化，也不必很长，只需要说明谁会使用这款软件、他们必须能做什么、它要连接哪些系统，以及上线之后会怎样。下面说明如何为网络应用、移动应用或两者兼有的项目撰写需求书。
应用开发需求书应当涵盖什么
把需求书当作第一次沟通的地图，而不是合同。对大多数项目来说，两到五页就足够了，内容应包括：
- 问题。现在有什么环节很慢、容易出错或根本做不到？“报价要花两天，因为价格分散在三张电子表格里”，比“我们需要一个报价应用”有用得多。
- 使用的人。谁会使用，大约有多少人，用什么设备。
- 目标。它跑起来之后会有什么不同：电话更少、开票更快、工作不再在办公室和现场之间丢失。
- 约束。真正的截止日期、预算范围，以及不能改变的系统。
无论您称之为定制软件还是定制网站和移动应用，需求书都是同一份文件，也是与任何开发人员首次会面的最佳准备。
用户角色与重要任务
大多数企业软件有几种用户角色，各自看到的内容不同：管理设置的管理员、处理记录的办公室员工、带着手机的现场人员，还可能有登录门户的客户。请为每个角色列出他们最常做的五到十项任务，用他们自己的话来写。“技术人员把工单标记为完成并添加照片”是一项任务；“工单管理模块”则不是。
请注明谁不能看到什么。权限在一开始设计要容易得多，上线后再补要难得多。
必备功能、后续功能与验收标准
把功能清单分成第一版的必备功能和其余的一切。第一版通常称为最小可行产品，应当是真实用户每天都能用的最小版本。等人们用起来、告诉您还缺什么之后，再给后续功能排序会容易得多。
为每个必备功能添加验收标准：用一句话说明您如何知道它能正常工作。“客户上传文档后，办公室能在工单记录中看到它并收到通知”可以测试；“方便的文档上传”则无法测试。验收标准也是判断某项功能是否完成的最公平的方式。
数据、系统集成与设备
- 现有数据。哪些需要从电子表格或旧系统导入，以及数据有多干净。
- 系统集成。会计、CRM、支付、邮件、地图或物流。请写明软件名称和数据流动的方向；这类连接很多都作为 API 集成工作，与应用本身一起处理。
- 设备和环境。办公室台式机、个人手机还是公司配发的加固手持设备；在室内还是在信号差的工地。如果人们必须离线工作，请写明，因为这会影响整个设计。
- 手机功能。相机、条码扫描、定位或推送通知，都倾向于选择安装在设备上的应用，而不是网络应用。
在浏览器中运行的定制网络应用，往往足以应付办公室任务，而当手机硬件或离线工作很重要时，定制移动应用才有用武之地。需求书不必做这个决定，只需提供能做出决定的事实。
账户、归属权与上线之后
归属权问题最好在还没有任何代码时就回答。需求书应注明，代码仓库、托管、域名和应用商店账户都属于您的企业。要以公司名义在 App Store 上架，就需要以组织身份注册，Apple 要求提供法律实体和 D-U-N-S 编号来验证；请参阅 Apple 的注册要求。Google Play 同样会验证组织账户，所以两者都要尽早着手。
也要为上线后的几年做好规划。手机操作系统每年都有一次大更新，商店里的应用需要更新才能跟上。定制移动应用和网络应用都需要托管、安全更新以及负责这些事的人，所以请在需求书中问明更新和支持将如何进行。在我们的定制应用项目中，文档、代码仓库的访问权限，以及更新和托管计划，都是交接的一部分。
常见问题：应用开发需求书
需求书需要写到多详细？
详细到两位开发人员想象出的是同一款软件。描述任务和结果，而不是界面和技术；好的开发人员会把这些转化为设计，并就空白之处提问。
需求书里要写预算吗？
写一个范围会有帮助。同一个目标可以用精简的第一版实现，也可以用功能齐全的版本实现，有了范围，开发人员就能提出合适的工作范围，而不是靠猜。
联系开发人员之前需要先画线框图吗？
不需要。粗略的草图或您喜欢的工具的截图很有用，但您不必自己设计界面。在我们的项目中，主要任务的可点击界面是在需求调研之后才出现的，并与真正使用软件的人一起评审。
有个流程已经超出了电子表格的能力？我们的定制网站与移动应用开发服务从需求调研和可点击原型开始，分阶段构建，并交付文档和代码访问权限，服务对象是洛杉矶 (Los Angeles)、长滩 (Long Beach) 及其他地区的公司。请把您的需求书发给我们，哪怕只是粗略的一份，并告诉我们谁会使用这款软件，以及它需要与哪些系统配合。
