[ASPICE] SWE.3 소프트웨어 상세 설계서인 SDD 문서 작성법

SW Detailed Design Specification 에 대해 설명한다.

소프트웨어 상세 설계 문서이며, 통상 SDD 또는 SWDD 라고 칭한다.

IEEE는 소프트웨어 상세 설계 문서를 "분석, 계획, 구현 및 의사 결정을 용이하게 하기 위해 작성된 소프트웨어에 대한 설명"으로 정의한다. 본질적으로 소프트웨어 상세 설계 문서(SDD)는 일련의 기술 요구 사항을 충족하기 위해 소프트웨어 제품 또는 기능을 구축하는 방법을 설명한다. 요구 사항 문서가 프로젝트의 "what"을 설명 한다면 디자인 문서는 "how"에 중점을 둔다.

 

 

SWE.3 소프트웨어 상세 설계 담당자가 기본적으로 수행하는 BP는 다음과 같다. 

 

SWE.3.BP1: Develop software detailed design. Develop a detailed design for each software component defined in the software architectural design that specifies all software units with respect to functional and nonfunctional software requirements.

 

소프트웨어 상세 설계를 개발합니다. 기능적 및 비기능적 소프트웨어 요구 사항과 관련하여 모든 소프트웨어 단위를 지정하는 소프트웨어 아키텍처 설계에 정의된 각 소프트웨어 구성 요소에 대한 세부 설계를 개발합니다.

 

SWE.3.BP2: Define interfaces of software units. Identify, specify and document the interfaces of each software unit.

 

소프트웨어 유닛의 인터페이스를 정의합니다. 각 소프트웨어 장치의 인터페이스를 식별, 지정 및 문서화합니다.

 

SWE.3.BP3: Describe dynamic behavior. Evaluate and document the dynamic behavior of and the interaction between relevant software units.

NOTE 1: Not all software units have dynamic behavior to be described.

 

동적 동작을 설명합니다. 관련 소프트웨어 장치 간의 동적 동작과 상호 작용을 평가하고 문서화합니다.

참고 1: 모든 소프트웨어 장치가 설명할 동적 동작을 갖는 것은 아닙니다.

SWE.3.BP4: Evaluate software detailed design. Evaluate the software detailed design in terms of interoperability, interaction, criticality, technical complexity, risks and testability.
NOTE 2: The results of the evaluation can be used as input for software unit verification.

 

소프트웨어 세부 설계를 평가합니다. 상호 운용성, 상호 작용, 중요도, 기술적 복잡성, 위험 및 테스트 가능성 측면에서 소프트웨어 세부 설계를 평가합니다.

참고 2: 평가 결과는 소프트웨어 장치 검증을 위한 입력으로 사용될 수 있습니다.

SWE.3.BP5: Establish bidirectional traceability. Establish bidirectional traceability between software requirements and software units. Establish bidirectional traceability between the software architectural design and the software detailed design. Establish bidirectional traceability between the software detailed design and software units.
NOTE 3: Redundancy should be avoided by establishing a combination of these approaches that covers the project and the organizational needs.
NOTE 4: Bidirectional traceability supports coverage, consistency and impact analysis.

 

양방향 추적성을 확립합니다. 소프트웨어 요구 사항과 소프트웨어 단위 간의 양방향 추적성을 설정합니다. 소프트웨어 아키텍처 설계와 소프트웨어 세부 설계 간의 양방향 추적성을 확립합니다. 소프트웨어 상세 설계와 소프트웨어 유닛 간의 양방향 추적성을 확립합니다.

참고 3: 프로젝트와 조직의 요구를 포괄하는 이러한 접근 방식의 조합을 설정하여 중복을 피해야 합니다.

참고 4: 양방향 추적성은 적용 범위, 일관성 및 영향 분석을 지원합니다.

 

 

SWE.3.BP6: Ensure consistency. Ensure consistency between software requirements and software units. Ensure consistency between the software architectural design, the software detailed design and software units.
NOTE 5: Consistency is supported by bidirectional traceability and can be demonstrated by review records.

 

일관성을 보장합니다. 소프트웨어 요구사항과 소프트웨어 단위 간의 일관성을 보장합니다. 소프트웨어 아키텍처 설계, 소프트웨어 세부 설계 및 소프트웨어 단위 간의 일관성을 보장합니다.

비고 5: 일관성은 양방향 추적성에 의해 뒷받침되며 검토 기록으로 입증될 수 있다.

 

 

SWE.3.BP7: Communicate agreed software detailed design. Communicate the agreed software detailed design and updates to the software detailed design to all relevant parties.

 

합의된 소프트웨어 세부 설계를 전달합니다. 합의된 소프트웨어 세부 설계 및 소프트웨어 세부 설계 업데이트를 모든 관련 당사자에게 전달합니다.

 

 

SWE.3.BP8: Develop software units. Develop and document the executable representations of each software unit according to the software detailed design.

 

소프트웨어 유닛을 개발합니다. 소프트웨어 세부 설계에 따라 각 소프트웨어 단위의 실행 가능한 표현을 개발하고 문서화합니다.

 

 

 

그렇다면, 실제 SDD는 어떻게 작성해야 하는가? 필요한 항목은 무엇인가?

사실, 정답은 없다. 아래는 실제 SDD에 작성한 항목이다. Design은 보안상 워터마크 처리하였다.

 

1 Introduction
1.1 Purpose and Scope
- 문서 개발 목적을 기술하고, 개발된 문서를 사용할 대상을 정의한다.
- 산출물이 다루고 있는 내용 범위를 정의하고, 내용 적용 간 제약사항을 기술한다.

1.2 References
- 본 문서 개발을 위해 참조하거나 문서의 내용 간 참조 대상이 있는 해당 문서의 정보를 기술한다.
- 문서명(또는 파일명), 문서에 대한 설명, 버전/날짜, 문서의 출처 등의 정보가 기술되어야 한다.

1.3 Terms and Abbreviation
- 문서에서 사용한 용어, 약어를 정의한다. 
- 약어에 대해 설명할 경우 본딧말(Original Words)을 기술 한 후 용어에 대한 설명을 한다.

1.4 Information
- 문서의 이해도를 높이고, 내용의 해석을 위해 공유해야 하는 정보를 자유형식으로 기재한다.
- 문서 작성 규칙을 정하여 운영할 경우 해당 규칙을 기술한다.
- 2개 이상의 MCU를 사용할 경우 요구사항 ID 앞에 MCU 특성을 기술한다.


2 Software Unit Design (Application Layer)
2.1 Software Component Name [SW 컴포넌트 ID] / ASIL 등급
2.1.1 Unit Name [SW 유닛 ID] / ASIL 등급
2.1.1.1 Unit Design

Unit Design 예시 (보안으로 인해 워터마크 처리)

- 해당 유닛 기준의 정적 다이어그램을 설계하여 작성한다.
- Input / output interface에 기재된 이름 등을 일관성 있게 반영하여 기재한다.

2.1.1.2 Input Interface Design

Input Interface Design 예시

- Unit Design에서 정의된 Input Interface를 기재한다.
- Input Name : 유닛의 입력 정보를 정의한다.
- Data Type : 입력 정보의 데이터 타입을 정의한다.
- Function Name / Variable Name : 인터페이스를 사용하기 위한 설계안을 정의한다.
- Value Range (Effective Range) : 데이터 타입에 따른 값의 범위 및 입력 정보의 유효 범위를 식별한다. 유효 범위가 없는 경우는 데이터 타입에 따른 범위 만을 정의한다.

 

2.1.1.3 Output Interface Design

Output Interface Design 예시

- Unit Design에서 정의된 Input Interface를 기재한다.
- Output Name : 유닛의 출력 정보를 정의한다.
- Data Type : 출력 정보의 데이터 타입을 정의한다.
- Function Name / Variable Name : 인터페이스를 사용하기 위한 설계안을 정의한다.
- Value Range (Effective Range) : 데이터 타입에 따른 값의 범위 및 입력 정보의 유효 범위를 식별한다. 유효 범위가 없는 경우는 데이터 타입에 따른 범위 만을 정의한다.

 

2.1.1.4 Software Requirements (at Unit level)

Software Requirements 예시

- Requirement ID : 소프트웨어 설계 요구사항 아이디를 기술한다. ID 형태는 1.4 Information에 정의한 문서작성 규칙과 일관성 있게 기술한다.
- Requirements : 소프트웨어 요구사항 또는 소프트웨어 아키텍쳐 설계 명세서로부터 할당 받아 요구사항을 기술한다.
요구사항 정의간 Unit Design에서 정의된 인터페이스 명칭을 사용한다.
요구사항은 기본적으로 IPO(입력 인터페이스, 처리, 출력 인터페이스)형태로 기술한다.
간단히 표현하기 어려운 요구사항의 경우, Semi-formal 형태로 기술 가능하다. (Semi-formal : UML, pseudo code, flow chart, 입/출력 진리표 등)
- Related ID : 추적성 관리를 위해 해당 요구사항이 할당 받은 상위 소프트웨어 아키텍처 요구사항 ID를 기술한다. 필요 시 소프트웨어 기능요구사항, 소프트웨어 기능안전 요구사항 ID도 기술한다.