요구사항 분석 및 개발

자동차 분야에서는 ISO 26262, A-SPICE 인증을 통해 각 기업의 개발 프로세스 품질 향상을 위한 노력이 계속적으로 늘어나고 있으며, 많은 업체가 인증 획득에 성공하는 사례가 늘어나고 있다. 개발 프로세스 품질의 핵심은 V-모델의 전반적인 활동들을 얼마나 잘 수행하고 관리하는가의 정도에 따라 결정된다. 요구사항 분석을 통해 설계, 구현, 테스트 각 단계에서 어떤 활동을 하여야 하는지는 표준 문서나 여러 자료들을 통해서 쉽게 접할 수 있지만 실제로 구축된 예시를 찾기가 매우 어렵기 때문에, 실제로 V-모델을 적용하고자 할 때, 많은 제약이 따르게 된다. 이에 간단한 SW를 개발하는 과정에 V-모델을 적용하여 각 단계별 산출물들의 예시를 작성하였다. 본 자료를 참고하여 인증 획득 활동에 도움이 되고자 한다.

1. 소프트웨어 요구사항 명세서(SRS) 란 무엇인가?
소프트웨어 요구사항 명세서(SRS, Software Requirement Specification)란 소프트웨어 개발 프로세스의 시작인 소프트웨어의 요구사항을 분석하고 정의하는 단계에서 작성되는 최종 산출물이다. 소프트웨어 요구사항 명세서에는 소프트웨어가 수행해야 할 모든 기능과 제약 조건 등이 기술되어 있으며, 이후 진행되는 소프트웨어 개발과 테스팅의 완료 승인에 대한 기준으로서 사용된다. 실제로 SRS는 고객사의 요구사항인 RFQ기반으로 정리된다. 

SysRS단에서 전체 시스템레벨로 정의되어 메디니등과 같은 형상관리 툴을 통해서 하나도 빠짐없이 리스트업되어야한다.

2. 소프트웨어 요구사항 명세서가 갖추어야 할 조건

작성된 요구사항 명세서가 좋은 명세서로 작성되었다고 판단할 수 있는 절대적인 기준은 존재하지 않는다. 하지만 소프트웨어 검증과 확인 절차에 대한 표준 문서인 IEEE Std. 1012 (IEEE Std. 1012-2012, IEEE Standard for Software Verification & Validation)에서 제시하고 있는 요구사항 평가 항목에 따라 요구사항 명세서를 평가하고, 소프트웨어 요구사항 명세에 대한 표준 IEEE Std. 830 문서에서 제시하고 있는 명세서의 특징을 잘 갖추고 있는 요구사항 명세서를 작성하려고 하면 좋을것이다. 하지만 표준에 따라 잘 정리하는 것과 더불어 축적의 시간을 필요로 하는것들도 있다.

요구사항 분석을 하다보면 RFQ내에서 외부 문서를 참조하라고 하는 경우가 많다. 이때 충분히 자동차 업계에서 경험을 가진 업체라면 문제 없겠지만 신규 진입한 업체들은 이 요구사항 분석을 빼먹고 하거나 외부 문서를 무시해서 발생하는 문제들이 많다. 

즉 신규개발이라면 A~Z까지 한 한줄도 빼지말고 요구사항을 분석해서 정리하고 그에 근거한 개발을 진행해야 한다. 

V Model에 있는 모든것들을 수행하고 문서화해야 나중에 발생할 수 있는 법적인 문제 과실여부등을 따질 때 문제를 최소화 할것이며 경쟁력을 갖출 수 있게 된다.

3. 요구사항에 맞추어 테스트 Plan을 반드시 준비하고 수행해서 기능 검증의 Coverage가 100%가 되도록 해야한다. 향후 기능안정이 점점 복잡해지고 자율주행으로 가면서 이 테스트 계획및 실행 결과는 향후 법적 소송등에서도 중요한 기준이될 것이다.