SWE.1 (소프트웨엉 요구사항 분석)의 가장 중요한 말은 시스템 요구사항에서 소프트웨어 관련한 부분을 파악하여
소프트웨어 관련 요구사항 무리로 분류하는 것이다. 그니까 상위 개념인 동시에 추상적인 의미를 가진 시스템 단계에서
그것의 하위 개념인 동시에 기술적인 내용을 가지는 소프트웨어 하드웨어 단계로 넘어가면서 미리 소프트웨어 관련 요구사항을 분석하여 소프트웨어 요구사항으로 변환하는 것
그리고 사실 SWE.1은 SYS.2 때 처럼 결국은 요구사항 분석으로 ASPICE 적으로 할 내용은 거의 똑같다.
그래서 이전 글인 SYS.2의 글 부분을 복사해 왔다. ↓
ASPICE 실무를 위해 좀 더 구체적으로 해야 하는 활동을 설명을 하자면 시스템 요구사항을 구조화 해야 하고
정확성, 기술적 실현 가능성, 검증 가능성, 위험 식별 지원을 위해 명세된 시스템 요구사항을 상호 의존성을 포함하여 분석
,비용에 대한 영향, 일정, 기술적 영향을 분석해야 한다. 또한 시스템과 운영 환경의 다른 엘리먼트 간 인터페이스르 식별해야 한다. 그리고 시스템 요구사항이 이러한 인터페이스와 운영 환경에 미치는 영향을 분석해야 한다.
검증 기준 또한 개발해야 한다.( 이 복사해 온 글에서 "시스템" 대신 "소프트웨어"로 변환시키면 ASPICE의
SWE.1 내용과 거의 일치)
근데 사실 위 ASPICE 내 실무적 내용은 본질적으로는 제품에 커스터마이징 하기 위해서 필요한 활동들이다 잘 생각해보고 내 말이 맞는지 스스로 고민해 보길 바란다
물론 ASPICE내 실무적으로 해야 하는 행위는 SYS.2이나 SWE.1이나 똑같지만 당연히 시스템 요구사항 분석 떄와는 요구사항을 다루는 내용이 달라질 것이다. 시스템 요구사항 분석보다 소프트웨어 요구사항 분석의 요구사항 내용이 더욱 구체적이고 시스템 요구사항을 구현하기 위한 것이 소프트웨어 요구사항이라고 보면 된다.
아 이참에 단계별 요구사항의 관계를 알려주겠다 음.. 가장 최상위 요구사항이 고객 요구사항이고 그 다음이 시스템 요구사항 그 다음이 소프트웨어 및 하드웨어 요구사항인데 이들 간의 바로 위 아래 단계 간의 핵심 내용은 "상위 개념을 구현하기 위한 것이 하위개념이다 "인 관계이다.
예를 들어 시스템 요구사항은 고객 요구사항을 구현하기 위한 것이고 소프트웨어 및 하드웨어 요구사항은 시스템 요구사항을 구현하기 위한 것이라 보면 된다.
'ASPICE 기본 이론' 카테고리의 다른 글
| 번외. SWE.4에서 등장하는 검증 용어 (0) | 2024.01.22 |
|---|---|
| SWE.2 (0) | 2024.01.18 |
| SYS.5 (0) | 2024.01.12 |
| SYS.4 (0) | 2024.01.12 |
| SYS.3 (참고로 이거 읽으면 제품 개발 프로세스가 왜 이런지 이해 갈 수 있음) (0) | 2024.01.11 |