요구사항 : 문제의 해결을 위하여 시스템이 가져야 하는 기능 또는 제약조건
- 고객이 직접 요구한 사항
- 고객 마음 속에 내포된 사항
- 요구하지 않았더라도 당연히 제공될 것이라고 생각되는 사항
요구사항 분석의 중요성
- 참여자들로 하여금 개발되는 소프트웨어 제품을 전체적으로 파악하게 함으로써 의사소통 시간을 절약
- 상세한 요구사항 있어야 규모 산정이 가능하고, 이를 기반으로 계획을 세울 수 있음
요구사항의 분류
- 기능적 요구사항 (Functional Requirements):
소프트웨어가 가져야 하는 기능적 속성 (ex. 파일 저장 기능, 편집 기능, 보기 기능)
target SW specific, 사용자로부터 얻어낼 수 있다
- 비기능적 요구사항 (Non-Functional Requirements):
품질 기능을 만족시키기 위해 소프트웨어가 가져야하는 성능, 사용성, 안정성과 같은 품질 속성
Non target specific, 통상적 요구 레벨이 존재하고, 제품 품질과 직결되기 때문에 상당히 중요
(ex. 응답시간, 처리량, 사용 용이성, 신뢰도, 보안성, 안정성 등)
요구사항 분석의 어려움
- 이해력 부족: 전문성 부족으로 사용자의 요구를 잘못 이해하거나 필수 요구를 누락할 가능성
- 의사소통 문제: 사용자가 요구사항 설명 어려워 일관성 없거나 불완전한 요구사항이 도출
- 변화하는 요구사항
- 애매모호한 요구사항: 일관성이 없거나 모순된 요구사항이 도출
- tacoma narrows bridge
요구사항 분석
고객으로부터 SW제품의 사양을 정확히 도출하고, 이를 분석하여 개발자들이 이해할 수 있는 형식으로 기술하는 작업
요구사항 분석 단계: 각 단계는 모두 "요구사항 관리"
- 요구사항 추출
- 요구사항 분석
- 요구사항 명세
- 요구사항 검증
(1) 요구사항 추출
- 의미
요구사항을 수집하는 단계
시스템에 대한 기능 및 제약사항을 식별하고 이해
- 중요성
최초 요구사항은 추상적이기 때문에 정확한 요구사항 파악해야함
요구사항은 계약 및 최초 산정의 기본이 된다
- 방법: 인터뷰/설문조사, 시나리오(시스템과 사용자 간), 관찰
(2) 요구사항 분석
- 의미: 추출된 요구사항을 분석 기법을 이용하여 식별/이해 가능한 요구사항으로 정제
- 중요성
추상적 요구사항을. 완전하고 일관성 있는 요구사항으로 발전시켜야함
분석 이후 설계 및 구현 단계에 필요한 정보 제공할 수 있어야함
- 구조적 분석 (Structured Analysis)
시스템의 기능을 중심으로 분석
시스템의 기능을 정의하기 위해서 프로세스들을 도출하고, 도출된 프로세스 간의 데이터 흐름을 정의
예) 자료흐름도 (Data Flow Diagram)
- 객체지향 분석 (Object-Oriented Analysis)
사용자 중심의 시나리오를 중심으로 분석
예) 유스케이스 모델(Use-case Model)
- 정보공학 분석 (Data-Oriented Analysis)
자료 또는 데이터를 중심으로 분석
자료를 처리하기 위해 필요한 기능을 도출하고 정제
예) ER 다이어그램
(3) 요구사항 명세
▪ 의미
- 분석된 요구사항을 명확하고 완전하게 기록하는 활동
- 소프트웨어가 수행하여야 할 모든 기능과 구현 상의 제약 조건 및 개발자와 사용자가 합의한 품질에 관한 사항 등을 명세
▪ 최종 결과물
- 요구사항 명세서 (SRS: Software Requirement Specification)
요구사항 명세서(SRS)
• 프로젝트 산출물 중 가장 중요한 문서
• 시스템이 어떻게 수행될 것인지가 아닌 무엇을 수행할 것인가에 대한 기술서
- 시스템이 이루어야 할 목표를 기술
- 목표 달성을 위한 해결 방법은 주로 기술하지 않음
• 사용자, 분석가, 개발자 및 테스터 모두에게 공동의 목표를 제시
명세 vs 문서화: 명세는 문서화보다 정형화된 형태로 기록한다
작성 시 유의 사항
▪ 시스템 기능과 제약 조건을 기술
▪ 요구사항의 검증 방법 및 기준 명시
▪ 시스템의 외부적 행위를 기술하는 것이므로 특정 구조나 알고리즘을 명시하지 않도록 함
▪ 변경에 대한 영향 분석 등을 위하여 계층적으로 구성
▪ 쉽게 참조할 수 있도록 고유의 식별자를 가지고 번호화
▪ 우선 순위화
비정형적 명세 기법
• 자연어나 다이어그램을 이용
• 의사전달 용이
• 애매모호한 표현이 가능해, 해석이 달라질 수 있음
• 완전성을 검증하기 어려움 (요구사항이 충분한지 검증하기 어려움)
정형적 명세 기법
• 수학적 원리와 표기법 이용
• 정확하고 간결
• 일관성/완전성 검증이 용이
• 수학적 표기법 이해하고 있어야 사용 가능
(4) 요구사항 검증
사용자 요구가 요구사항 명세서에 올바르게 기술되었는가에 대해 검토
▪ 검증 내용
- 요구사항이 사용자나 고객의 목적을 완전하게 기술하는가?
- 요구사항 명세가 문서 표준을 따르고, 설계 단계의 기초로 적합한가?
- 요구사항 명세서의 내부적 일치성과 완전성이 있는가?
무결성(correctness) / 완전성(completeness): 사용자 요구를 에러 없이 완전하게 반영하고 있는가?
일관성(consistency): 요구사항이 서로간에 모순되지 않는가?
명확성(unambiguous): 모호함 없이 모든 참여자들에 의해 명확하게 이해될 수 있는가?
기능성(functional): 요구사항 명세서가 “어떻게” 보다 “무엇을”에 관점을 두고 기술되었는가?
검증 가능성(verifiable): 기술된 내용이 사용자의 요구를 만족하는가?
추적 가능성(traceable): 요구사항과 설계문서를 추적할 수 있는가?
vysryoo