요구 분석이란
- 소프트웨어 개발의 실질적인 첫 단계
- 사용자의 요구를 이해하고 정리하는 작업
- 3가지 작업
- 요구 추출
- 개발하려는 시스템에 대한 기대와 요구를 고객이나 사용자로부터 찾아낸다.
- 요구 분석 및 정의
- 찾아낸 시스템에 대한 요구를 이해 관계자와 합의할 수 있는 형태로 정의한다.
- 요구 확인
- 기술된 요구가 고객과 사용자를 만족시킬 것인지 확인하고 필요에 따라 수정한다.
- 요구 추출
- 페르소나
1 요구(Requirements)
요구의 정의
- 시스템에 대한 고객의 요청을 확정한 것
- “진정한 요구”를 찾는 일이 프로젝트 성공의 필수 조건
- 여러 이해당사자(stakeholder)의 이해관계와 관련
제약 사항(Constraints)
- 특정 언어/특정 제품 사용 등으로 해결책을 제한하는 조건
요구의 분류
- 기능 요구
- 비기능 요구
1.1 기능 요구(Functional Requirements)
- 시스템이 외형적으로 나타내는 기능/동작
- 현금 인출기 : 현금의 인출, 잔금 조회, 계좌 이체, 현금 서비스 ..
- 시스템과 외부 요소 간 인터랙션
- 입력을 받아 처리 후 결과 출력
- 보통 문장 형태: “시스템은 ~을 해야 한다”
- 동사로 표현 / 쉽게 파악 / 제품 기능 / 사용사례로 정리
기능 요구의 종류
기능 요구에 포함되어야 하는 사항
- 입력의 검증
- 정확한 작업 순서
- 비정상적인 상태(오버플로우, 네트워크 오류)에 대한 응답 및 복구
- 매개변수의 유효성
- 입출력 관계
1.2 비기능 요구(Non-functional Requirements)
- 요청된 기능 이외에 시스템이 갖춰야 할 조건/특징
- 예: 응답속도, 장애 복구 기간, 보안 등
- 형용사로 표현 / 파악이 어려움 / 제품 속성 / 품질 속성 시나리오로 정리
비기능 요구의 종류
- 외부 인터페이스
- 메모리 제약
- 성능 요구
- 사용자의 특성과 가정
- 설치 환경의 적합성
1.3 요구 대상에 의한 분류
- 비즈니스 요구
소프트웨어 적용 업무 사례로부터 획득하는 요구 사항 - 아키텍처 및 설계 요구
비즈니스 요구보다는 더 상세한 요구 사항으로 구현에 필요한 전체적인 설계와 관련된 요구 사항 - 시스템 및 통합 요구
개발자가 코딩하는 데 필요한 아주 상셍한 요구 사항이다.
2 요구 추출(Requirements Elicitation)
요구 추출 3단계
- 응용에 대한 정보 출처 파악
- 응용에 대한 정보 취합
- 요구와 제한 사항 정의
2.1 요구 정보 출처
- 고객
- 도메인 전문가(업무 도메인 지식 제공)
- 이해당사자(stakeholder)
- 사용자(직접 사용자)
- 역공학
- 레거시 시스템이나 현재 문서를 조사하고 분석
정보 수집 방법
- 고객의 발표
- 문헌/양식 조사
- 인터뷰
- 설문
- 브레인스토밍 회의(JAD 포함)
- 관찰과 작업 분석
- 프로토타이핑
2.2 고객의 발표(가이드라인 요지)
- 초기 시스템 개념 잡는 데 도움
- 운영 책임자/관리자 발표가 효과적
- 발표 전 “필요 정보 체크”
- 의심되는 부분은 질문으로 명확화
- 구현/기술 토론은 배제
- 자료 공유, 2시간 이상은 지양
2.3 문헌/양식 조사
- 유사 프로젝트 조사 → 통찰 제공
- 업무 문서/양식 조사 → 현재 업무/시스템 이해
- 산업·기업 표준, 정부 정책/규제 조사
2.4 인터뷰(가이드라인)
- 가능한 많은 당사자 인터뷰
- 일정은 여유롭게(시간 넘겨도)
- 중요 관련자는 여러 차례 인터뷰
→ “예/아니오”로 끝나는 질문은 지양하고, 자세한 응답이 나오도록 질문을 구성할것.
2.5 설문
- 관리자/사용자 등 이해당사자 대상
- 무기명 설문으로 숨겨진 정보/개선 의견 도출 용이
- 영향력 있는 사람의 선택에 다른 사람들도 영향을 받아 설문하여 자료가 오염되기 때문
- 질문은 간단하고 핵심 이슈 중심으로
2.6 브레인스토밍 / JAD
- 여러 명에게서 아이디어를 얻는 회의(익명성 보장)
- JAD = 집중 브레인스토밍 세션
2.7 프로토타이핑
- 최종 시스템 기능 일부를 빠르게 구현한 프로그램
- 가장 단순한 형태 : paper prototype
- 무엇이 일어날지 설명한 그림을 순서대로 그린 것
- 병행하여 만들기 적합
- 가장 흔한 형태 : 모의 사용자 인터페이스
- 프로토타이핑 언어로 작성
- 컴퓨팅/DB접근/다른 시스템 상호작용은 제한될 수 있음
- 특정 요소(알고리즘/DB 등)만 프로토타이핑 하기도 함
3 요구 분석(Requirements Analysis)
- 요구 후보를 분석해 요구로 확정하는 단계
3.1 요구 품질
좋은 요구(요구 품질)
- 원자적(atomic)
- 완전성(complete)
- 비모호성(unambiguous) + 통일성(consistent)
- 추적성(traceable)
- 우선순위화(prioritize)
- 테스트 가능성(testable)
3.2 도메인 분석(Domain Analysis)
- 도메인 = 요구의 배경(비즈니스 룰/개념 파악)
- 응용 분야 개념을 정의/분석하여 시스템 개념으로 정립
방법
- 도메인 개념 찾기
- 도메인 사전 작성
- 비즈니스 규칙 정리
3.3 시나리오 기반 분석
- 다양한 사람들이 참여해 용어/개념을 공유 → 커뮤니케이션 장벽 해소 필요
- 5H1W 기반
- 소프트웨어에 대한 시나리오를 언제, 어디서, 누가, 무슨 서비스를, 왜 제공하는지 기술
- 사용자 스토리 형태로도 표현
- <사용자/역할(who)>는 <목표/혜택/이익(why)>를 얻기 위하여 <행위/작업(what)>을 원한다.
4 유스케이스(Use Case)
- 도메인 분석과 모델링 사이의 관문
- 도메인 분석 결과를 액터/사용사례/관계로 구성된 시스템 명세로 매핑
유스케이스 요소
- 액터(Actor)
- 시스템 범위(System boundary)
- 유스케이스(Use case)
- 관계(Relationship)
유스케이스 분석 과정
- 액터 찾기
- 유스케이스 찾기
- 유스케이스 사이의 관계 찾기
4.1 유스케이스 다이어그램
- 시스템 기능을 표현하기 위해 요구를 추출/분석할 때 사용
- 구성: 유스케이스(시스템 기능), 액터(사용자/외부 시스템)
- 유스케이스 : 시스템 안에 존재
- 액터 : 시스템 범위 밖에 존재
액터(Actor)
- 시스템과 상호작용 하는 외부 엔티티
- 구별되는 이름/설명 필요
- 액터가 될 수 있는 것: 사용자 역할, 다른 시스템
액터 찾기 질문 예시
- 어떤 사용자 그룹이 작업을 위해 시스템 지원을 받는가?
- 주요 기능/부수 기능(유지보수/관리 등)을 누가 쓰는가?
- 다른 외부 HW/SW 시스템과 동작하는가?
유스케이스
- 여러 개별 시나리오를 묶은 것(정상 흐름 + 오류/예외 흐름)
- 개발자와 사용자가 함께 작성
- 지침서/절차 매뉴얼 등 도메인 문서 활용
유스케이스 도출 질문 예시
- 액터가 시스템이 수행하길 원하는 작업은?
- 액터가 원하는 정보는?
- 누가 데이터를 생성/조작/삭제하는가?
- 액터가 시스템에 알릴 정보/빈도/시점은?
- 액터가 시스템에서 정보를 얻기 위한 이벤트/빈도는?
4.2 유스케이스 명세(Use Case Specification)
- 시스템 제목
- 유스케이스 이름
- 액터
- 시작 조건(Precondition)
- 기본 흐름(Main flow)
- 대안 흐름(Alternative flow)
- 종료 조건(Postcondition)
4.3 유스케이스 관계
- 관계를 이용해 복잡도 ↓, 이해도 ↑
- 대안 흐름: 기본 흐름의 변형/선택/예외
- 포함(include): 공통 동작을 떼어내 재사용
- 확장(extend): 특정 조건일 때 기본 유스케이스에 삽입되는 확장 동작
포함 관계
- 유스케이스 사이의 중복을 제거함
- 어떤 유스케이스가 다른 유스케이스를 포함하는 관계
- 공통된 동작을 떼어 낼 수 있다.
- ATM에서 예금과 출금이라는 유스케이스에 공통적으로 사용자를 인증하는 이벤트들이 포함되어 있다면
- ATM에서 예금과 출금이라는 유스케이스에 공통적으로 사용자를 인증하는 이벤트들이 포함되어 있다면
확장 관계
- 유스케이스가 일정한 조건 아래 확장된 동작을 포함한다면 다른 유스케이스를 확장하는 관계에 있다.
- 결제 과정에서 멤버십이면 “멤버십 할인”이 삽입
- 기본 유스케이스인 ‘결제’는 자체로 완전한 유스케이스
- 멤버쉽에 가입되었다는 조건에 만족하면 ‘멤버쉽 할인’ 유스케이스가 삽입
유스케이스: 시스템과 사용자 사이의 상호작용을 사건 중심으로 기술한 것
사용자스토리: 대상 시스템이 제공하는 서비스나 기능을 한 문장으로 명시한 것
5 요구 명세(Requirements Specification)
IEEE 830 기반 구성(요지)
- 개요
- 시스템 목적 / 범위 / 정의·약어 / 참조
- 기능적 요구
- 외부 인터페이스 요구(사용자/하드웨어/소프트웨어·통신)
- 기능 요구(기능 #1, 기능 #2 … / 사용사례 기반으로 정리)
- 기타 요구 및 제약 사항
- 성능 요구(반응시간/처리시간/처리율)
- H/W 요구(기억장치 규모/통신 수용도 등)
- 예외 조건 및 처리
- 자원/인력 제약 등
- 인수 조건(수용 테스트 관점)
5.1 작성 방법
- 사용자/개발자 모두 쉽게 이해할 수 있게
- 문서에 기술된 조건은 사용자·개발자가 동의한 것
- 목표 시스템이 수행할 기능을 정확히 기술
- 시스템에 영향을 주는 모든 제약 조건 기술
- 시스템 인수를 위한 테스트 기준 제공
- 원하는 시스템의 품질과 중요도, 품질 측정 방법 기술
6 요구 검증(Requirements Validation)
사용자 요구가 요구 분석 명세서에 올바르게 기술되었는지 검토하는 활동
- 이해용이성(Comprehensibility): 요구 의미를 잘 이해할 수 있는가?
- 중복(Redundancy): 불필요한 중복이 없는가?
- 완전성(Completeness): 빠진 요구/빠진 정보가 없는가?
- 일관성(Consistency): 요구사항이 서로 모순되지 않는가?
- 모호성(Ambiguity): 모호함 없이 명확하게 이해되는가?
- 검증 가능성(Verifiable): 사용자의 요구를 만족하는지/분석 내용과 일치하는지 검증할 수 있는가?
- 추적 가능성(Traceable): 요구가 설계/구현과 매핑되어 추적 가능한가?
비니비니히비니의 정리블로그