[소공] 4장 요구 분석

0. 요구 분석 작업 단계(3)

  - 요구 추출: 고객의 요구를 찾아냄.(인터뷰, 설문)

  - 요구 분석 및 정의: 찾은 요구를 이해관계자와 합의할 수 있는 형태로 정의.

  - 요구 확인: 요구가 고객을 만족시키는지 확인하고 수정(프로토타입핑)

4-1 요구

1. 요구란?

: 시스템에 대한 고객의 요청을 확정한 것.

  → 진정한 요구를 찾는 일: 프로젝트 성공의 필수 조건!

2. 제약 사항이란?

: 시스템의 해결책 제한함. (특정한 프로그래밍 언어와 특정한 제품 사용 금지)

  → 요구와 차이점: 제약은 여러 가지 설계 구현 안을 줄임.

3. 요구의 분류(2)

  - 기능 요구: 고객이 요구하는 시스템이 처리할 기능(업무 절차나 기계 동작을 실현한 것.)

      → 특징: 동사로 표현/ 쉽게 파악/ 제품 기능/ 사용 사례로 정리

      → 종류(5): 입력의 검증/  정확한 작업순서/  비정상적인 상태에 대한 응답 및 복구/ 매개 변수의 유효성/  입출력 관계

  - 비기능 요구: 요청된 기능 외에 시스템이 갖추어야 할 조건(응답 속도, 보안 등)

      → 특징: 형용사로 표현/ 파악 어려움/ 제품 속성/ 품질 속성 시나리오로 정리

4. 요구 대상에 의한 분류(3)

  - 비즈니스에 대한 요구: 업무 사례로부터 획득하는 요구

  - 아키텍쳐 설계에 대한 요구: 더 상세한 요구사항으로 구현에 필요한 전체 설계와 관련된 요구

  - 시스템 통합에 대한 요구: 코딩하는데 필요한 상세한 요구

 

4-2 요구 추출

1. 요구추출 단계(3)

  (1) 응용에 대한 정보 출처 파악

         → 고객: 프로젝트를 유치하고, 재정 지원(프로젝트에 돈을 후원하는 회사)

        → 도메인 전문가: 비즈니스 도메인을 지원하는 시스템 구축에 필요한 사람(회계시스템 구축: 회계사)

        → 이해당사자: 시스템 운용으로 영향을 받는 사람

        → 사용자: 시스템을 직접 사용하는 사람

        → 역공학: 래거시 시스템 참조(옛날 시스템)

  (2) 응용에 대한 정보 취합

  (3) 취합된 정보를 분석하여 요구와 제한 사항 정의

2. 정보 수집 방법(7)

  - 고객의 발표: 좋은 방법. 개발팀이 초기에 개념을 잡을 수 있음.

  -  문헌, 양식 조사: 유사한 플젝 조사, 산업 표준 조사, 관련 정책 조사, 문서나 양식 조사.

  -  인터뷰

  -  설문

  -  브레인스토밍 회의: 아이디어를 낼 목적으로 회의. 익명성 보장, 다른 사람에게 자극 받아 아이디어 많이 내려 노력

  -  관찰과 작업 분석

  -  프로토타이핑: paper prototype(가장 단순), 모의 사용자 인터페이스(가장 흔함)

4-3 요구 분석

1. 요구 품질 분석(7)

• 원자적(단일 목적을 가짐)
• 완전성(모든 정보를 포함)
• 비모호성, 통일성
• 추적성(추적 가능하게 고유번호를 가짐)
• 우선순위화(중요도를 정할 수 있음)
• 테스트 가능성(검증 가능하도록 기술)

2. 도메인 분석

  - 도메인: 요구의 배경 

  - 방법(3):

• step1) 도메인 개념 찾기: 도메인의 목적, 구조, 객체, 프로세스, 사람, 규칙 찾기
• step2) 도메인 사전 작성: 도메인 개념에 대한 정의 작성. 요구, 인터뷰 등 활용.
• step3) 비즈니스 규칙 정리: 업무에서 지켜야하는 규정, 정책 정하기.

3. 시나리오 기반 분석

: 시나리오 기반 -> 5W1H 사용! (who, what, where, why, when, how)

• 사용자 스토리: <사용자(who)>는 <햬택(why)>을 얻기 위하여 <작업(what)>을 원한다.

user story

4-4 유스케이스

1. 유즈케이스

: 도메인 분석과 모델링 사이의 작업. 

2. 유즈케이스 요소(4)

: 액터,  시스템 범위,  유즈케이스,  관계

3. 유즈케이스 다이어그램(2)

: 사용자 요구를 추출, 분석하는데 사용.

• usecase: 시스템 기능
• actor: 시스템과 상호작용 하는 외부 엔티티. 사용자가 맡은 일, 다른 시스템이 대상.(사용자, 시스템)

4. 유즈케이스 분석과정(3)

  step1) 액터 찾기: 액터를 찾기 위한 질문(4)

          - 누가 지원을 받는가?

          -  누가 주요 기능을 사용하는가?

          -  누가 부수적 기능(유지 보수 등)을 사용하는가?

          - 시스템이 다른 외부 시스템과 동작하는가? 

  step2) 유즈케이스 찾기: 여러 개별 시나리오를 묶은 것. 유즈케이스를 찾기 위한 질문(5)

  step3) 유즈케이스 사이의 관계 찾기: 관계를 이용해 복잡도를 줄이고, 이해도를 높인다. 관계 종류(3)

          - 포함 관계: 다른 유즈케이스에서 재사용할 수 있도록 캡슐화. 중복을 제거.

예금, 현금 인출할 떄 고객인증 필요

          - 확장 관계: 기본 유즈케이스의 이벤트 흐름이 특정 조건에 만족되었을 때 분리 확장된 것.

결제할 때 멤버십 있으면 할인

          - 대안 흐름: 기본 유즈케이스에서 이벤트 흐름이 약간 변형되거나 선택, 예외인 경우

 

 

5. 유즈케이스 명세

: 시스템이 제공해야 할 서비스를 시간 순서로 기술한 것.

6. 사용자 스토리 vs 유즈케이스

: 둘 다 소통 도구임.

• 사용자 스토리: 시스템이 제공하는 기능을 한 문장으로 명시
• 유즈케이스: 시스템과 사용자 사이의 상호작용을 사건 중심으로 기술

4-5 요구 명세

1. 요구 명세(SRS)

: Software Requirement Specification

2. 요구 분석서 작성 시 주의 사항(6)

• 사용자, 개발자 모두 이해할 수 있도록.
• 사용자, 개발자 모두 동의한 내용.
• 기능들을 정확히 기술
• 목표하는 시스템에 영향을 주는 제약 조건 모두 기술.
• 테스트 기준 제공.
• 품질 측정방법이 기술.

4-6 요구 검증

1. 요구 검증 사항(7)

: 이해용이성, 중복, 완전성, 일관성, 모호성, 검증 가능성, 추적 가능성