回复
谈一些需求实践
本文谈一些在汽车嵌入式系统/软件项目开发中的需求分析实践，目的是使需求规约能满足如下文章中提到的需求特征，进而提升需求规约的质量。
1. 使用”需求属性”，帮助识别、组织和管理需求
常用的需求属性包括：
- 需求ID：需求的唯一标识符
- (Stakeholder) Priority: Priority来自于Stakeholder，Priority可以帮助项目团队确定需求开发的先后顺序，并且当项目的资源/时间/成本等受限场合，进行需求的取舍。
- Type：根据需求意图对需求进行分类，如：功能性需求、性能需求、可靠性需求、验证需求等
- Status：需求的Status包括如“proposed”, “assumed”, “accepted”, “reviewed”, “delivered”, “verified”
- ASIL：功能安全场合适用
2. 使用”需求属性”，帮助进行需求分析
需求分析时，需要分析需求的可验证性、可实现性和正确性等。
ASPICE评估时，需求工程师经常会被问的一个问题是：项目中是如何确保每个需求都有从"可验证性"、"可实现性"等方面进行分析呢？
增加必要的需求属性，可以帮助建立需求分析的系统化机制(Systematic Approach).
例如：
很多项目使用系统工具(如：DOORs, Polarian, ALM)进行需求管理时，往往会有很多与上图类似的”属性字段”，是同样的道理。
3. 使用”自然语言+图表”结合的方式，增加需求的可读性、完整性、可维护性
众多的用自然语言描述的需求，放在一起形成需求集合后。如果没有很好的组织方式，很难维护，也较难判断需求的完整性。此时可以借用图表，来支持展现需求间的关系。
例如：
如下所示，基于某1条"系统需求"，开发了一组"系统组件需求"。
系统需求：主控板接收到电芯温度信号后，进行信号有效性和过温判断，超过X场合，切断接触器，超过Y场合，发送过温报警信号
- 系统组件需求-1: [HW - 温度采集模块]，通过Private CAN, 采集电芯温度信号
- 系统组件需求-2: [SW - 温度采集逻辑模块]，接收电芯温度数据，进行温度有效性检查。
- 系统组件需求-3: [SW - 过温控制逻辑模块]，进行温度过温判断，查过X场合，发送切断接触器的指令；超过Y场合，发送报警信号指令
- 系统组件需求-4: [SW - [接触器控制逻辑模块]…..
- 系统组件需求-5: [SW - 报警处理逻辑模块]，…...
说明：如上是展示需求间关系的示例，需求描述简略，不满足很多需求特征，勿拍。
这组"系统组件需求"是完整的吗？是否存在遗漏或冗余呢？
"系统需求"是否完整呢？是否包括了各种可能情况呢？
这个问题不是很容易回答。
如果有如下的需求间关系的Diagram，这个问题就一目了然了。
缺少哪些需求呢？参考下图的红色框：
4. 对需求描述的语言进行限制
4.1 需求描述需要完整包括各种可能性，如：功能性需求中需包括正常/异常等情况。
4.2 采用一定的语法结构
如：
说明：当某条需求中有两个Action，则表明该需求不是Singular，需要拆分。
4.3 限制使用不确定性的词语
一些使能动词（如：可以, 可能, 大概, 也许）和表示范围的副词（如：所有, 全部, 每个）等会增加需求的不确定性。
例如：[BMS系统]可以处理接收到的所有异常信号。
如果使用英文来描述需求的话，例如：
- 可以使用 Shall, must, is, are等
- 不能使用 Should, can, may, will等
- 不能使用 all, always, never, each, every等
- 不能使用 easy to use, user friendly等
5. 需求评审
把对需求的要求，形成CheckList，并使用该Check List对需求进行评审。
可以要求需求的所有相关方参与评审，并承担相应的评审职责，例如：软件需求评审时：
- SW Tester，负责确认需求的Verifiability
- SW Developer，负责确认需求的Feasibility
- SYS Engineer，负责确认SW Req.是否符合System需求及System Design
- …
- All，负责确认需求的Comprehensible, Unambiguous等等
6.真正使用“需求规约”【最重要 & 最有效的实践】
- 设计工程师，基于”需求规约”进行产品设计，对需求规约存在疑问时，请需求工程师进行解释，并更新和再次发布”需求规约”。
- 测试工程师，基于”需求规约”进行测试用例设计，对需求规约存在疑问时，请需求工程师进行解释，并更新和再次发布”需求规约”。
- ……
文章转载自公众号：仨人谈起
分类
标签
赞
收藏
回复
相关推荐
