앞 서 ASPICE에 대한 용어와 SWE 프로세스에 대해 알아보았다. SWE.1은 Software Requirements Analysis 프로세스이다. 이에 대한 Base Practice, Work Product는 어떤 게 있어야 하는지 구체적으로 알아보자. 아래 내용은 ASPICE 4.0을 베이스로 작성되었다. 3.1과 디테일은 다르고 큰 맥락에서는 같다.
이전글: ASPICE 정복하기 - (1) ASPICE 용어 친해지기
SWE.1란?
지난 번 간단히 적어뒀기 때문에 언급만 하고 넘어가도록 하려고 한다. 'Software Requirement Analysis'로, 소프트웨어 요구사항이다. 소프트웨어가 구현/기능해야 하는 요구들을 적어놓는다. 예를 들어, ADC 드라이버는 Analog 값을 Digital로 변환해야 한다. 등이 된다.
ASPICE에서 SWE.1에 요구하는 Base practice
Base practice는 요구되는 활동이고, 산출물은 보여줘야되는 결과이다. 둘을 모두 나열하고 매칭을 시키면서 글을 쓰려고 했으나, ASPICE 문서를 그대로 번역하는 게 될뿐더러 가독성도 없어, Base Practice 위주로 정리하려고 한다. Base Practice만 알더라도 ASPICE 문서를 읽을 때 충분히 스스로 매칭시킬 수 있다.
Base Practice 1: Specify software requirements
소프트웨어 요구사항을 특정해야한다는 것이다. 시스템 요구사항과 시스템 아키텍처를 이용하여 기능적/비기능적 요구를 특정하고 문서화한다.
이 내용은 시스템 요구사항과 시스템 아키텍처(또는 그 변경 사항)를 바탕으로 소프트웨어 요구사항을 작성해야 한다는 것이다. 예를 들어 시스템 요구사항으로 '커넥터 핀A01로 입력되는 voltage 값을 읽어야 한다.'라는 요구사항이 있다고 하자. 이때 'ADC - Analog to Digital Converter' 기능을 통해 아날로그 값을 디지털 값으로 변환하는 기능이 필요하다. 따라서, ADC 소프트웨어 요구사항을 작성해야 한다.
Base Practice 2: Structure software requirements.
소프트웨어 요구사항들을 구조화한다.
결과적으로 소프트웨어 요구사하을 논리적이고 계층적으로 구조화하라는 의미이다.
여기서 말하는 구조화는
- 프로젝트와 관련된 비슷한 항목을 묶는다. e.g.) Safety Requirement인지 Functional Requirement인지
- 논리적인 순서로 정돈하고 e.g.) 1.1 요구사항 개괄, 1.1.1 세부 요구사항1, 1.1.2 세부 요구사항2 .... 논리적인 문서를 만들 것.
- 연관된 기준을 바탕으로 분류하고 e.g.) 예를 들어 Input Output을 담당하는 소프트웨어 요구사항을 묶는다.
- 고객 요구사항에 따라 우선순위를 매기는 작업 e.g.) High, Medium, Low 등 Importance 정의하는 작업. 이때 통상 특정 릴리즈에 소프트웨어 내용을 할당하는 작업이 포함된다. (Planned In...)
를 의미한다.
전반적으로 Requirement Management 툴에서 Requirement Specification 등을 만들 수 있어 계층화할 수 있게 돕고 있고, 각 항목마다 우선순위를 매길 수 있게 하는 등 여러 방법을 통해 위 Best Practice를 구현할 수 있게 돕고 있다.
Base Practice 3: Analyze software requirements.
소프트웨어 요구사항을 분석한다.
이때 분석은 다음과 같다.
- 소프트웨어 요구사항이 독립적인지; 이 경우는 다른 요구사항과 충돌한다거나 중복되지 않는지 분석한다.
- 올바른지, 기술적으로 구현가능한지, 그리고 프로젝트 관리에 맞게 제공될 수 있는지 (기한에 맞출 수 있는지) 분석한다.
Base Practice 4: Analyze the impact on the operating environment.
동작 환경에 줄 수 있는 영향을 분석한다. 여기서 동작 환경이란 하드웨어, OS 등을 의미한다.
Base Practice 5: Ensure consistency and establish bidirectional traceability.
소프트웨어 요구사항과 시스템 아키텍처 사이가 정합(Consistency)성 있게 연결되어야 하고, 추적(Traceability)이 되어야 한다. 또한, 소프트웨어 요구사항과 시스템 요구사항 간의 관계도 마찬가지이다.
Base Practice 6: Communicate agreed software requirements and impact on the operating environment.
합의된 소프트웨어 요구사항을 전달하고, 동작환경에서의 영향을 연관 있는 당사자들에게 전달한다.
위와 같은 활동(Base Practice)을 하는 작업으로 보면 된다.
Process Outcome - Base Practice에 의한 산출물
이러한 활동들을 하면서, 보여줄 수 있는 결과물이 나와야 된다. 이것을 Process outcomes라고 정의한다.
아래와 같은 결과물이 나와야 한다.
심사받을 때는 결과물을 보여줘서 증명해야 하므로, 필요로 하는 결과물이 무엇인지 각별히 주의가 필요하다.
위 표를 간단히 읽을 수 있지만, 해석을 하자면 다음과 같다.
Process Outcomes 1) Software requirements are specified.
소프트웨어 요구사항이 '특정'되어야 한다. 는 결과가 나와야 한다.
(1) Base Practice 1. Specify software requirements이 수행되고,
(2) 17-00 Requirement가 나와야 한다. 즉, 이 작업을 통해 소프트웨어 요구사항이 나와야한다.
Process Outcomes 2) Software requirements are structured and prioritized.
소프트웨어 요구사항이 구조화되고 우선수위가 매겨져야 한다.
- Base Practice 2: Structure software requirements가 수행되고
- 17-00 Requirement와 17-54 Requirement Attribute가 나와야 한다. 이때 Attribute은 중요도(Priority)와 구조화할 수 있는 요소(예를 들어 어떤 프로젝트의 요구사항인지) 등이 있다.
Process Outcomes 3) Software requirements are analyzed for correctness and technical feasibility.
소프트웨어 요구사항이 올바른지 그리고 기술적으로 구현가능한지 분석된다.
- Base Practice 3: Analyze software requirements. 가 수행되고,
- 15-51 Analysis Results 즉, 분석 결과가 나와야 한다.
- 분석 결과란, 기술적으로 구현가능한지 등이다.
Process Outcomes 4) The impact of software requirements on the operating environment is analyzed.
- Base Practice 4: Analyze the impact on the operating environment가 수행되고,
- 15-51 Analysis Results 분석결과가 나와야 한다.
Process Outcomes 5) Consistency and bidirectional traceability are established between software requirements and system requirements.
소프트웨어 요구사항과 시스템 요구사항 사이의 정합성과 추적성이 있어야 한다.
- Base Practice 5: Ensure consistency and establish bidirectional traceability가 수행되고,
- 13-51 Consistency Evidence가 나와야 한다.어떠어떠한 이유로 해당 소프트웨어 요구사항과 시스템 요구사항이 연결되어야 한다 라는 결과가 있어야 된다는 것이다. Comment로 남길 수 있다.
Process Outcomes 6) Consistency and bidirectional traceability are established between software requirements and system architecture.
- Base Practice 5: Ensure consistency and establish bidirectional traceability가 수행되고,
- 13-51 Consistency Evidence가 나와야 한다. 어떠어떠한 이유로 해당 소프트웨어 요구사항과 시스템 아키텍처가 연결되어야 한다 라는 결과가 있어야 된다는 것이다. Comment로 남길 수 있다.
Process Outcomes 7) The software requirements are agreed and communicated to all affected parties.
소프트웨어 요구사항이 합의되고 모든 관계자에게 전달되어야 한다.
- Base Practice 6: Communicate agreed software requirements and impact on the operating environment가 수행되고,
- 13-52 Communication Evidence가 있어야 한다라는 것이다. 이는 review tool 등에 남겨도 되고, 어떤 툴에 남겨도 좋다. 다만 각 담당자가 리뷰어였다는 점과, 리뷰 결과가 남는 것을 목표로 해야 한다.
준비하면서 어려운 부분들..
SWE.1를 하면서 가장 어려웠던 점은 Cosistency 확보했다는 것을 어떻게 남길 것인가이다.
Comment를 남길 수 있지만, 어떻게 남길 것인가? 내 경우, 시스템 요구사항에서 일부 따오고, 소프트웨어 요구사항에서 일부 따와서 작성하는 게 가장 좋아보였다.
예를 들어, 시스템 요구사항: 핀 A01은 ADC 채널이다. 이 경우 소프트웨어 요구사항은 'ADC 드라이버는 Analog 값을 Digital로 변환해야 한다.'라는 소프트웨어 요구사항이 있다고 해보자. 이 때 적을 수 있는 Comment는 다음과 같다.
Comment: 이 소프트웨어 요구사항은 ADC 기능을 수행하도록 설계된 요구사항이다. 핀 A01은 ADC 채널로 지정되어 있으므로, 해당 핀을 ADC 입력으로 구현해야 하기 때문에 연결하기 적합하다.
등이다.
하지만 현실적으로 수 많은 소프트웨어 요구사항을 연결할 때마다 위와 같은 Comment를 남기는 것은, 장시간이 걸리고 시간적 여유가 없으면 불가능하기 때문에 일괄적으로 남길 수 있는 Comment를 남기는 게 최선일 것 같다.
다음은 SWE.2에 대해 알아보자.
'임베디드소프트웨어' 카테고리의 다른 글
| ASPICE 정복하기 - (2) SWE란? (0) | 2025.03.08 |
|---|---|
| ASPICE 정복하기 - (1) ASPICE 용어 친해지기 (0) | 2025.02.28 |
| 인피니언 TC3xx EVADC 개념 정리 - 2편 (Arbitration, Result Handling, Service Request Generation) (0) | 2023.05.09 |
| 인피니언 TC3xx EVADC 개념 정리 - 1편 (EVADC 개요, 트리거, Queue) (0) | 2023.05.05 |
| RISC와 CISC 개념, 분석, 비교 (0) | 2022.07.02 |
댓글