요구사항 분석
요구사항 분석(Requirements analysis)은 시스템 공학과 소프트웨어 공학 분야에서 수혜자 또는 사용자와 같은 다양한 이해관계자의 상충할 수도 있는 요구사항을 고려하여 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 것과 같은 업무를 포함한다.
| 소프트웨어 개발 프로세스 | |
|---|---|
| 활동과 단계 | |
| 요구사항 분석 · 기능 명세 구조 · 설계 구현 · 테스팅 배치 · 유지보수 | |
| 개발 모형 | |
| 애자일 소프트웨어 개발 · 클린룸 DSDM · 순차점증적 개발 · 반복형 개발 RAD · RUP · 나선 모형 폭포수 모델 · 익스트림 프로그래밍 스크럼 · V 모델 · TDD | |
| 지원 활동 | |
| 구성 관리 · 문서화 품질보증 · 프로젝트 관리 사용자 경험 설계 | |
| 도구 | |
| 컴파일러 · 디버거 · 프로파일러 GUI 디자이너 · 통합 개발 환경 | |
체계적인 요구사항 분석은 요구사항 공학으로도 알려져 있다. 이 밖에도 요구사항 수집, 요구사항 획득, 요구사항 명세와 같은 부정확한 용어들이 이따금씩 사용되기도 한다.
요구사항 분석은 개발 과제의 성공에 결정적이다. 식별된 업무의 필요성과 기회와 관련하여 실행 가능하며, 측정 가능하고, 시험 가능하며 시스템 설계를 위해 충분히 상세한 수준까지 정의되어야 한다.
개요
편집개념적으로 요구사항 분석은 다음의 세 가지 유형의 행위를 포함한다.
- 요구사항의 유도: 요구사항이 무엇인지를 결정하기 위해 고객 및 사용자와 대화하는 작업. 요구사항 수집이라고도 불린다.
- 요구사항의 분석: 언급된 요구사항이 불명확하거나 불완전하거나 모호하거나 모순되는지를 결정하고 해결하는 것을 가리킨다.
- 요구사항의 기록: 요구사항은 자연 언어 문서, 유스 케이스, 사용자 스토리 또는 공정 명세서와 같은 다양한 형식으로 문서화되어야 한다.
요구사항 분석은 지루하고 힘든 과정이며, 그 동안 많은 섬세하고 심리적인 기술이 관련된다. 새로운 시스템은 환경과 사람들간의 관계를 변경시키므로, 모든 이해 관계자를 식별하고, 그들 모두의 요구를 고려하며, 새로운 시스템의 결과를 그들에게 이해시키는 것이 중요하다.
분석가는 고객으로부터의 요구사항을 유도하기 위해 몇 가지 기술을 사용할 수 있다. 역사적으로 분석가들은 면담을 하거나 포커스 그룹과의 워크샵을 갖거나, 혹은 요구사항 목록을 작성하는 등의 기술을 사용해 왔다. 더욱 발전된 기술로는 프로토타이핑이나 유즈 케이스 작성 등을 사용할 수 있다. 분석가는 이러한 기술들 중 필요한 것을 적절히 조합하여 고객의 요구사항을 충족시켜야 한다.
요구사항의 종류
편집이 문단은 아직 미완성입니다. 여러분의 지식으로 알차게 문서를 완성해 갑시다. |
요구사항은 몇 가지 방법으로 분류된다. 아래의 분류는 기술적 관리와 관련한 일반적인 요구사항 분류법이다.
- 고객 요구사항
- 시스템의 목적, 주어진 환경과 제한 조건, 변경의 유효성과 적합성의 관점에서 시스템의 기대 사항을 정의하는 사실 및 가정을 서술한 것(MOE/MOS).
- 기능 요구사항
- 기능 요구사항은 반드시 구현되어야 할 필수적인 작업과 동작 등을 정의함으로써 어떤 기능이 구현되어야 하는지를 설명한다.
- 비기능 요구사항
- 비기능 요구사항은 특정 기능보다는 전체 시스템의 동작을 평가하는 척도를 정의한다.
- 성능 요구사항
어떤 기능이 동작해야 하는 한계를 정의한다. 이는 보통 자료의 양이나 질, 동작의 적시성과 민첩성 등의 척도로 기술된다.
- 설계 요구사항
- 유도된 요구사항
- 할당된 요구사항
같이 보기
편집외부 링크
편집
- Requirements Engineering Process "Goodies"
- Requirements Engineering: A Roadmap (PDF) article by Bashar Nuseibeh and Steve Easterbrook, 2000.
- Undreamt Requirements Analysis
- Getting Started With Use Cases