요구사항 개발 프로세스 _도출,분석,명세,검증
요구사항 개발 프로세스
전반적인 요구사항 개발 프로세스는 4가지 과정을 거친다.
도출 -> 분석 -> 명세 -> 검증
1. 도출
1. 고객이나 사용자가 원하는 요구사항을 수집하는 과정으로 가장 기본적인 과정이다.
2. 수집된 요구사항을 통해 개발되어야 하는 SW의 기능 및 제약사항을 식별하고 이해하는 활동이다.
3. 고객의 최초 요구사항은 추상적이기 때문에 요구사항 분석가는 정확한 요구사항을 파악해야 한다.
4. 요구사항은 계약 및 최초 범위산정의 기본이 된다.
5. SW를 활용할 조직의 사업기준과 규칙을 법과제도에 벗어나지 않은 범위 내에서 참고해야 한다.
요구사항 도출 기법
1.인터뷰
프로젝트 관계자들과의 직접적인 대화를 통해 정보를 추출하는 일반적인 요구사항 기법
두 가지 인터뷰방법이 있는데 어떤 방법을 하더라도 '인터뷰 결과서' 문서화로 산출되어야 한다.
- OPEN 인터뷰 : 개방인터뷰, 당사자들과 만날 때 질문, 답변을 준비하지 않고 격의 없이 즉흥적인 인터뷰를 말한다.
- CLOSED 인터뷰 : 폐쇄인터뷰, 개방인터뷰와 반대이다. 사전에 질문, 답변 List를 준비해서 각본대로 진행된다.
즉흥성이 없어 한계가 정해져 있지만 신중한 답변을 내놓을 수 있다는 장점이 있다.
2. 시나리오 기법
SW와 사용자 간에 상호작용을 시나리오를 작성하여 요구사항을 도출하는 방법이다.
3. 관찰 기법
개발할 개발자가 현장에 방문하여 직접 살피는 기법이다.
예 ) 사용자의 실제 구매 패턴을 살펴보는 것
2. 분석
관계자들로부터 추상적 요구사항을 명세서 작성 전에 완전하고 일관성 있는 요구사항으로 정리하는 활동이다.
도출된 고객의 요구사항은 정제되지 않아 추상적이며 구현하기에 어려운 비현실적일 수 있는데
다양한 분석 기법으로 보다 현실적으로 구현이 가능한 요구사항으로 만드는 활동이다.
기능 요구사항과 비기능 요구사항을 별도로 분리하여 분석할 필요가 있다.
기능적인 요구사항은 필수적, 비기능요구사항은 반드시 필요하지는 않지만 2차적인 성능, 편리성이다.
분리하는 것은 어떤 것이 더 우선적이냐를 파악하기에 중요하기 때문이다.
SW품질특성을 감안하여 요구사항을 분석하면 좀 더 구체적으로 분석할 수 있다.
여섯 가지 소프트웨어 품질특성(기능적, 비기능적)
외부 사용자와의 인터페이스 및 내부 SW모듈 혹은 시스템 구성요소 간의 인터페이스를 정확히 분석해야 한다.
정확히 분석하면 각각의 영역에 있어서 각자 다른 구성원들이 보는 인터페이스를 보다 완벽하게 정의할 수 있다.
분석활동 이후의 설계와 구현을 위한 필요한 정보를 제공할 수 있어야 한다.
분석단계에서 제대로 하지 않는다면 후속단계에서 문제가 발생할 수 있다.
분석단계에서 완벽하게 실현가능하고, 일관성 있게 정의를 내준다면 그 이후에 있어서 개발단계가 보다 쉬워진다.
분석기법
1. 구조적 분석기법
2. 정보공학적 분석기법
3. 객체지향적 분석기법
1. 구조적 분석기법
- 구조적 분석기법은 한마디로 해서 SW기능을 표현하는 것이다.
- SW의 기능을 중심으로 구조적인 이해와 관계성을 분석한다.
- SW의 기능을 정의하기 위해서 프로세스들을 도출하고, 데이터 흐름을 정의할 수 있는데
- 구조적 분석기법에 가장 많이 쓰이는 도구: DFD (Data Flow Diagram) 자료흐름도
DFD는 4가지 기호를 통해서 표현할 수 있다.
1. ㄷ : 자료저장소
2. ㅁ : 프로세스
3. -> : 데이터 흐름
4. 음영 있는 ㅁ : 외부엔터티 : 자료를 주고받는 주체
2. 정보공학적 분석기법
- 조직 전체의 관점에서 정보와 데이터 구조에 초점을 맞춘다.
- 데이터의 불일치 문제, 조직전체의 전략적인 활용에 효과를 나타내기 위한 노력으로 탄생이 되었다.
대표적인 방법은 E-R Diagram
E: Entity 개체, R : Relation 관계 즉, 한국말로 개체관계도, 개체관계흐름도라고 부른다.
예) 회원, 상품 두 가지 개체를 정의, 개체와 개체를 이어주는 주문 관계
회원과 상품 두 개체 사이에는 주문이라는 관계가 설정된다. 개체와 개체 사이를 이어주는 것이 관계라고 부른다.
회원이 만약 상품을 구입하면 주문이라는 관계를 통해서 회원과 상품 간에 관계가 설정된다.
관계에 있어서 다양한 릴레이션쉽 회원과 상품사이에 N:M (Many to Many) 관계가 설정된다.
하나의 회원이 여러 개의 상품을 구입할 수 있고, 반대로 하나의 상품은 여러 사람이 구입할 수 있다.
각각의 개체나 관계는 다양한 속성.
속성이라는 것은 entity 개체가 갖고 있는 다양한 성질을 속성이라고 부른다. 관계도 다양한 속성을 포함할 수 있다.
1. 회원은 회원번호, 이름, 이런 것들이 속성이 된다.
2. 상품은 상품번호, 상품명, 이런것들이 속성이 된다.
3. 주문은 주문번호라는 속성을 가질 수 있다.
3. 객체지향적 분석기법
요구사항을 사용자 중심의 시나리오 분석을 통해 유스케이스 모델로 분석하는 방법이다.
- 요구사항을 도출하고 유스케이스 실체화 (Realization) 과정을 통해 도출된 요구사항을 분석한다.
예) 유스케이스 모델로 분석 ) 도서관 사서
1. 도서검색, 도서등록, 도서수정, 도서삭제 등 주요 임무를 표시하는 것이 유스케이스의 첫 번째 나타내는 것이다.
2. 두 번째는 흐름도이다. 사서가 일하는데 시작 -> 종료 가 있는데 정상적인 흐름도가 있고 비정상적인 흐름도가 있다.
어떤 이유에 의해서 종료가 되는 비정상적인 흐름도 표현할 수 있다. 예외적인 질문이 있을 경우 다시 시작으로 돌아가
시작하는 예외적인 흐름도 표현할 수 있다. 이런 종합적인 흐름을 표현하는 것이 유스케이스의 대표적인 2번째 부분이다.
3. 명세
분석된 요구사항을 명확하고 완전하게 기록하는 것을 말한다.
소프트웨어 시스템이 수행하여야 할 모든 기능과 시스템에 관련된 구현상의 제약조건 및 개발자와 사용자가 합의한 성능에 관한 사항 등을 명세한다.
keyword
모든 기능
기능적인 필수적인 요구사항
구현상의 제약조건, 합의한 성능
비기능적인 요구사항
최종경과물
요구사항 명세서 (SRS : Software Requirement Specification)
요구사항 명세서
- 프로젝트 산출물 중 가장 중요한 문서이다.
- SW가 어떻게 수행될 것인가(How)가 아닌 무엇을 수행할 것인가(What)에 대해 기술한 것이다.
- SW가 이루어야 할 목표를 기술하지만 목표를 달성하기 위한 해결방법은 기술하지 않는다.
명세를 위한 고려사항
- SW 품질특성 6가지 (기능적, 비기능적)를 완벽하게 기술해야 한다.
- SW와 연계되는 외부 인터페이스 즉, 사용자 인터페이스를 고려해야 한다.
- SW 개발과 관련된 제약사항을 분명히 명세해야 한다.
- 개발하는 데에 있어 법/제도에 걸림돌이가 되지 않는 것을 명세해야한다. 법/제도내에서 허용되고있음을 명세해야한다.
- 구현하는, 개발하는 환경에 대해서도 기술할 필요가 있다.
- 개발하는 업체의 사업기준/규칙을 벗어나지 않는것을 기술할 필요가 있다.
- 기술의 한계도 명세서에 포함되어야 한다.
요구사항 명세서 작성을 위한 Tip
- SW가 수행할 모든 기능과 제약조건을 명확하게 기술해야 한다.
- 기술된 모든 요구사항은 검증이 가능할 수 있도록 품질, 상대적 중요도(우선순위), 검증 방법 및 기준 등을 명확하게 제시해서 검증단계를 쉽게 해야 한다.
- 아직은 특정한 구조나 알고리즘을 사용하여 설계하지 않도록 하는 것이 원칙이다.
알고리즘은 How에 관한 부분이기 때문에 What에 집중해야 된다.
- 관련자들이 SW의 기능을 이해하거나 변경에 대한 영향 분석을 위하여 계층적으로 구성해 보다 이해하기 쉽게 한다.
- 추상적으로 걸어놓는 것이 아닌 요구사항을 쉽게 참조할 수 있도록 고유의 식별자를 가지고 ID를 부여한다.
- 모든 요구사항이 동등한 것이 아니며, 모든 SW로 구현하는 것이 아니기 때문에 요구사항을 우선순위화하고 개발범위를 정할 수 있도록 한다.
4. 검증
관련자의 요구사항이 요구사항 명세서에 올바르게 기술되어 있는가에 대해 검토하는 활동이다.
검증 목적
1. 요구사항이 설계기준에 따라 하드웨어 형상 항목, 소프트웨어 형상 항목 등에 적절하게 할당되었는지 검증
2. 안전, 보안, 및 위험성과 관련된 소프트웨어 품질 특성 요구사항이 정확하게 기술되어 있는가를 검증
3. 기술적 실현가능성의 검증 : 아무리 좋은 소프트웨어를 만들더라도 비용이라던가의 한계, 제약점이 있는지 검증
검증을 올바르게 하기 위한 질문
예)
- 요구사항이 사용자나 고객의 목적을 완벽하게 충족하게 서술되어 있는가?
- 요구사항 명세가 문서작성 표준을 따르고 있는가?
아무리 명세를 잘한다고 하더라도 올바르지 않은 절차를 따르면 안 된다.
그래서 절차가 표준으로 되어있는가를 질문해야 한다.
- 명세서를 기준으로 설계작업의 진행이 가능한가?
- 요구사항 명세서가 일관성과 완전성을 가지는가? (완전성= 빠져있는 부분이 없는 것, 애매한 부분을 명쾌하게 정의한 것)
...
검증의 완료 및 베이스라인
검증이 완료되면 베이스라인을 설정한다.
- 요구사항 명세서에 대한 고객의 승인이 떨어지면
- 승인된 명세서는 버전 1.0으로 확인된다.
참고사이트 - 메가존아이티평생교육원 | 소프트웨어 공학 | 전우천