前言
之前看过一些系统分析相关，偏信管、软工专业的书：《系统分析与设计方法》，《软件需求》。 需求工程 部分对实际开发工作有不少帮助。相信很多开发也不太了解信管或者软工，更多关注于具体领域的前沿技术，所以这些概念应该能用到。
文中部分是引用书中原文，部分是个人观点。文中产品，软件，系统是类似的含义。
2020.7.10 —— by zz。
需求
需求一词的字典义是“被命令或强制性的东西；需要或者必要”，和软件中的需求不一样。下面给出两个软件需求的定义
-
《软件需求》书中的需求定义：
-
需求是对我们应当执行的任务的规范说明，他描述系统的行为特征或属性，可以是一种对系统开发进程的约束。
-
(1)用户解决问题或达到目标所需的条件（ condition ）或能力(capability)。
-
(2)系统或系统部件要满足合同、标准、规格（c ontract, standard,specification ）或其它正式规定文档所需具有的条件或能力。
-
(3)一种反映上面(1)或(2)所描述的条件或能力的文档说明。
这些两个定义的共同点在于 需求 是对软件的行为、特征、属性进行描述，对开发进程约束的说明。
需求的层次
需求的层次从宏观到具体分为 业务需求，用户需求，系统需求。
-
业务需求
-
业务需求描述用户对系统的高层次的目标要求，关联到客户有哪些业务目标要完成。
-
比如需要降低某个业务成本，或抓住一个市场机遇。
-
以住房为例，居住就是最终目的。
-
对应出资人，用户公司的市场/业务部门
-
用户需求
-
描述的是用户使用产品完成的具体目标，对应到在一个用户场景（scenario）下具体可以做什么。
-
具体需要完成的事对应到“用例”。
-
比如 完成对季度营收的分类分析
-
以住房为例，睡眠，做饭就对应不同的场景，建筑师基于场景设计独立的房间。
-
对应使用软件的终端用户
-
系统需求
-
从系统的角度说明的需求，包括功能需求，非功能需求，设计约束。
-
功能需求指用户用来完成任务的功能，往往以动词描述
-
多个相关的功能组合组成了特性(feature)
-
非功能需求指除了功能需求以外的部分。其中一部分是一些属性，往往以形容词描述。另一部分是用户不会作为功能指定，但需要作为对系统要求的一部分。
-
包括软件质量属性： 性能、可用性、安全性、可修改性、可维护性、易用性、可测试性等等
-
系统环境相关的属性：可移植性，系统环境兼容性、历史数据兼容性等等
-
技术组件，外部系统，架构设计带来的技术性需求
-
-
-
设计约束指一些直接约束系统的限制条件，如licence，预算。设计约束也可以看做一种非功能需求。
-
如支持的SQL功能，性能，是否运行在国产化硬件等。
-
以住房为例，是否有纱窗，纱窗是否耐用，是否国产材料等。
-
对应开发人员。终端用户对这些的关注应该尽量减少。
需求层次的划分并不是严格的，业务需求内部也分很多层次。需求层次划分主要的目的在于
-
“用户” 群体内部分为不同的层次，也存在公司内部层级与不同职责。不同人群关注不同的层次需求。
-
用于分解并用户需求，形成便于处理的需求结构
-
以业务需求是否完成作为用户的最终目的。
-
以用户需求划分场景，可以对于每个场景分析用户故事。
-
以系统需求驱动系统设计，并作为最细粒度的落实描述。
需求的重要性
需求依赖软件，还是软件依赖需求？
-
依赖的含义是当甲改变，乙就会改变，则说明乙依赖甲。
-
需求之于软件可以等价于喝水之于水杯，做饭之于厨房。
-
在 具体 喝水时，手是需要依赖水杯的形状方便握取，否则需要改变喝水办法。
-
在 设计 喝水时，水杯是依赖手的形状，以喝水为目的进行塑形设计，从而有了存在的意义。
-
软件依赖需求存在，把握了需求就确定了软件的设计变化方向。
没有银弹，软件工程的首要和次要问题中提到，最难的问题是开发 conceptual construct，需求是在具体实现之外最主要的概念来源。
-
The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract in that such a conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.
-
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.
需求工程
需求工程指以工程化手段完成需求相关事情的合集，具体事项分为需求开发和管理两条线。
需求开发
需求开发不是指开发具体的代码，而是说开发“需求”本身，是使需求概念模型完备的过程。
需求开发分为不同的步骤，步骤之间会迭代重复进行，直到稳定。
需求获取
需求获取涵盖发现需求的各类活动，是获得最原始用户的需求与约束资料的过程。
常见手段：
-
自省
-
分析比对竞品。
-
关注前沿领域技术发展。以技术推动力促进产品变的更好。
-
熟悉自己的产品，追求更高的产品设计品味。
-
收集用户侧信息
-
用户访谈。
-
问卷调查。匿名意见收集。
-
文档分析。特别是对于用户的文档。
-
数据分析。主动分析用户数据，包括用户行为和常见问题等。
-
原型展示。使用原型或者各类演示（如PPT）方式演示给用户。
-
会议。与用户一起参与联合需求计划会议，持续同步。
-
观察。现场参与到用户的业务开发中。
自省更多发生在长期演进的产品的开发中。收集用户测信息更多发生在针对用户具体用途的短期项目开发中，如为用户定制一个系统，或完成一个具体功能解决一个业务场景。
在需求获取的各类手段中，每种手段都需要一些具体的计划和步骤完成，以及后续跟进，并非看上去那么简单。
干系人-客户-用户
-
干系人（stack holder）
-
积极参与项目的人或组织，会受到项目过程和结果的影响，或者影响到项目的过程或结果。
-
包含开发组织内部或者外部的人，范围较广。比如开发和测试人员也属于干系人。
-
客户(client)
-
直接或间接从产品中受益的人或者组织
-
干系人的子集
-
用户(user)
-
直接或间接使用产品的人
-
是客户的子集
-
直接使用产品的人叫“终端用户”
-
用户内部也可以分不同类别，需要找到需要优待的用户重点支持。
需求分析
需求分析准确理解并表达每个需求，是对需求收集获取的原始资料分析细化形成模型、确定重要程度和优先级的过程。
需求分析过程同时也是产品设计过程，需要有一些产品设计的原则才能给出优雅的用例，拒绝不合理诉求。
需求分析过程可以参考SA（结构化分析）和面向对象分析（OOA）方法。
OOA 该方法比较理想化，方法大致包括
-
建立用例模型
-
根据原始资料中提取静态概念和动态行为，名词，动词，形容词，条件
-
使用use case图建模参与者，用例，通信关联。（略）
-
细化用例描述。如前置条件，后置条件，执行步骤，优先级，是否扩展使用其他用例。
-
建立静态分析模型（领域模型）
-
静态分析模型 的意思是在分析阶段的静态模型，静态是相对稳定的含义。
-
领域模型（domain model）又称概念模型。表达了名词概念之间的关系。
-
名词对应 概念类 之间的关系往往比较稳定。这是在用户不断变更的需求面前，需求模型稳定的基础。
-
-
可以用类图表达。
-
使用领域驱动设计，以及Class-Responsibility-Collaborator方法“牵连再精化"产生一个静态的类模型。
-
建立动态分析模型
-
动态分析模型指分析阶段描述类之间交互的动态模型，用于描述用例执行步骤
-
可以用顺序图，状态机图等等UML交互图表达
OOA 方法或领域驱动设计蕴含了先为概念建模，在做后续实现层面设计的思想。这种方法的好处是使我们的软件实现存在一个精心维护的概念模型（有点类似于柏拉图的理念世界与现实世界的关系）。
在现实开发过程中更常见的办法其实是直接借鉴竞品或者开源的产品或实现代码层面设计。在理解后搬实现的过程，潜移默化的把相应的概念搬到自己的软件中。
这种做法并非没有好处，代码和开源概念上靠的更进有助于技术理解与交流，“长期借鉴”，以及未来的标准化。对于往标品方向做，一部分功能目标就是 me too，或者差异化不在功能性需求上的软件（比如数据库？），这种做法其实是合理的。
需求分析的详细程度并没有唯一的标准，因为分析和设计过程并不能清楚的切开，所以留有模糊空间。一个可能的标准是，在用户可见概念的基础上，完整建模了产品的外部行为，与用户需求不重不漏的对应，并且这些外部系统行为之间没有矛盾。
确定需求规格
需求规格（Software Requirement Specification，SRS）是一种需求开发产生的阶段性产物。确定了后续开发人员的工作范围。同时是一个系统对外的接口定义。形式化与可理解性并重才能最好的描述需求的定义。好的需求陈述要做到，完整、正确、必要、可行、优先级排序、可验证。
需求评审
需求评审是项目干系人在需求问题上达成共识的过程。完整正式评审后进入系统设计阶段。非正式的评审是一种提前收集意见的手段。
需求测试
需求规格中的概念和步骤只是典型的，部分的，不一定在概念模型上是完备的。需要对概念模型进行测试，比如描述一些场景是否会导致现有的交互设计出错，尽可能覆盖所有场景。
在测试驱动开发（TDD）的思想下，测试作为站在用户角度想问题的手段，应当先于开发。在需求测试的指导下，可以提前给出验收测试，更加精确描述需求的同时，指导后续的开发。
需求开发——以数据库一个小功能为例
比如需要支持一个叫“触发器（或者任何数据库的小功能点）”的功能，需求开发步骤大概是
-
明确外部推动力：看竞品，看标准，看用户场景
-
看竞品
-
Hive，Oracle，MySQL，BigQuery，PG等等。
-
总结触发器在各个产品的共性和区别，给出按照产品层面特性分类的评价表格。
-
-
看标准
-
SQL 标准。可以视作一种竞品。
-
看用户场景
-
明确解一个痛点。
-
注意使用用户真实场景测试产品设计。
-
-
明确内部约束：看 MaxCompute 现有功能，概念模型和系统内部设施
-
如果已存在，则合理化现有系统行为，和现有兼容，丰富其行为。
-
如果不存在，则新增实体对象到概念模型中，确定对象间关系，新增该对象上操作集合 。
-
对系统内部设施现状做权衡，多大程度上作为约束条件。
-
完备思考各种场景下概念模型完备性，是否会有冲突，矛盾，重复。
-
与现有产品最好的结合方式，应用产品设计原则
-
理清概念
-
最小化用户知识，用户只表达意图，避免牵涉实现机制
-
-
结合两者给出一个严格的功能需求描述。
-
完备的概念测试用例（可以直接给出SQL）
需求管理：
需求管理包含项目过程中保持需求协议完整性、准确性和流通行的活动。包括版本与变更控制，需求跟踪等。
版本与变更控制
基线
基线是指已经通过正式评审和批准的规约或产品，可以作为进一步开发的基础，只能通过正式的变更控制系统进行变化。需求基线是干系人认可的一个需求集合，通常作为某一个开发迭代或计划发布的内容。需求开发的结果（以各类文档的形式）通过评审后就形成了需求基线。
版本
需求基线需要版本化的管理，每个需求变化后都需要更新版本号，以避免混淆。
变更控制
需求的变更是不可避免的，但是频繁的需求变更会造成大量的开发工作变化。
-
由于一开始需求存在的模糊性，随着时间推移用户会希望“范围蔓延”，不断的在已有的模糊需求中提出更高要求。
-
在跨团队合作时，如果排期已确定但没有清晰定义两个团队合作接口的边界时，可能会出现 无主需求 ，以及 不断变化的边界协议 。这些会导致一开始承诺的工期无法满足，在同时和多个团队合作时会拖后下一个团队需求开发，也会使自己的开发工作疲于奔命。
每一个需求变更都应该非常正式的对待，需要识别出需求变更并要求重新排期（并且加钱），让提出变更的用户意识到需求变更的代价。这需要在开发时间评估之前，提前明确边界协议，保证完全覆盖需求以及多方对于边界协议达成一致。
需求跟踪
需求跟踪是个复杂的过程
需求跟踪包括
-
单个需求的开发状态跟踪
-
父子需求整体开发状态跟踪。（父子需求的组合可以用于开发任务的跨模块分派）
-
端到端跟踪
-
用户原始需求 <-> 需求用例 <-> （交付功能点，设计，测试，代码）
需求跟踪可以做到
-
发现遗漏/不必要的需求
-
需求变更影响分析
-
跟踪项目进度
-
关联设计，代码，测试与需求，便于历史问题调查
