요구사항 확인 요구사항 2/2

요구사항 확인 요구사항

요구사항

요구사항 명세 단계

요구사항 명세 단계 주요 기법

비정형 명세 기법

• 사용자의 요구를 표현할 때 자연어를 기반으로 서술하는 기법
• 사용자와 개발자의 이해가 용이
• 명확성 및 검증에 문제

정형 명세 기법

• 사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술하는 기법
• 정형 명세 언어인 Z-스키마, Petri Nets, 상태 차트 활용
• 표현이 간결, 명확성 및 검증이 용이
• 기법의 이해가 어려움

요구사항 명세 원리 및 검증 항목

• 명확성 : 각각의 요구사항 명세 내용은 하나의 의미만 부여해야 함
• 완전성 : 기능, 성능, 속성, 인터페이스, 설계 제약 등에 관한 모든 시스템 요구사항이 포함되어야 함
• 검증 가능성 : 요구사항 내용의 충족 여부와 달성 정도에 대한 확인이 가능해야 함
• 일관성 : 요구사항의 내용 간 상호 모순이 없어야 함
• 수정 용이성 : 요구사항 변경 시 쉽게 수정할 수 있어야 함
• 추적 가능성 : 각 요구사항 근거에 대한 추적과 상호참조가 가능해야 함
• 개발 후 이용성 : 시스템 개발 후 운영 및 유지보수에 효과적인 이용이 가능해야 함

요구사항 확인 및 검증 단계

요구사항 확인 및 검증 절차

1. 요구사항 목록 확인

• 요구사항 목록에서 업무 기능에 대한 요구사항 반영 여부 확인

2. 요구사항 정의서 작성 여부 확인

• 요구사항 목록 중 수용인 경우, 요구사항 정의서(유스케이스 명세서)가 작성되었는지 확인
• 요구사항 정의서(유스케이스 명세서)에서 시스템의 동작 방식을 명확하고 구체적으로 기술하고 있는지 검토

3. 비기능적 요구사항의 확인

• 시스템 특성, 품질, 제약사항 등 비기능적 요구사항이 명확하게 도출되었는지 검토
• 성능, 가용성, 사용 용이성, 유지보수 용이성, 안전성, 보안성 등에 대한 요구사항 문서화 여부 확인

4. 타 시스템 연계 및 인터페이스 요구사항 확인

• 타 시스템 또는 하위 시스템 등과의 모든 인터페이스 요구사항이 정의되어 있는지 확인
• 인터페이스 구분(내부/외부), 주기, 방법, 제공자, 요청자 등이 명확하게 정의되어 있는지 확인

요구사항 정의서 목록

• ID : 명명 규칙에 따라 유일성이 확보되는 식별자가 부여되었는지 확인
• 이름 : 요구사항 내용을 요약하고, 중복되지 않았는지 확인
• 유형 : 기능, 비기능, 제약사항, 기타로 구분되어 있는지 확인
• 품질 속성 : 유형이 비기능일 때 품질 속성으로 성능, 가용성, 유지보수성, 신뢰성, 보안성, 유지보수 용이성, 사용 용이성 등이 명시되어 있는지 확인
• 우선순위 : 필수, 선택, 희망 사항 등으로 구분되어 있는지 확인
• 중요도 : 작성 규칙에 따라 적절한 점수가 부여되어 있는지 확인
• 출처 : 요구사항을 낸 이해관계자의 이름이나 관련 문서명이 기술되어 있는지 확인
• 관련 부서 : 요구사항과 관련된 조직의 부서명이 기술되어 있는지 확인
• 전체 조건 : 요구사항과 관련된 전체 조건이 적절한지 확인
• 내용 : 요구사항의 내용이 명확하고 이해하기 쉽게 기술되어 있는지 확인
• 관련 요구사항 : 관련된 요구사항이 적절한지 확인
• 버전 : 요구사항의 변경 상태에 따라 버전이 관리되고 있는지 확인
• 수용 여부 : 검토 예정, 수용, 거부 등의 수용 여부 진행 상태가 기술되어 있는지 확인

요구사항 확인 및 검증 단계의 주요 기법

요구사항 검토

• 여러 검토자가 에러, 잘못된 가정, 불명확성, 표준과의 차이 검토
• 고객 중심 프로젝트에서는 검토자 그룹에 고객 대표자 1명 이상 포함 필요
• 시스템 정의서, 시스템 사양서, 소프트웨어 요구사항 명세서를 완성한 시점에서 검토

정형 기술 검토 활용

• 동료 검토(Peer Review)
• 워크 스루(Walk Through)
• 인스펙션(Inspection)

프로토타이핑 활용

• 개발할 시스템에 대한 주요 기능이나 일부분을 개발하여 최종 사용자나 고객을 대상으로 시연하면서 시스템이 작동하는 모습을 경험할 수 있게 하여 요구사항을 확인
• 요구사항이 잘못된 경우 유용한 피드백 제공
• 사용자 인터페이스의 동적인 행위에 대한 이해가 문서나 그래픽 모델보다 용이

모델 검증

• 분석 단계에서 개발된 모델의 품질 검증 필요
• 객체 모델의 경우 객체들 사이의 의사소통 경로를 검증하기 위한 정적 분석 수행에 유용

테스트 케이스 및 테스트를 통한 확인

• 요구사항의 중요한 속성은 최종 제품이 요구사항을 만족시키는지 확인할 수 있어야 함
• 각각의 요구사항을 어떻게 확인할 것인지에 대한 계획을 수립하고 테스트 케이스 작성
• 테스트 케이스를 생성한 후에는 단계별 테스트 및 인수 테스트에서 활용
• 인수 테스트에는 알파 테스트와 베타 테스트가 있음

CASE 도구 활용 검증

• 구조화된 요구사항 명세서에 대해서는 자동화된 일관성 분석을 제공하는 CASE 도구 활용 가능
• 대규모 개발 프로젝트에서는 다양한 이해관계자들이 요구사항 명세서 검토가 필요하기 때문에, 요구사항 명세서에 대한 형상 관리 수행이 가능한 CASE 도구 이용

베이스라인(Baseline)을 통한 검증

• 요구사항 변경을 체계적으로 추적하고 통제하는 시점인 베이스라인을 통한 요구사항에 대한 지속적 검증 수행

요구사항 추적표(RTM, Requirement Traceability Matrix)를 통한 검증

• 요구사항 정의서를 기준으로 개발 단계별 최종 산출물이 어떻게 반영되고, 변경되었는지 확인할 수 있는 문서

상세 정형 기술 검토 기법

관리 리뷰(Management Review)

• 프로젝트 진행 상황에 대한 전반적인 검토를 바탕으로 범위, 일정, 인력 등에 대한 통제 및 의사결정을 지원하는 리뷰

기술 리뷰(Technical Review)

• 정의된 계획 및 명세를 준수하고 있는지에 대한 검토를 수행하는 리뷰
• 변경 사항이 적절하게 구현되었는지를 평가하고, 여러 대안을 추천하거나 대안을 검토
• 대표 엔지니어가 주재하며 때에 따라서 관리자도 참가 가능

인스펙션(Inspection)

• 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 또는 팀이 검사하여 문제를 식별하고 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법
• 동료 검토(Peer Review)라고도 함

워크 스루(Walk Through)

• 검토 자료를 회의 전에 배포해서 사전 검토한 후 짧은 시간 동안 회의를 진행하는 형태로 리뷰를 통해 문제 식별, 대안 조사, 개선 활동, 학습 기회를 제공하는 가장 비형식적인 검토 기법

감사(Audit)

• 소프트웨어 제품 및 프로세스가 규제, 표준, 가이드라인, 계획, 절차를 준수하고 있는지를 독립적으로 평가하는 기법
• 감사는 소프트웨어 제품의 제공자, 소비자, 제3기관이 수행

요구사항 관리 단계(CMM Level 2 프로세스 영역)

1. 요구사항 협상

• 가용한 자원과 수용할 수 있는 위험 수준에서 구현할 수 있는 기능을 협상하기 위한 기법
• 우선순위 설정, 시뮬레이션

2. 요구사항 기준선 설정

• 공식적으로 검토되고 합의된 요구사항 명세서를 통해 기준선을 설정하기 위한 방법
• 공식 회의, 형상 관리

3. 요구사항 변경 관리

• 요구사항 기준선을 기반으로 모든 변경을 공식적으로 통제하기 위한 기법
• 형상 통제 위원회(CCB, Configuration Control Board), 영향도 분석

4. 요구사항 확인 및 검증

• 구축된 시스템이 이해관계자가 기대한 요구사항에 부합하는지 확인하기 위한 방법
• 확인 및 검증

요구사항의 시스템화 타당성 분석

요구사항의 기술적 타당성 검토

성능 및 용량 산정의 적정성

• 목표 시스템의 용량이 산정되면, 과거 유사 프로젝트 경험치를 적용하여 필요시 재조정한 후, 성능 관련 비기능 요구사항과 비교하여 적정성 여부 판단

시스템 간 상호운용성(Interoperability)

• 요구사항 중에서 목표 시스템이 조직 내외 타 시스템과의 연동을 요구하는 경우, 상호 운용이 가능한지 여부를 판단

IT 시장 성숙도 및 트렌드 부합성

• 시스템 구축 시 요구되는 영역별 기술들의 시장 성숙도 및 발전 방향을 파악하고, 요구사항이 이에 부합하는지 판단
• 향후 사용되지 않을 가능성이 높은 시스템들은 향후 유지보수가 어려운 상황이 발생

기술적 위험 분석

• 요구사항을 만족하기 위하여 적용한 기술의 복잡성, 검증 여부, 의존성 등에 대하여 위험 발생 가능성, 영향도 파악

요구사항의 기술적 타당성 분석 프로세스

1. 타당성 분석 결과 기록

• 요구사항 목록에 타당성 분석을 위한 속성을 추가하고 타당성 분석 결과를 기록
• 타당성 분석을 위한 속성에는 성능/용량, 시스템 간 상호 운용성, 시장 성숙도 및 트렌드 부합성, 기술 복잡성, 기술 검증 여부, 기술 의존성이 있음

2. 타당성 분석 결과의 이해관계자 검증

• 요구사항의 시스템화 타당성 분석 결과를 요구사항 관련 이해관계자에게 배포하여 사전 검토 요청
• 관련 이해관계자가 모여 시스템화 타당성 분석 결과 검증
• 타당성 분석 결과에 이견이 있는 경우 프로젝트 관리자의 중재 하에 합의 도출

3. 타당성 분석 결과 확인 및 배포/공유

• 이해관계자 검증을 거친 타당성 분석 결과를 의사 결정자가 확인
• 확정된 타당성 분석 결과를 이해관계자에게 배포하여 공유