1. 요구사항의 정의와 중요성
가. 요구사항의 정의
1) 요구사항의 정의(IEEE)
문제의 해결 또는 목적을 달성하기 위하여 요구되거나, 표준이나 명세 등을 만족하기 위하여 시스템이나 시스템 컴포넌트(즉 소프트웨어)가 가져야 하는 조건 또는 역량
"A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document"
2) 요구사항의 다른 정의 (한국정보통신기술협회)
계약, 표준, 명세 또는 다른 형식으로 제시된 문서에 맞추어 시스템이나 시스템 구성요소가 갖춰야 할 조건이나 능력
3) 명시적 요구사항
고객이나 사용자가 공식적으로 요구한 소프트웨어 기능과 품질을 만족하기 위한 조건이나 기능
4) 묵시적 요구사항
고객이 요구하지 않았더라도 소프트웨어가 당연히 제공되어야 한다고 일반적으로 가정되는 사항들
나. 요구사항에서부터 문제가 시작됨
프로젝트 실패의 가장 큰 원인
개발자는 무엇을 개발해야 할지 요구사항에 의하여 프로젝트를 진행
고객도 처음부터 무엇을 요구해야 할지 모름.
사용자도 어떻게 사용하는 것이 편리하고 자신에게 맞는 소프트웨어인지 잘 알지 못함.
결국은 의사소통의 문제로 귀결되는 경우가 많음.
다. 요구사항의 분류
1) 기능적 요구사항
수행될 기능과 관련되어 입력과 출력 및 그들 사이의 처리과정과 피드백의 기능
목표로 하는 제품의 구현을 위해 소프트웨어가 가져야 하는 기능적 속성
예) 파일 저장 기능, 문서편집 기능, 인쇄 기능 등
2) 비기능적 요구사항
제품의 비기능적 품질 기준 등을 만족시키기 위해 소프트웨어가 가져야 하는 성능, 사용의 편의성, 안정성과 같은 특성
시스템의 기능에 관련되지 않는 사항을 나타냄.
예) 성능(응답시간, 처리량), 사용의 용이성, 신뢰도, 이식성, 유지보수성, 보안성, 운용상의 제약 등
라. 소프트웨어 품질 특성
| 분류 | 내용 | |
| 기능적 품질특성 | 기능성(Functionality) | 요구사항에 적합한 기능을 발휘함 |
| 비기능적 품질특성 | 신뢰성(Reliability) | 명시된 조건과 기간 동안 일정 수준 이상의 성능을 유지함 |
| 사용성(Usability) | 사용자 입장에서 시스템 사용의 편리함 여부 | |
| 효율성(Efficiencv) | 개발된 소프트웨어 사용시 조직이나 기업에 미치는 효과와 효율 | |
| 유지보수성(Maintainability) | 운영 시 시스템 보완이나 유지의 편리함 정도 | |
| 이식성(Portability) | 타 시스템 또는 플랫폼에 손쉽게 이식가능 여부 | |
2. 요구사항 개발과 관리 프로세스
가. 요구사항 개발과 관리의 기준
나. 요구사항 개발의 정의
고객이나 사용자로부터 개발될 소프트웨어의 사양을 정확히 도출 및 분석하여 요구사항을 명세화하고, 이를 검증한 결과를 개발자들이 이해할 수 있는 형식으로 서술하는 활동
다. 요구사항 관리의 정의
고객이나 사용자로부터 개발될 요구사항과 프로젝트 계획 및 산출물 간의 일관성을 확보하기 위한 활동
관리에 대한 다음과 같은 상세 활동
요구사항에 대한 이해를 확보
요구사항에 대한 고객 및 사용자와 합의
요구사항의 변경관리 및 추적성 확보
요구사항과 산출물 간의 불일치 사항을 식별 및 개선
3. 요구사항 개발 프로세스
가. 요구사항 개발 프로세스 개요
도출 > 분석 > 명세 > 검증
1) 도출
고객이나 사용자가 원하는 요구사항을 수집
수집된 요구사항을 통해 개발되어야 하는 SW의 기능 및 제약사항을 식별하고 이해하는 활동
고객의 최초 요구사항은 추상적이기 때문에 요구사항 분석가는 정확한 요구사항을 파악해야 함.
요구사항은 계약 및 최초 범위산정의 기본이 됨.
SW를 활용할 조직의 사업기준과 규칙을 참고해야 함.
요구사항 도출 기법
- 인터뷰
프로젝트 관계자들과의 직접적인 대화를 통해 정보를 추출하는 일반적인 요구사항 기법
- 시나리오 기법
SW와 사용자 간의 상호작용을 시나리오로 작성하여 요구사항을 도출
- 관찰
현장에 방문하여 직접 살핌.
2) 분석
도출된 고객의 요구사항을 분석 기법으로 식별 가능한 문제들로 분석하고 요구사항을 이해하는 활동
관계자들로부터 추상적 요구사항을 명세서 작성 전에 완전하고 일관성 있는 요구사항으로 정리하는 활동
기능 요구사항과 비기능 요구사항을 별도로 분리하여 분석할 필요 있음.
SW품질특성을 감안하여 요구사항을 분석하면 좀더 구체적으로 분석할 수 있음.
외부 사용자와의 인터페이스 및 내부 SW모듈 혹은 시스템 구성요소 간의 인터페이스를 정확히 분석해야 함.
분석활동 이후의 설계와 구현을 위한 필요한 정보를 제공할 수 있어야 함.
분석기법
- 구조적 분석기법
SW의 기능을 중심으로 구조적인 이해와 관계성을 분석
SW의 기능을 정의하기 위해서 프로세스들을 도출하고, 데이터 흐름을 정의
예) DFD(Data Flow Diagram)
- 정보공학적 분석기법
조직 전체의 관점에서 정보와 데이터 구조에 초점
데이터의 불일치 문제, 조직전체의 전략적인 활용에 효과를 나타내기 위한 노력으로 탄생
예) ERD(Entity Relationship Diagram)
- 객체지향적 분석기법
요구사항을 사용자 중심의 시나리오 분석을 통해 유스케이스 모델로 분석하는 방법
요구사항을 도출하고, 유스케이스 실체화(Realization) 과정을 통해 도출된 요구사항을 분석
3) 명세
분석된 요구사항을 명확하고 완전하게 기록하는 것
소프트웨어 시스템이 수행하여야 할 모든 기능과 시스템에 관련된 구현상의 제약조건 및 개발자와 사용자가 합의한 성능에 관한 사항 등을 명세
최종결과물: 요구사항 명세서(SRS: Software Requirement Specification)
프로젝트 산출물 중 가장 중요한 문서
SW가 어떻게 수행될 것인가(How)가 아닌 무엇을 수행할 것인가(What)에 대한 기술
SW가 이루어야 할 목표를 기술하지만 목표를 달성하기 위한 해결방법(How)은 기술하지 않음.
명세를 위한 고려사항
SW 품질특성 6가지
SW와 연계되는 외부 인터페이스
SW 개발과 관련된 제약사항(법/제도, 환경, 사업기준/규칙, 기술의 한계)
요구사항 명세서 작성을 위한 Tip
SW가 수행할 모든 기능과 제약조건을 명확하게 기술
기술된 모든 요구사항은 검증이 가능할 수 있도록 풀질, 상대적 중요도, 검증 방법 및 기준 등을 명확하게 제시
아직은 특정한 구조나 알고리즘을 사용하여 설계하지 않도록 함.
관련자들이 SW의 기능을 이해하거나 변경에 대한 영향 분석을 위하여 계층적으로 구성
요구사항을 쉽게 참조할 수 있도록 고유의 식별자를 가지고 ID를 부여
모든 요구사항이 동등한 것이 아니며, 모든 SW로 구현하는 것이 아니기 때문에 요구사항을 우선순위화하고 개발범위를 정할 수 있도록 함.
4) 검증
관련자의 요구사항이 요구사항 명세서에 올바르게 기술되었는가에 대해 검토하는 활동
검증 목적
요구사항이 설계기준에 따라 하드웨어 형상 항목, 소프트웨어 형상 항목 등에 적절하게 할당되었는지 검증
안전, 보안 등 위험성과 관련된 소프트웨어 품질 특성 요구사항이 정확한지 검증
기술적 실현가능성의 검증
검증을 위한 질문 (예)
요구사항이 사용자나 고객의 목적을 완전하게 서술되어 있는가?
요구사항 명세가 문서작성 표준을 따르고 있는가?
명세서를 기준으로 설계작업의 진행이 가능한가?
요구사항 명세서가 일관성과 완전성을 가지는가?
검증의 완료 및 베이스라인
요구사항 명세서에 대한 고객의 승인
승인된 명세서는 버전 1.0으로 확인 -> Baselined
베이스라인은 요구사항 개발과 요구사항 관리를 구분하는 기준선이 됨.
