[실기] 1. 요구사항 확인 (3) 요구사항 확인 & (4) 분석 모델 확인하기

1. 요구사항 확인
(3) 요구사항 확인

<< 기출 >>

기능적 요구사항 : 기능, 서비스
비기능적 : 기능 이외, 시스템 구축 제약사항.

 

---

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


기능적 요구사항 : 반드시 수행해야 하는 기능. 분석, 설계, 구현, 테스트 공정 거쳐 개발.
-부서별 담당자가 홈페이지 게시물을 작성할 수 있도록 관리자 페이지가 제공되어야 한다.
-콘텐츠 관리자가 예약정보를 입력하고 예약 현황을 파악할 수 있도록 다양한 통계와 관리 메뉴를 제공해야 한다.

비기능적 요구사항 : 기능 요구사항 제외한 것. 소프트웨어 개발 생산성에 영향 미치는 요인들.
-특정 함수의 호출시간은 5초를 넘지 말아야 한다.
-시스템 자원(CPU, 메모리 등)의 평균사용률은 최대 70%를 초과하지 않도록 구현해야 한다.

요구사항 도출 : 소프트웨어가 해결해야 할 문제를 이해, 고객이 제시되는 추상적 요구에 대해 관련 정보 식별, 수집 방법 결정, 수집된 요구사항 구체적으로 표현하는 단계.
=> 요구사항 개발 단계 : 도출 > 분석 > 명세 > 확인 & 검증

브레인스토밍 : 말 꺼내기 쉬운 분위기, 아이디어 비판 없이 수용하는 회의

비정형 명세 기법 : 요구사항 명세 단계에서 사용자 요구 표현할 때, '자연어' 기반 서술 기법.

요구사항 명세서(=요구사항 정의서) Requirement Specification
: 소프트웨어 개발 프로세스의 시작인 소프트웨어의 요구사항을 분석하고 정의 단계에서 작성되는 '최종 산출물'

인스펙션 Inspection : 소프트웨어 요구, 설계, 원시 코드 등의 저작자 외의 다른 전문가 or 팀이 검사하여 문제 식별, 문제에 대한 올바른 해결을 찾아내는 형식적인 검토 기법.

형상통제 위원회 Configuration Control Board
: 형상 관리 주요 방침 정하기, 산출물 검토, 단계별 의사결정 수행하는 조직.

---

요구사항 분류

기능적 요구사항 : 기능, 서비스에 대한 요구사항. 특정 입력 & 특정 상황. 기능적, 완전성, 일관성
-온라인 홈페이지에서는 쇼핑카트에 주문하고자 하는 품목을 저장할 수 있는 장바구니 기능을 제공해야 함
-상품의 결제수단은 신용카드, 무통장 입금, 포인트 결제가 가능해야 함

비기능적 요구사항 : 기능 이외의 사항, 시스템 구축 제약사항. 품질 속성, 제한 조건.
-특정 함수의 호출시간은 3초를 넘지 않아야 함.
-시스템은 하루 24시간 가동되어야 하며 가동률 99.5%를 만족해야 함
-시스템은 운영되는 중에 패치 및 업그레이드를 할 수 있어야 함.


요구사항 개발 프로세스 => 도/ 분/ 명/ 확 : 도출 > 분석 > 명세 > 확인

도출 Elicitation : 요구사항 소스, 도출 기법, 이해관계자(Stakeholder)식별, 효율적 의사소통 중요.
분석 Analysis : 요구사항 분류, 개념 모델링, 기술 구조 설계 및 요구사항 할당, 요구사항 협상, 완전성과 일관성 확보.
명세 Specification : 시스템 정의서, 시스템 요구사항 명세서, 소프트웨어 요구사항 명세서, 문서 작성, 정형화된 요구사항 생성
확인 Validation : 검토, 프로토타이핑, 모델 검증, 인수 테스트


요구사항 도출 단계 주요 기법

-인터뷰 Interview : 직접 대화. 공식적, 비공식적 정보 수집 방법.
-브레인스토밍 Brainstorming : 말 꺼내기 쉬운 분위기, 아이디어 비판없이 수용 회의
-델파이 기법 Delphi Method : 전문가 경험적 지식 → 문제 해결, 미래 예측
-롤 플레잉 Role Playing : 각자가 맡은 역 연기
-워크숍 Workshop : 단기간 집중적인 노력, 모든 핵심 인물의 참여 필요, 팀 협력, 사전 준비
-설문조사 Survey : 간접적 정보 수집, 사용자 다수일 때 의견 수렴 용이

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

-비정형 명세 기법 : 사용자 요구 표현할 때 '자연어' 기반. 사용자와 개발자 이해 용이. 명확성 및 검증 문제有
-정형 명세 기법 : 사용자 요구 표현할 때 '수학적인 원리와 표기법'으로 서술. 표현 간결, 명확성 및 검증 용이. 기법 이해 어려움.


요구사항 명세 원리 및 검증 항목 => 명/ 완/ 검/ 일/ 수/ 추/ 개

명확성 : 하나의 의미만 부여
완전성 : 모든 시스템 요구사항 포함
검증 가능성 : 충족 여부와 달성 정도에 대한 확인 가능
일관성 : 내용 간 모순x
수정 용이성 : 변경 시 쉽게 수정 가능
추적 가능성 : 근거에 대한 추적, 상호참조 가능
개발 후 이용성 : 개발 후 운영 & 유지보수에 효과적인 이용 가능


정형 기술 검토 활용 => 동/ 워/ 인

-동료 검토 Peer Review : 2~3명 진행하는 리뷰 형태. 요구사항 작성자가 요구사항 명세서 설명하고 이해관계자들이 설명 들으면서 결함 발견.
-워크 스루 Walk Through : 오류를 조기에 검출 목적. 검토 자료 회의 전에 배표해 짧은 시간 동안 회의 진행 → 리뷰 통해 오류 검출하고 문서화.
-인스펙션 Inspection : 저작자 외의 다른 전문가 or 팀이 검사하여 오류 찾아내는 공식적 검토 방법.


상세 정형 기술 검토 기법 => 관/ 기/ 인/ 워/ 감

-관리 리뷰 Management Review : 전반적인 검토 바탕.
-기술 리뷰 Technical Review : 정의된 계획 및 명세 준수하고 있는지 검토 수행. 대표 엔지니어 주재.
-인스펙션 Inspection (=동료 검토 Peer Review) : 다른 전문가 또는 팀이 검사. 형식적 검토 기법. 
-워크스루 Walk Through : 사전 검토하여 짧은 시간 동안 회의.
-감사 Audit : 독립적 평가. 소프트웨어 제품의 제공자, 소비자, 제3기관 수행.

---

(4) 분석 모델 확인하기

유스케이스 모델 검증 방법
: 유스케이스 모형 상세화 수준 및 적정성 검증 위해 액터, 유스케이스, 유스케이스 명세서를 점검.

분석 모델의 기술적 타당성 검토 항목
-성능 & 용량 산정의 적정성
-시스템 간 상호 운용성
-IT 시장 성숙도 & 트렌드 부합성
-기술적 위험 분석

성능 & 용량 산정의 적정성
-요구사항을 만족시키기 위한 분석 모델에 따라 시스템을 구현할 때 요구되는 시스템의 자원 식별
-분석 클래스에서 불필요하고 지나치게 많은 속성들을 포함시키면 객체 생성 시 시스템의 메모리 자원이 많이 요구되며, 전체 시스템의 성능 저하 발생.