나도개발자

요구사항

1) 요구공학이란?

사용자의 요구가 반영된 시스템을 개발하기 위해 사용자 요구사항에 대한 도출, 분석, 명세, 확인 및 검증하는 구조화된 활동.

2) 요구공학의 목적

이해 관계자 사이에 효과적인 의사소통 수단을 제공하고 시스템 개발의 요구사항에 대한 공통된 이해를 설정.

요구사항 누락 방지 및 이해 오류로 인한 불필요한 비용을 절감하고 요구사항 변경 추적을 가능하게 함.

초기 요구사항 관리로 개발 비용과 시간을 절약하고 효과적인 의사소통 수단 제공.

[ 기능적 요구사항 ]

시스템이 제공하는 기능 및 서비스에 대한 요구사항.

특정 입력 및 상황에 대해 시스템이 어떻게 반응 및 동작해야하는지에 대한 기술.

기능성 / 완전성 / 일관성

[ 비기능적 요구사항 ]

시스템이 수행하는 기능 이외의 사항, 시스템 구축에 대한 제약사항에 관한 요구사항.

품질 속성에 관련하여 시스템이 갖춰야 할 사항 및 시스템이 준수해야 할 제한 조건에 관한 기술.

신뢰성 / 사용성 / 효율성 / 유지보수성 / 이식성 / 보안성 / 품질 관련 요구사항 / 제약사항

3) 요구사항 개발 단계 구성 (CMM Level 3 프로세스 영역)

도출 -> 분석 -> 명세 -> 확인

1. 요구사항 도출

소프트웨어가 해결해야 할 문제를 이해하고, 고객으로부터 제시되는 추상적 요구에 대해 관련 정보를 식별하고 수집 방법 결정, 수집된 요구 사항을 구체적으로 표현하는 단계

도출 단계에서 이해관계자가 식별되고, 개발팀과 고객 사이의 관계가 형성되며 다양한 이해관계자와 효율적인 의사소통이 중요.

고객 분석, 조직 환경 분석, 후보 요구사항 분류, 후보 요구사항 정제, 요구사항 소스 관리.

인터뷰 / 브레인스토밍 / 델파이 기법 / 롤 플레잉 / 워크숍 / 설문 조사

2. 요구사항 분석

도출된 요구사항에 대해 충돌, 중복, 누락 등의 분석을 통해 완전성과 일관성을 확보하는 단계.

요구 사항들 간 상충되는 것을 해결하고, 소프트웨어의 범위를 파악하며 소프트웨어가 환경과 어떻게 상호 작용하는지 이해하는 단계

주요 활동으로는 시스템 요구사항을 정제하여 소프트웨어 요구사항 분류, 후보 요구사항 모델링, 요구사항의 우선순위 부여, 해당 릴리즈에 수행할 요구사항 선정, 요구사항 협의

비용과 일정에 대한 제약설정, 타당성 조사, 요구사항 정의 문서화 수행.

요구사항 분류 -> 개념 모델링 생성 및 분석 -> 요구사항 할당 -> 요구사항 협상 -> 정형 분석

[ 자료흐름 지향 분석 ]

데이터 흐름도 및 자료사전으로부터 소프트웨어 구조를 유도하는 방법

[ 객체 지향 분석 ]

시스템의 기능과 데이터를 함께 분석하여 UML로 표준화함

청취 / 인터뷰와 질문 / 분석 /중재 / 관찰 / 작성 / 조직 / 모델 작성

3. 요구사항 명세

체계적으로 검토, 평가, 승인될 수 있는 문서를 작성하는 단계

동의한 요구사항을 하나 이상의 형태로 저장하여 정형화된 요구사항을 생성하는 활동 수행.

주요 활동으로는 요구사항 명세 기준 정의, 요구사항 명세서 작성, 요구사항 추적 관련 정보 저장.

요구사항 명세서 산출

검증 항목 : 명확성 / 완전성 / 검증 가능성 / 일관성 / 수정 용이성 / 추적 가능성 / 개발 후 이용성

[ 비정형 명세 기법 ]

사용자의 요구를 표현할 때 자연어를 기반으로 서술.

사용자와 개발자의 이해가 용이.

명확성 및 검증에 문제.

[ 정형 명세 기법 ]

사용자의 요구를 표현할 때 수학적인 원리와 표기법으로 서술.

Z-스키마, Petri Nets, 상태차트 활용.

표현이 간결하고 명확성 및 검증이 용이.

기법의 이해가 어려움.

4. 요구사항 확인 및 검증

분석가가 요구사항을 이해했는지 확인하고 요구사항 문서가 회사의 표준에 적합하고 이해 가능하며, 일관성이 있고 완전한지 검증하는 단계.

요구사항 명세서 검토, 요구사항 용어 검증, 요구사항 베이스라인 수립.

이해관계자들이 요구사항 문서 검토 및 요구사항 관리 툴을 이용하여 요구사항 정의 문서들에 대한 형상 관리 수행.

리소스가 요구사항에 할당되기 전에 문제를 파악하기 위한 검증 수행.

요구사항 목록 확인 -> 요구사항 정의서 작성 여부 확인 -> 비기능적 요구사항의 확인 -> 타 시스템 연계 및 인터페이스 요구사항 확인

요구사항 검토 / 정형기술 검토 활용 / 프로토타이핑 활용 / 모델 검증 / 테스트 케이스 및 인수 테스트 / CASE 도구 활용 / 베이스라인 / 요구사항 추적표

[ 정형 기술 검토 ]

- 동료 검토 : 2-3명이 진행하는 리뷰 형태. 이해관계자들이 결함 발견. (= 인스펙션)

- 워크 스루 : 오류를 조기 검출하는 데 목적. 사전 검토 후 짧은 회의를 통해 리뷰하고 오류를 검출, 문서화함. 비형식적.

- 인스펙션 : 저작자 외의 다른 전문가 또는 팀이 검사하여 오류 발견하는 공식적 검토 방식. 형식적

- 감사 : 규제, 표준, 계획, 절차, 가이드라인을 준수하고 있는지 독립적으로 평가. 소프트웨어 제공자, 소비자, 제3기관 수행.

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

- 기술 리뷰 : 대표 엔지니어의 주재. 관리자 참가 가능. 정의된 계획 및 명세를 준수하고 있는지 검토 수행.

[ 상세 정형 기술 검토 ]

관리 리뷰 / 기술 리뷰 / 인스펙션 / 워크 스루 / 감사

[ 요구사항 정의서 ]

ID / 이름 / 유형 / 품질 속성 / 우선순위 / 중요도 / 출처 / 관련 부서 / 전제 조건 / 내용 / 관련 요구사항 / 버전 / 수용 여부

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

프로젝트 진행 과정에서 발생하는 요구사항의 변경에 대해 일치성과 무결성을 제공하기 위해 변경제어와 추적 등 일련의 관리를 수행하는 활동.

요구사항 변경요청서 / 요구사항 변경 승인서 / 요구사항 추적표 산출

협상 -> 기준선 설정 -> 변경관리 -> 확인 및 검증

형상통제 위원회(Configuration Control Board)

형상 관리에 대한 주요 방침을 정하고 산출물을 검토하며, 단계별 의사결정을 수행하는 조직.

분석 모델 검증 방법

1) 유스케이스 모델 검증

시스템 기능에 대한 유스케이스 모형 상세화 수준 및 적정성 검증을 위해 액터, 유스케이스, 유스케이스 명세서 점검.

* 액터 : 시스템의 외부에 있고, 시스템과 상호 작용을 하는 사람 또는 시스템.

* 유스케이스 : 시스템이 액터에게 제공해야 하는 기능으로 시스템 요구사항이자, 사용자 입장에서 바라본 시스템의 기능.

2) 개념 수준의 분석 클래스 검증

시스템의 주요 도메인 개념을 분석 클래스로 도출하여 유스케이스 분석에 활용하므로, 개념 수준의 주요 분석 클래스를 적절히 도출하였는지, 관련 정보가 명확한지 점검.

주요 클래스 도출 여부, 도출된 클래스 이름과 속성의 적절성, 올바른 클래스들 간의 관계 여부 점검.

3) 분석 클래스 검증

유스케이스 실현에 필요한 분석 클래스 도출 확인.

유스케이스 별로 도출된 분석 클래스들이 스테레오 타입으로 표시되었는지 확인.

경계와 제어 클래스의 도출 여부 및 상세화 정도 확인.

클래스 간의 관계, 클래스 정보의 상세화 정도 확인.

분석 모델 검증 프로세스

1) 검토의견 컬럼 추가

분석 모델까지 요구사항 추적표를 작성하고 검토의견 컬럼 추가

2) 검토의견 작성

요구사항 목록을 참조하여 요구사항 ID와 요구사항명 입력

유스케이스 모델에 대한 검토의견 작성

개념 수준의 분석 클래스 모델에 대한 검토의견 작성

분석 클래스 모델에 대한 검토의견 작성

3) 검토의견 정제

요구사항 추적표에서 요구사항에 대한 검토의견 정제

누락된 유스케이스 모델/개념 수준 분석 클래스/분석 클래스가 존재하는 경우, 검토의견 추가

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

1) 검토

- 성능 및 용량 산정의 적정성

요구사항을 만족시키기 위한 분석 모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원 식별.

- 시스템 간 상호 운용성

분석 모델을 이용해 보다 구체적으로 시스템 간 상호 정보 및 서비스가 교환 가능한지 검토

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

분석 모델이 과거의 문제를 해결하고 최근 많이 사용되는 트렌드에 부합되는지 확인

- 기술적 위험 분석

분석 모델이 시스템의 기술 구조, 프레임워크, 사용되는 HW/SW와 부합되는지 확인.

2) 프로세스

타탕성 분석 결과 기록 -> 타당성 분석 결과의 이해관계자 검증 -> 타당성 분석 결과 확인 및 배포/공유