국내 소프트웨어 시장은 소프트웨어 제품의 품질 불만과 수익성 악화라는 악순환의 고리에서 헤어나지 못하고 있다. 산업계 및 학계에서는 문제의 주된 원인이 소프트웨어 사업 초기의 불명확한 요구사항에 있음을 인식하고, 사업 초기부터 개발 범위 및 내용, 품질 목표 등을 명확히 설정하고 이를 요구사항 명세서에 충실히 반영할 것을 강조하고 있다. 본 연구에서는 보다 명확한 요구사항의 명세와 요구사항의 효과적인 관리를 위해 국내외의 다양한 형태의 요구사항 명세서를 분석하고, 이를 바탕으로 개발 범위의 명확화, 품질의 정량화, 요구사항들간의 연결/추적관리, 명세의 편이성이 제고된 요구사항명세 표준지침을 개발하였다. 제안하는 표준 병세서는 분할 발주 또는 일괄 발주 등 다양한 소프트웨어 사업 프로세스에 적용할 수 있는 장점이 있다.
국내 소프트웨어 시장은 소프트웨어 제품의 품질 불만과 수익성 악화라는 악순환의 고리에서 헤어나지 못하고 있다. 산업계 및 학계에서는 문제의 주된 원인이 소프트웨어 사업 초기의 불명확한 요구사항에 있음을 인식하고, 사업 초기부터 개발 범위 및 내용, 품질 목표 등을 명확히 설정하고 이를 요구사항 명세서에 충실히 반영할 것을 강조하고 있다. 본 연구에서는 보다 명확한 요구사항의 명세와 요구사항의 효과적인 관리를 위해 국내외의 다양한 형태의 요구사항 명세서를 분석하고, 이를 바탕으로 개발 범위의 명확화, 품질의 정량화, 요구사항들간의 연결/추적관리, 명세의 편이성이 제고된 요구사항명세 표준지침을 개발하였다. 제안하는 표준 병세서는 분할 발주 또는 일괄 발주 등 다양한 소프트웨어 사업 프로세스에 적용할 수 있는 장점이 있다.
Domestic software market is struggling with product's low quality and low return-on-investment. The cause for the problems is due to unclear requirements at the early stage of software project. Studies show that, to lessen the problem, the requirements specification must reflect the right project sc...
Domestic software market is struggling with product's low quality and low return-on-investment. The cause for the problems is due to unclear requirements at the early stage of software project. Studies show that, to lessen the problem, the requirements specification must reflect the right project scope and quantifiable quality goal. To achieve such features, this paper describes a standard guideline for SRS (Software Requirements Specification), which helps in defining the scope of project, measuring and quantifying quality, linking and tracing of requirements, and improving usability. The proposed SRS enables separating the requirements analysis activity from implementation activity and thus can improve subcontract management process in software project.
Domestic software market is struggling with product's low quality and low return-on-investment. The cause for the problems is due to unclear requirements at the early stage of software project. Studies show that, to lessen the problem, the requirements specification must reflect the right project scope and quantifiable quality goal. To achieve such features, this paper describes a standard guideline for SRS (Software Requirements Specification), which helps in defining the scope of project, measuring and quantifying quality, linking and tracing of requirements, and improving usability. The proposed SRS enables separating the requirements analysis activity from implementation activity and thus can improve subcontract management process in software project.
* AI 자동 식별 결과로 적합하지 않은 문장이 있을 수 있으니, 이용에 유의하시기 바랍니다.
문제 정의
. 발주자간의 상호 기대 등을 사업초기부터 요구사항에 명확하게 명세하면서도 요구사항 변경에도 유연하게 대처할 수 있는 요구사항 명세 표준을 제시한다. 제시하는 명세표준은 사용자 중심의 효율적 의사소통 및 협력의 기반이 되는 요구사항 명세, 명세서 작성 노력을 줄이면서 측정 가능한 요구사항 명세, 그리고 변경 및 추적이 용이한 요구사항 명세를 지향한다[3L 이러한 명세목표를 달성하기 위해, 명세서가 가져야 할 세부 특성으로는 ① 요구사항 명세관련 이해당사자의 명확한 정의, ② 요구공학 활동에서 산출되는 다양한 형태의 요구사항 반영, ③ 요구사항으로부터 사업의 규모, 기간 등의 대가 산정 가능, ④ 요구사항의 이해와 해석을 명확하게 하기 위한 명세 지침, ⑤ 요구사항 기준선 및 변경 기준선의 정의 및 관리 등 5가지로 요약될 수 있다(그림 3).
요구사항의 명확한 명세와 유연한 변경추적을 지원하기 위해서는 정형화되고 통일된 표준 형식이 필요하다. 본 논문에서는 정량화, 정형화, 연결/추적이 용이한 표준 명세서를 제안하고, 이의 활용 방안을 소개하였다.
제안 방법
기존의 요구명세서가 갖는 특성들을 파악하기 위해 현재 국내외적으로 널리 활용되고 있는 NASA, DOD, IEEE, 그리고 국내 A, B사의 표준 요구명세서를 비교분석하였다. 분석은 1절에서 기술한 5가지 특성과 [4] 의연구결과를 토대로 수행되었다.
본 논문에서 제안하는 표준 명세서의 요구사항 구성은 크게 비즈니스 요구사항, 기술 요구사항, 그리고 제약 요구사항으로 나뉘며, 각 범주의 세부 항목은 그림 4 와 같다. 표준 명세서는 이들 항목들이 상호 유기적인 관계를 가지면서 이해당사자들간의 상호 의사소통의 기반이 될 수 있도록 요구사항들간의 연결/추적, 요구사항의 정량화, 명세의 정형화 수단을 지원한다(그림 5).
분석은 1절에서 기술한 5가지 특성과 [4] 의연구결과를 토대로 수행되었다.
가능하도록 지원한다(표 11). 이를 위해 각 요구사항은 기능에 대한 명세뿐만 아니라 입출력 유형, 파일 유형, 각 기능에 관련된 입출력 데이터를 함께 제공함으로써 소프트웨어 규모를 예측할 수 있다, 또한 각 요구사항에 대한 고객의 등급이나 우선순위, 적합성(선택/핆수) 수준, 위험수준 둥도 정량화함으로써 가치 기반의 요구사항을 실현한다.
성능/효과
3%가 사용자와의 비효율적인 의사소통으로 인한 불완전한 요구사항의 정의와, 이로 인한 잦은 요구사항의 변경인 것으로 나타나고 있다[1]. 즉 프로젝트의 실패가 적용 기술이나 방법론의 부족에 기인하기보다는, 고객의 요구를 이해, 분석, 문서화하고, 변경을 관리 통제하는 기술과 방법의 문제인 것으로 나타났다(그림 1). 이러한 문제는 국제표준화 기구인 ISO/IEC JTC1/SC7 WG4에서 조사한 요구사항관리에 대한 현황 조사 보고서에도 잘 나타나 있다(그림 2).
후속연구
. 비 효율적인 의사소통으로 인해 고객과의 요구사항 합의 및 외주 관리가 어려운 경우에도 본 표준명세서가 효과적으로 활용될 수 있다. 특히 최근 대두 되고있는 소프트웨어 분할 발주 제도가 시행되면 본 표준명세서를 이용하여 사용자 요구사항의 명세뿐만 아니라 유즈케이스 명세까지를 포함하여 구현 이전의 기본 설계가 가능하게 된다.
요인으로 작용할 수도 있다. 따라서 표준명세서를 조직 및 프로세스 환경이나 특성에 따라 효과적으로테일러링할 수 있는 방안에 대한 추가 연구가 필요하다. 또한 다양한 산업 도메인(국방, 의료, 건설, 조선 등), 조직 및 프로젝트 규모 별로 특화된 템플릿을 개발함으로써 사용자의 테일러링에 대한 부담과 비용을 줄일 수 있는 방안도 함께 연구되어야 한다.
특히 최근 대두 되고있는 소프트웨어 분할 발주 제도가 시행되면 본 표준명세서를 이용하여 사용자 요구사항의 명세뿐만 아니라 유즈케이스 명세까지를 포함하여 구현 이전의 기본 설계가 가능하게 된다. 또한 기존의 턴키 방식의 소프트웨어 사업 프로세스를 개선하는 데에도 본 표준명세서가 유용하게 활용될 수 있다. 사용자 요구사항의 도출 및 명세는 사전에 용역사업을 통해 개발하고(사전요구사항), 이후 설계 및 구현은 별도의 사업으로 수행될 수 있다.
따라서 표준명세서를 조직 및 프로세스 환경이나 특성에 따라 효과적으로테일러링할 수 있는 방안에 대한 추가 연구가 필요하다. 또한 다양한 산업 도메인(국방, 의료, 건설, 조선 등), 조직 및 프로젝트 규모 별로 특화된 템플릿을 개발함으로써 사용자의 테일러링에 대한 부담과 비용을 줄일 수 있는 방안도 함께 연구되어야 한다. 이 외에도 비기능적 요구사항으로부터 소프트웨어 사업 대가를 산정 예측할 수 있는 방안, 요구사항 리스트를 업무 도메인/시스템별로 정리, 저장, 관리, 재사용할 수 있는 기술에 대한 연구도 필요하다.
또한 다양한 산업 도메인(국방, 의료, 건설, 조선 등), 조직 및 프로젝트 규모 별로 특화된 템플릿을 개발함으로써 사용자의 테일러링에 대한 부담과 비용을 줄일 수 있는 방안도 함께 연구되어야 한다. 이 외에도 비기능적 요구사항으로부터 소프트웨어 사업 대가를 산정 예측할 수 있는 방안, 요구사항 리스트를 업무 도메인/시스템별로 정리, 저장, 관리, 재사용할 수 있는 기술에 대한 연구도 필요하다.
참고문헌 (12)
The Standish Group, Standish Group Report, 2005
ISO/IEC JTC1/SC7 WG4, Study Period Report on Requirement Engineering Tool Capabilities, ISO/IEC JTC1/SC7 WG4, 2004
Karl Wiegers, Software Requirements, Microsoft Press, 2003
Giakoumakis and Xylomenos, 'Evaluation and selection criteria for software requirements specification standards,' IEE/BCS Software Engineering Journal, vol.11, no.5, pp.307-319, 1996
※ AI-Helper는 부적절한 답변을 할 수 있습니다.