ASPICE - SYS.1 带读

ChrisWuyin

大家好，我，不按时更新的克里斯。
今天我们聊一下ASPICE系统工程的第一号过程。SYS.1 Requirement Elicitation。
SYS.1的篇幅会比较小，因为太简单了。克里斯要想想后面怎么写。比如PAM3.1-4.0 重大更新的SWE.5估计能把我写死。

我们将观察和对比多份准则。
- ASPICE 3.1 : PAM 3.1
- ASPICE 4.0 : PAM 4.0
- AGILE-SPICE : 基于敏捷开发过程的ASPICE评估时给出的推断准则
- ASPICE PoA ：评审潜在供应商而非正式供应商项目时给出的准则

好。我们现在开始观察sys.1能力级别1级时的描述

	ASPICE 3.1	ASPICE 4.0	AGILE-SPICE	ASPICE PoA
过程目的	The  purpose of the Requirements Elicitation Process is to gather, process, and  track evolving stakeholder needs and requirements throughout the lifecycle of  the product and/or service so as to establish a requirements baseline that  serves as the basis for defining the needed work products.	The  purpose is to gather, analyze, and track evolving stakeholder needs and  requirements throughout the lifecycle of the product and/or service to  establish a set of agreed requirements.		The  purpose is to gather and process stakeholder needs and requirements of the  exemplary product or service
过程产出	1)  continuing communication with the stakeholder is established;	1)  continuing communication with the stakeholder is established;		1)  Exchange of Stakeholder expectations is estabilished
	2) agreed stakeholder requirements are defined  and baselined;	2)  agreed stakeholder requirements are defined and baselined;		2)Stakeholder  requirements are agreed
	3) a change mechanism is established to  evaluate and incorporate changes to stakeholder requirements into the  baselined requirements based on changing stakeholder needs;	3)  a change mechanism is established to evaluate and incorporate changes to  stakeholder requirements into the baselined requirements based on changing  stakeholder needs;		3)  Stakeholder needs are monitored continously
	4) a mechanism is established for continuous  monitoring of stakeholder needs;	4)  a mechanism is established for continuous monitoring of stakeholder  needs;		4)Evolving  stakeholder requirements are continously evaluated
	5) a mechanism is established for ensuring that  customers can easily determine the status and disposition of their requests;  and	5)  a mechanism is established for ensuring that customers can easily determine  the status and disposition of their requests; and
	6) changes arising from changing technology and  stakeholder needs are identified, the associated risks assessed and their  impact managed.	6)  changes arising from changing technology and stakeholder needs are  identified, the associated risks assessed and their impact managed.
Basic Practice	BP1:  Obtain stakeholder requirements and requests.	BP1:  Obtain stakeholder expectations and requests.	Continuous  communication between the stakeholder and the team (of teams) is established.	BP1:  Obtain stakeholder expectations and request
	BP2: Understand stakeholder expectations.	BP2:  Agree on requirements.	Agreed stakeholder requirements are defined and  collected in the product backlog to be realised during development. After the  development of individual stakeholder requirements it is important to  differentiate between the description of the product (specification) and  backlog items and their respective history.	BP2: Agree on requirements.
	BP3: Agree on requirements.
	BP4: Establish stakeholder requirements  baseline.
	BP5: Manage stakeholder requirements changes.	BP3:  Analyze stakeholder requirements changes.	Stakeholder  needs are continuously exchanged and their impact on the product backlog is  analysed.     Changes to stakeholder requirements are incorporated into the product  backlog based on changing stakeholder needs.     Changes arising from changing technology and stakeholder needs are  identified, the associated risks assessed and their impact managed.	BP3:  Analyze stakeholder requirements changes.
	BP6: Establish customer-supplier query  communication mechanism.	BP4:  Communicate requirements status.	1.  Continuous communication between the stakeholder and the team (of teams) is  established.     2. The status of the product backlog items is made visible to the customer  and is regularly communicated.

新版的ASPICE已经进行了BP删减。克里斯按照VDA给出的映射关系将前后互相映射的BP做了对齐
可以明确看到的是ASPICE并没有对SYS.1进行比较重大的变化。其要点还是围绕
- 需要在完整的开发生命周期内的持续进行
- 需求挖掘，分类，整理，
- 达成约定一致
- 需要必要时候与SUP的变更过程关联

系统工程过程1，需求挖掘的主要目的，是将一个需求池推导出一组约定好的需求。挖掘需要在产品开发生命周期内不断进行维护，约定需要在所有干系人之间达成共同的约定。

一个通常的误区是将这个过程理解为仅仅是客户需求收集。这是狭隘的，原则上一个需求收集和平衡的过程需要顾虑到几个大方面
- 你的客户和你的供应商对你设计的影响，要求，约束
- 你的平台，也就是你过去的对该产品的开发知识主导的你对这产品的设计知识提出的需求和约束
- 你的组织，你的国家，你的目标市场的规则，规定，法律
当我们来到这一个层面，你就会发现你面对的干系人过于庞大，没错这就是为什么系统工程那么值钱。
需要注意
1. 需要对干系人需求进行归类
2. 干系人可能无法提出显性需求，这时候开发团队需要挖掘隐性需求将其曝光
3. 但是干系人可能会提出，渗透系统设计的细节需求，例如，干系人可能直接给你提出一个AUTOSAR的配置需求。这个时候直接由系统需求去继承是否合适，答案是否定的。需要软件团队一起评估该需求可否被系统需求抽象，如果不用抽象则直接下发软件需求，如果确实要素无法直接抽象，则需要评估可行性并且补充要素之后进行抽象再决定由谁继承。当然存在一种情况，客户提出的某个渗透性的需求，不足以完整的形成一个系统抽象功能，这个时候
- 需要补充得以完成抽象的方案 - 与干系人达成共识
- 需要抽象出系统黑盒行为，不干预完整的设计细节。
然后再系统需求中进行黑盒描述，附加已知的带渗透性的设定作为约束。

另一个通常的误区是，需求需要建立完整的自上向下的追溯。然而，在软件部门的同意下，在不违反无遗漏风险的要求的情况下，某些SYS.1的需求，可以直接追溯上软件需求，甚至，追溯向软件详细设计。这是一个看似简单然而复杂的需求，其复杂性来源于软件开发过程中常常存在的子项目，即非常少的项目由1个软件团队进行全栈开发。
SYS.1的需求还有一个豁免条款，即当干系人要求的需求是，“过程符合性需求，或者过程产物特性”的时候，不需要进行向下追溯。ASPICE评估师手册给出了一个很经典的例子，比如干系人要求代码符合MISRA C某版本某修订版。则该需求不需要向下进行追溯，仅需要出示最终满足证据。

一个明确的要求是，这个过程需要在项目的生命周期内持续的进行，并且持续的维护。在PAM中要求在必要时候对干系人提出的变更与SUP变更过程进行关联，在AGLIE规则的推断准则里提示项目组需要在完成某个干系人的需求开发中，需要明确back log中定义的用户需求（可能时用户故事描述）不能等同于产品规范。 其实，在SYS.1也明确要求了干系人需求需要进行分类整合而不能直接生搬硬套。

好了，就到这里戛然而止吧，克里斯要睡觉了。
大家拜拜

下次更新不知道是啥时候，克里斯给大家拜个早年。

hyowinner

持续学习来了！

hyowinner

需求可否被系统需求抽象，具体如何抽象，这个过程，克里斯下次再分享一下细节。期待~！