前言：一般来说，软件产品的需求人员的主要输出物就是软件需求，如果这个软件产品就XX系统，人们口中的“系统需求”和“软件需求”就没有什么区别了。在车企行业，推行这ASPICE体系，在这个体系中明确申请了系统域和软件域，分别定义了系统需求和软件需求，那两者就有一些区别的。笔者作为一个开发转岗的软件需求，下文主要是在项目实战后结合《软件需求》的理论介绍，梳理出对于一名软需分析师，比较有益的编写指南。
1、 小故事
是不是有些小小的沮丧？？但这种情况确实又比较常见！既然不能做到完全避免，那如果降低发生的概率呢？
明确需求精确的程度，加强清晰的沟通，写出高质量的需求。
2、优秀需求的特点
这个问题可以从两个方面来看，需求项和需求集。
2.1 需求项的理想特点
（1）完整性
提供的信息可以让开发人员正确实现它，可以用TBD标识不确定项，并在过程中解决。
（2）正确性
用户代表应审查需求
（3）可行性
开发人员从技术角度检查实现的可行性，检查实现所需的时间、预算、人力等的可行性。
（4）必要性
每个需求都应源自一个有权提供需求的途径。
（5）优先级顺序
实现的先后顺序。
（6）无歧义
不可能消除需求里所有的歧义，但评审时有同事的帮助可以清除大多数更严重的歧义。
（7）可验证性
如不可验证，那是否正确实现将不是客观分析而是主观结果。测试人员擅长检查需求的可验证性。
从7个维度来思考需求项的要求，也可以看出“评审”的重要性。在实施本工作之前，总觉得评审就是审核结果的形式，重点在于过与不过。但是学习此部分内容后，根深刻的理解了它所带有的讨论意义，也是基于此更明白我们实际操作评审中为什么总是会有那么多耗时的讨，因为需求本身也是强烈依赖“评审”以完善的。以软需分析人员的一己之力是不能做出好的需求的，这个工作是带有团队合作属性的。
2.2 需求集的理想特定
（1）完整性
任何包含TBD的SRS都是不完整的。
（2）一致性
需求间如存在冲突，开发就要硬着头皮处理；记录每个需求的来源，不一致时找相关人员沟通。
（3）可修改性
每个需求都有唯一标识，这样在必须修改的时候可以无歧义地引用和找出它们。
（4）追溯性
回溯来源，向下追溯到设计、代码、测试。
需求集的理想特点，更倾向于整体的状态，以及域之间的追溯关系等。
永远不可能完美具备这些理想特点，但在写和评审时牢记这些，将得到更好的需求和软件。
3、需求编写指南
“套路”：
实践经历和来自相关者的反馈是最好的老师。
（比如：同行审查）
“目标”：
①任何阅读需求的人对需求理解一致；
②每个读者的理解与作者试图表达的一致
相比教条地使用规则和简介的风格，表达所产生的最终效果更重要。
3.1 角度
从系统或者用户的角度来描写，以明确行为主体是谁能做什么。
3.2 写作风格
3.3 细化程度
可以从“细节”和“粒度”两个维度思考细化程度问题，比如给外部客户的需求，细节上就应做到多场景；比如公司内部自研自用的，细节上就可考虑少场景；比如用少量用例就可以验证的需求可以粒度适宜即可，而需要大量不相关用例才可验证的，那就要拆分成粒度更细的场景。
3.4 表述技巧&避免歧义&避免不完整性
4、“优秀”举例
亮点：表格（信息清晰明确）、明确数字边界（无歧义）……
5、怎么做好需求？
近期在一个行业分享视频中看到这样一个答复“要做到会提问！”，确实是的。
怎么提问呢？
——软需格式就是一种笨但好用的办法，能保障基本信息不缺失。
软需格式：在XX情况下，XX模块/服务收到XX信号，进行XX的处理，输出XXX（如果有输出的话）。
——进阶款，就涉及到角色转换、经验等等。
依稀记得曾经在视频号看到的一个“需求挖掘”对话过程，略显搞笑，但是接近“崩溃”的追问。。。
后记：都说做需求很容易，但谁做谁知道，“痛苦程度”也要看个人的负责程度和公司的整体土壤。
与君共勉！
