요구사항 정의
03. 요구사항 분석 과정
1) 요구사항 분류(Requirement Classification)
1. 요구사항 분류의 개념
- 요구사항이 고수준 요구사항으로부터 요구된 것인지 아니면 이해관계자나 다른 소스로부터 발생한 것인지 분류
- 요구사항이 사용 용이성, 효율성 등에 관한 것인지 입력 처리, 데이터베이스 처리 등에 관한 것인지 분류
- 요구사항 중 중요도에 따라 우선순위를 분류
- 요구사항의 범위를 분류
- 요구사항이 소프트웨어 생명주기 동안에 변경이 발생하는 형상 관리 대상인지 아닌지를 분류
- 요구사항이 기능적 요구사항인지 비기능적 요구사항인지 분류
2. 기능적 요구사항
- 시스템이 수행해야 하는 행위들을 구체화한 것
- 시스템에서 제공해야 할 기능을 정의한 것
- 입력 기능, 출력 기능, 데이터베이스 기능, 통신 기능 등이 있음
3. 비기능적 요구사항
- 시스템이 가져야 하는 기능 이외의 요구사항
- 시스템의 전체적인 품질이나 고려해야 하는 제약사항 등
- 사용 용이성, 효율성, 신뢰성, 이식성, 유연성, 확장성 등이 있음
- 성능적인 면에서는 응답 속도, 자원 사용량 등이 있음
- 보안 측면에서는 침입 대응, 침입 탐지, 사용자 인증, 권한 부여 등이 있음
2) 개념 모델링(Conceptual Modeling)
- 개념 모델링을 통한 요구사항을 분석
- 개념 모델링은 문제가 발생하는 상황에 대한 이해를 증진시키고 해결책을 설명
- 시스템 사용자와 이해관계자, 여러 주변 환경이 시스템과 상호 작용하는 사용 시나리오를 개념 모델로 작성
- 개념 모델은 요구되는 서비스와 기능을 분석
- 개념 모델은 문제 도메인의 엔티티들과 그들의 관계 및 종속성을 반영
- 요구사항을 구체화하기 위해 UML을 사용
- UML
- 요구분석, 설계, 구현 등의 소프트웨어 개발 과정에서 개발자 간의 의사소통을 원활하게 이루지게 하려고 표준화한 모델링 언어
- 모델링에 대한 표현이 정확하고 오류가 적은 논리적인 표기법
- 개발하려는 소프트웨어 규모에 상관없이 모두 적용 가능
3) 요구사항 할당(Requirement Allocation)
- 요구사항을 만족시키기 위한 개발자, 자원, 컴퓨터 시스템, 소프트웨어 기능, 통신 기능, 데이터베이스 기능 등의 구성 요소들을 식별한 후 업무에 맞게 할당
- 식별한 구성 요소와 다른 구성 요소와의 상호 작용이나 호환성 분석을 통하여 추가적인 요구사항이 있는지 파악
4) 요구사항 협상(Requirement Negotiation)
- 두 명의 이해관계자가 서로 의견을 달리할 때 협상이 필요
- 요구사항과 일치하지 않는 자원을 사용해야 하는 경우나 추가적인 자원을 필요로 할 때 협상이 필요
- 기능적 요구사항과 비기능적 요구사항이 서로 상충되는 경우, 한쪽을 선택하기 보다 적절한 트레이드오프 지점에서의 협상이 중요
- 요구사항에 우선순위를 부여하는 것은 중요한 요구사항을 우선 처리할 수 있으며, 요구사항들이 서로 상충되는 문제를 해결하는 데 사용될 수 있음
- 형식적으로 정의된 의미를 지닌 언어로 요구사항을 표현
- 정확하고 명확하게 표현하여 이해관계자 간에 오해를 최소화
- 요구사항 분석의 마지막 단계에서 정혁 분석이 이루어짐
04. 요구사항 확인 과정
1) 요구사항 검토(Requirement Reviews)
- 검토는 소프트웨어 요구사항 명세서, 시스템 정의서, 시스템 사양서를 완성한 시점 등에서 이루어짐
- 요구분석가가 요구사항을 이해했는지 확인하는 것이 필요
- 여러 검토자가 오류, 잘못된 예측, 불명확성, 표준과의 차이 등을 찾아내는 작업이며 검토자 그룹 구성이 가장 중요
- 고객 중심 프로젝트일 경우에는 검토자 그룹에 고객 대표자가 1명 이상은 포함되어야 함
- 요구사항 문서가 회사의 표준에 적합하고 이해 가능하고, 일관성이 있고, 완전한지 검증하는 것이 중요
2) 프로토타이핑(Prototyping)
- 프로토타이핑 소프트웨어 요구사항에 대해 소프트웨어 개발자가 해석한 것을 확인하기 위한 수단으로 많이 사용됨
- 프로토타이핑은 사용자에게 미리 소프트웨어를 보여주어 불분명한 사용자의 요구사항이나 새로운 요구사항을 확인하기 위한 임시 소프트웨어
- 프로토타이핑 분석가의 가정을 파악하고 잘못된 경우 유용한 피드백을 제공받을 수 있음
- 사용자 인터페이스의 동적인 행위가 이론적인 문서나 그래픽 모델보다 프로토타입형 소프트웨어로 이해하기 쉬움
- 사용자가 요구사항을 변경하게(가변성) 되는 경우가 급격히 감소
- 사용자가 소프트웨어 중요 기능에는 관심이 없고, 프로토타입형 소프트웨어의 외적 디자인이나 품질 문제로 집중될 수 있음
- 잘못된 요구사항이 줄어들면서 자원을 낭비하는 것을 방지할 수 있음
3) 모델 검증(Model Verification)
- 분석 단계에서 개발 모델의 품질을 검증할 필요가 있음
- 객체 모델의 경우 객체들 사이에 존재하는 메시지 경로를 검증하기 위하여 정적 분석을 수행하는 것이 유용함
4) 인수 테스트(Acceptance Tests)
- 개발된 소프트웨어가 요구사항을 만족시키는지 확인이 가능해야 함
- 모든 요구사항을 어떻게 테스트할 것인지 계획을 세움
05. 요구사항 검증 과정
1) 요구사항 검증(Verification)
- 요구사항 검증은 요구사항 명세서에 나타난 사용자의 요구사항이 정확하게 적용되었는지에 대해 검토하고 베이스라인으로 설정하는 활동
- 요구사항 검증은 요구사항 검토 계획을 수립하고 많은 이해관계자와 함께 다양한 시각에서 공식적으로 검토하고 승인하는 작업
- 요구사항은 다양하고 요구의 변화가 많이 때문에 요구사항 검증 과정을 통해 모든 요구사항 문제를 발견할 수는 없음
2) 요구사항 검증 절차
1. 요구사항 검토 계획 수립
- 품질 관리 담당자가 요구사항 검토 기준과 검토 방법, 검토 일정과 참여자 등을 포함한 요구사항 검토 계획을 수립
- 인터페이스 요구사항을 검증할 경우, 기술 아키텍처 전문가 또는 인터페이스 전문가가 참여하여 인터페이스 요구사항 점검 방법과 체크리스트 등을 결정
2. 요구사항 명세서 검토와 오류 수정
- 검토 계획 수립 시 선정한 검토 방법과 검토 기준에 따라 요구사항 명세서를 검토
- 명세서가 명세 표준을 준수하고 있는지 검증
- 기술된 용어가 일관성과 표준성, 이해 용이성을 가졌는지 검증
- 요구사항이 서로 상충하지 않았는지 검증
- 요구사항 명세서를 피드백
3. 요구사항 베이스라인 설정
- 검증된 요구사항을 공식적으로 승인
- 소프트웨어 설계와 구현이 필요한 요구사항 명세서의 베이스라인을 설정
- 베이스라인이 정해지면 요구사항의 수정은 공식적인 변경 통제 절차로만 변경할 수 있음
06. 요구사항 검증 방법
1) 요구사항 검토(Requirements Review)
1. Peer Review(동료 검토)
- 2~3명 정도의 검토 담당자가 수행하는 검토
- 다수의 이해관계자에게 요구사항 명세서 작성자가 명세서를 설명
- 이해관계자들이 설명을 들으면서 결함을 발견하는 형태로 진행
2. Walk Through
- 소프트웨어 개발 단계마다 실시하는 비정형 검토회의
- 오류를 조기에 검출하는 것이 목적
- 검토 자료를 회의 전에 배포
- 사전 검토한 후 짧은 시간 동안 회의를 진행
- 오류를 검출하고 문서화
3. Inspection
- 소프트웨어 개발에 참여하지 않은 다른 전문가에 의해 오류를 찾아내는 공식적 검토 방법
- 소프트웨어의 품질을 높이는 방법 중 하나이며 결과물 자체의 품질과 결과물을 만들어내는 과정도 인스펙션에 포함
4. 프로토타입
- 검증하려는 주요 기능이나 일부분을 임시적으로 개발하여 이해관계자나 고객을 대상으로 시연하면서 요구사항을 검증
5. 리펙토링
- 오류를 제거하고 새로운 기능을 추가하는 것이 아니라 결과의 변경 없이 프로그램 소스의 구조를 재조정하는 것
- 리펙토링은 가독성을 높이고 유지보수를 편하게 함
2) 테스트 설계
- 요구사항은 테스트가 가능하도록 작성되어야 함
- 테스트 케이스를 생성하여 요구사항이 현실적으로 테스트 가능한지를 검토
- 테스트 케이스는 송수신 시스템에서 확인해야 할 사항을 각각 도출
- 송수신 시스템에서 각각 개별 데이터의 유효한 값과 송수신 데이터 간 연관 관계를 체크하는 테스트 케이스로 구별해서 작성
- 송수신 코드를 체크할 수 있도록 테스트 케이스를 작성
- 데이터를 데이터베이스에 적용하는 과정에서 오류가 발생하지 않는지 테스트 케이스를 작성
- 데이터베이스에서 참조하는 테이블에 데이터가 없거나 데이터 갱신이나 등록 오류가 발생하는지 테스트 케이스를 작성
3) CASE(Computer Aided Sofrware Engineering)
1. CASE의 개념
- CASE는 소프트웨어를 개발하는 시점부터 요구분석, 설계, 개발, 유지보수에 이르기까기 소프트웨어의 생명주기 전반을 지원하는 프로그램 또는 소프트웨어 개발을 지원하는 자동화 도구 혹은 방법론의 결합
0 소프트웨어 개발 과정의 일부 또는 전체를 자동화하기 위한 도구
- 표준화된 개발 환경 구축 및 문서 자동화 기능을 제공
- 작업 과정 및 데이터 공유를 통해 작업자 간의 커뮤니케이션을 증대
- CASE는 객체지향 시스템뿐만 아니라 구조적인 시스템을 포함해 모든 분야에 적용
- 분산된 환경에서 다양한 이해관계자가 공동 작업할 수 있으며, 테스트 연계 및 결함 관리 등의 기능을 제공하기 때문에 시스템 구축 업무를 효율적으로 수행할 수 있음
- 자동화된 일관성 분석을 제공하는 CASE 도구를 활용할 수 있음
- 대규모 시스템에서는 다양한 이해관계자들이 요구하는 명세서를 검토해야 하고, 복잡한 형상 관리를 수행해야 하기 때문에 요구사항 관리 도구인 CASE를 이용
2. CASE의 분류
- 상위 CASE
- 계획 수립, 요구분석, 기본 설계 단계를 다이어그램으로 표현
- 모델들 사이의 모순 검사 기능, 모델의 오류 검증 기능, 일관성 검증 기능 등을 지원
- 자료 흐름도 작성 기능, UI 설계 기능 등을 지원
- 하위 CASE
- 구문 중심 편집, 정적/동적 테스트 기능 등을 지원
- 시스템 명세서 생성 기능, 소스 코드 생성 기능 등을 지원
- 통합 CASE
3. CASE의 특징
- 소프트웨어 생명주기의 전 단계를 연결
- CASE의 툴 가격은 비싸지만, 소프트웨어를 개발할 수 있는 기간이나 인력을 줄일 수 있기 때문에 전체 개발 비용은 절감
- CASE는 스스로 동작하는 것이 아니므로 분석가의 지원이 필요
- 수정이 용이하며 정확함
- 개발을 신속하게 할 수 있어 개발 기간이 단축
- 프로그램의 유지보수가 간편함
- 생성성 향상
- 재사용성이 높아짐
- 자동화된 검사를 통해 품질 향상
- 그래픽을 지원
- 다양한 소프트웨어 개발 모형을 지원
- CASE 툴 간의 호환성이 없음
- CASE 툴은 전문성을 갖추고 있는 고액의 프로그램이기 때문에 수요가 적고, 따라서 타사 제품의 데이터 형식이나 파일 형식은 고려하지 않음
- 사용자가 많을수록 호환성을 고려해야 하지만 수요가 적으면 호환성은 고려되지 않음
- 요구사항 변경 사항을 추적하고 분석 및 관리할 수 있음
- 표준 준수 여부를 확인할 수 있음
- 분산된 환경에서 다양한 이해관계자가 공동 작업할 수 있음
- 테스트 연계 및 결함 관리 등의 기능을 제공
- 시스템 구축 업무를 효율적으로 수행
- 컴파일러나 인터프리터와 같은 언어 번역 프로그램은 지원하지 않음
- CASE는 소프트웨어 개발자의 보조적인 도구로 소프트웨어가 처리하는 방식이나 운용 방식(일괄 처리, 실시간 처리, 시간 분할 처리 등)이 아님
- CASE는 소프트웨어를 구조적으로 개발할 수 있도록 지원해주거나 개발될 소프트웨어를 미리 가상적으로 확인할 수 있는 프로토타이핑 유형의 소프트웨어를 구현해 주기도 함
- CASE는 물리적인 저장소를 소프트웨어 개발자가 고민하지 않아도 효율적으로 표준화하여 저장할 수 있도록 지원
4) 요구사항 관리
1. 요구사항 협상
- 가용할 자우너과 수용 가능한 위험 수준에서 구현 가능한 기능을 협상하기 위한 기법
2. 요구사항 기준선(Baseline)
3. 요구사항 변경 관리
- 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법
4. 요구사항 확인
- 이해관계자가 기대한 요구사항에 부합되는지 확인하기 위한 검증, 확인 기법
5) 요구사항 분석 자동화 도구(CASE)
1. SADT(Structure Analysis & Design Technique)
- SoftTect사에서 개발된 대규뫃 프로젝트용 요구사항 분석 자동화 도구
- 구조적인 도형 표기와 그것을 효율적으로 수행하기 위한 설계 방법으로 이루어짐
- SADT는 요구분석과 설계 분석, 설계 명세서를 동시에 표현할 수 있는 자동화 도구
2. BS(Brain Storming)의 4가지 규칙
- 비판 금지 : 사용자는 대부분이 초보자이므로 사용자의 의견을 비판하게 되면 사용자에게 얻을 수 있는 문제를 파악하기가 어렵되 되므로 비판을 금지한다.
- 자유 분방 : 어떠한 사용자의 의견도 경청한다.
- 다수 환영 : 사용자의 의견이 많을수록 문제 대상의 접근이 용이하다.
- 연쇄 개선 : 중요한 의견이 나왔을 때 집중적으로 질문한다.
3. PSL/PSA(Program Statement Language/Program Statement Analysis)
- 미시간 대학의 ISDOS 프로젝트에서 개발된 요구분석용 자동화 도구
- 요구분석에 필요한 내용을 PSL이란 기술 언어를 사용하여 작성한 위 PSA에 입력하면 PSA는 분석 데이터베이스에 저장하고 있는 자료를 분석하여 최적의 요구 명세서를 자동으로 출력
4. SPEM(Software Requirement Engineering Methodology), RSL/REVS
- TRW사가 미 국방성의 의뢰로 개발한 실시간 시스템용 요구분석 방법론 및 자동화 도구
- 도형 표기법 R-Net(Requirements Network)과 기술용 언어 RSL(Requirements Statement Language)로 작성된 요구분석의 기본 자료를 REVS(Requirements Statement & Validation System)에 입력하면 REVS는 입력된 RSL을 번역하여 요구분석 데이터베이스에서 RSL에 요구된 사항대로 요구 명세서를 자동으로 출력
07. 요구사항의 기술적 타당성 검토
1) 성능 및 용량 산정의 적정성
- 시스템 용량 산정 방법을 통하여 목표 시스템의 용량이 산정되면, 과거에 개발된 유사 프로젝트 경험치를 적용하여 필요하면 재조정함
- 성능 관련 비기능 요구사항과 비교하여 적정성 여부를 판단
2) 시스템 간 상호 운용성
- 서로 다른 목적을 가지고 있는 2개 이상의 시스템들이 상호 간 정보 및 서비스를 주고 받으면서 효과적으로 운용될 수 있는 시스템의 능력
- 요구사항 중에서 목표 시스템이 다른 시스템과의 연동을 요구하는 경우, 상호 운용이 가능한지 여부를 판단해야 함
3) IT 시장 성숙도 및 트렌드 부합성
- 요구되는 기능별 정보 기술들의 시장 성숙도 및 발전 방향을 파악하고, 요구사항이 이에 적합한지 판단해야 함
- 시장 성숙도가 낮거나, 발전 방향에 적합하지 않은 기술들은 앞으로 사용되지 않을 가능성이 높아 시스템의 유지보수가 어려운 상황이 발생할 수 있음
4) 기술적 위험 분석
1. 복잡성
- 기술의 안정성, 시장성, 개방성을 저해하는 모든 요소
- 하드웨어, 소프트웨어 솔루션의 적용이 아키텍처와 불일치할 수 있음
2. 검증 여부
- 적용 기술에 대한 조직 내 경험자가 없을 수 있음
- 외부 지원이 불가능할 수 있음
3. 의존성
- 특허 및 라이선스에 따른 문제가 있을 수 있음
- 특정 업체 기술에 대한 의존도가 클 수 있음
