요구공학
요구공학은 사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동이다.
기능적 요구사항
- 시스템이 제공하는 기능, 서비스에 대한 요구사항
- 이를테면 온라인 홈페이지에선 쇼핑카트에 주문할 품목을 저장하는 장바구니 기능이 제공돼야 한다는 것이 있다.
비기능적 요구사항
- 시스템이 수행하는 기능 이외의 사항(제약사항에 대한 요구사항이 포함됨)
- 특정 함수의 호출시간은 3초를 넘지 않아야 한다는 것
요구사항 개발 단계 구성(CMM Level 3 프로세스 영역)
- 요구사항 개발은 요구사항 도출, 분석, 명세, 확인 및 검증 단계로 구성되어 있다.
- 도출
- 요구사항 소스
- 도출 기법
- 분석
- 요구사항 분류
- 개념 모델링
- 기술 구조 설계 및 요구사항 할당
- 요구사항 협상
- 명세
- 시스템 정의서
- 시스템 요구사항 명세서
- 소프트웨어 요구사항 명세서
- 확인
- 검토
- 프로토타이핑
- 모델 검증
- 인수 테스트
좀더 구체적으로 말하자면..
- 요구사항 도출
- 소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집방법 결정, 수집된 요구를 구체적으로 표현하는 단계
- 도출 단계에서 이해관계자가 식별되고, 개발팀과 고객 사이의 관계가 형성되며 다양한 이해관계자와 효율적인 의사소통이 중요하다.
- 주요 활동으로는 고객 분석, 조직 환경 분석, 후보 요구사항 분류, 후보 요구사항 정제, 요구사항 소스 관리가 있다.
- 요구사항 분석
- 도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계
- 요구사항 간 상충 부분을 해결하고, 소프트웨어의 범위를 파악하며, 소프트웨어가 환경과 ㅇ떻게 상호작용하는지 이해하는 단계
- 주요 활동으로는 시스템 요구사항을 정제하여 소프트웨어 요구사항 분류, 후보 요구사항 모델링, 요구사항의 우선순위 부여, 해당 릴리즈에 수행할 요구사항 선정, 요구사항 협의가 있다.
- 요구사항 분석 활동으로 비용과 일정에 대한 제약설정, 타당성 조사, 요구사항 정의 문서화 수행이 있다.
- 요구사항 명세
- 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계
- 동의한 요구사항을 하나 이상의 형태로 저장하여 정형화된 요구사항을 생성하는 활동 수행
- 주요 활동으로 요구사항 명세 기준 정의, 요구사항 명세서 작성, 요구사항 추적 관련 정보 저장이 있다.
- 요구사항 확인 및 검증
- 분석가가 요구사항을 이해했는지 확인하고, 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관적이고 완전한지 검증하는 단계이다.
- 요구사항 명세서 검토, 요구사항 용어 검증, 요구사항 베이스라인을 수립한다.
- 리로스가 요구사항에 할당되기 전 문제를 파악하기 위해 검증을 수행한다.
요구사항 분석 단계 절차
- 요구사항 분류
- 요구사항이 기능인지 비기능인지 확인한다.
- 요구사항이 소프트웨어에 미치는 영향의 범위를 파악한다.
- 개념 모델링 생성 및 분석
- 요구사항을 더 쉽게 이해할 수 있도록 현실 세계의 상황을 단순화, 개념적으로 표현한 것을 모델이라 하며, 모델링은 이러한 모델을 만드는 활동이다.
- 유스케이스 다이어그램(Use Case Diagram), 데이터 흐름 모델(Data Flow Model), 상태 모델(State Model), 목표 기반 모델(Goal-Based Model), 사용자 인터랙션(User Interactions), 객체 모델(Object Model), 데이터 모델(Data Model)과 같은 다양한 개념 모델 작성이 가능하다.
- 모델링 표기는 주로 UML을 사용한다.
- 요구사항 할당
- 요구사항을 만족시키기 위한 아키텍처 구성요소를 식별한다.
- 다른 구성요소와 상호작용하는 방식을 분석하여 추가적인 요구사항을 발견할 수 있다.
- 요구사항 협상
- 두 명의 이해관계자가 서로 상충되는 내용을 요구할 때 적절한 선에서 합의하기 위한 목적을 지닌다.
- 요구사항이 서로 충돌할 때 각각에 우선순위를 부여하여 중요도를 인식할 수 있어 문제해결에 도움을 준다.
- 정형 분석
- 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현
- 구문과 의미를 갖는 정형화된 언어를 사용하여 수학적 기호로 표현
- 요구사항 분석의 마지막 단계에서 이뤄짐
요구사항 명세 단계
요구사항 명세 단계는 체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계이다.
- 비정형 명세 기법
- 사용자의 요구를 표현할 때 자연어를 기반으로 서술
- 사용자 및 개발자의 이해가 용이하나 명확성 및 검증 측면에서 문제될 수 있다.
- 정형 명세 기법
- 사용자의 요구를 표현할 때 수학적 원리와 표기법으로 서술
- Z-스키마, Petri Nets, 상태차트 등 정형 명세 언어를 사용한다.
- 표현이 간결하고 명확하며, 검증이 쉽지만 기법 이해가 어렵다는 단점이 있다.
요구사항 확인 및 검증 단계의 주요 기법
- 요구사항 검토
- 여러 검토자들이 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
- 고객 중심 프로젝트에선 검토자 그룹에 고객 대표자 1명 이상 포함 필요
- 정형 기술 검토 활용
- 동료 검토(Peer Review)
2~3명이 진행하는 리뷰 형태
요구사항 명세서 작성자가 요구사항 명세서를 설명하고, 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행 - 워크 스루(Walk Through)
오류를 조기 검출하는 목적
검토 자료를 회의 전 배포하여 사전검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 오류를 검출하고 문서화 - 인스펙션(Inspection)
소프트웨어 요구, 설계, 원시 코드 등 저작자 외 다른 전문가 혹은 팀이 검사하여 오류를 찾아내는 공식적 검토 방법
- 프로토타이핑 활용
- 개발할 시스템에 대한 주요 기능이나 일부분을 개발하여 최종 사용자나 고객을 대상으로 시연하면서 시스템이 작동하는 모습을 확인하게 하여 요구사항 검증
- 모델 검증
- 분석 단계에서 개발된 모델의 품질 검증 필요
- 객체 모델의 경우 객체 사이의 의사소통 경로를 검증하기 위한 정적 분석수행에 유용
- 테스트 케이스 및 테스트를 통한 확인
- 요구사항의 중요한 속성은 최종 제품이 요구사항을 만족시키는지 확인 가능해야 한다는 것이다.
- 각 요구사항을 어찌 확인할 것인지에 대한 계획을 수립하고 테스트 케이스를 작성한다.
- 테스트 케이스를 생성한 후엔 단계별 테스트 및 인수 테스트에서 활용한다.
- 인수 테스트엔 알파 테스트와 베타 테스트가 있음
요구사항 관리 단계(CMM Level 2 프로세스 영역)
- 요구사항 관리는 프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 변경제어와 추적 등 일련의 관리를 수행하는 활동이다.
- 주요 산출물로 요구사항 변경요청서, 요구사항 변경승인서, 요구사항 추적표가 있다.
절차
- 요구사항 협상: 가용한 자원과 수용가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 방법
- 우선순위 설정, 시뮬레이션
- 요구사항 기준선 설정: 공식적으로 검토되고 합의된 요구사항 명세서를 통해 기준선을 설정하기 위한 방법
- 공식 회의, 형상 관리
- 요구사항 변경관리: 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법
- 형상통제 위원회, 영향도 분석
- 요구사항 확인 및 검증: 구축된 시스템이 이해관계자가 기대한 요구사항에 부합하는지 확인하기 위한 방법
- 확인 및 검증
