Chapter #4: 요구 분석

요구 분석

SW 개발의 첫 단계

사용자 요구에 대하여 이해하고 정리하는 작업

두 가지 작업 - 현재의 상태를 파악하고 요구를 정의 / 명세서 작성

요구의 변경은 파급효과가 큼

 

요구 분석 과정

1. 요구 추출 - 기능적인 요구와 기능 이외의 조건 추출 (ex) 성능, 품질, 안전, 보안, 인터페이스

2. 도메인 분석 - 요구에 대한 정보를 수집, 배경 분석 (개체, 관계, 기능, 프로세스, 제약)

3. 모델링 - 도메인 분석을 통해 얻은 자료 개념화 (다이어그램)

4. 프로토타이핑과 시험 - 분석된 기능적 요구의 타당성 시험을 위한 프로토타입 생성

5. 문서화 검토 - 요구 분석서를 작성 (기능, 성능, 제약, 검증, 평가기준)

 

4.1 요구사항(Requirements)

시스템이 제공해야 할 역량

기능적 및 비기능적 요구사항

외형적으로 나타내는 기능, 성능

요구

기능적 요구(functional)

- 시스템과 외부 요소들 간 인터렉션

- 시스템이 어떤 상태일 때 외부의 데이터나 명령에 대해 어떤 반응을 하는지?

- 기능적 요구 항목으로 제기되는 문제들은 사용자의 문제를 해결하기 위한 구현 기술과는 독립적인 사항

 

기능적 요구와 사례 

- 기능 (시스템이 무엇을 하는가?)

- 자료 (입력, 출력이 무엇이며 어떤 형태?)

- 입출력 (데이터의 특정한 형태가 있는가?)

- 사용자 (누가 사용?)

 

비기능적 요구 

- 시스템 구축에 대한 성능, 보안, 품질, 안전, 사용성 등에 대한 요구 사항

 

종류

- 성능 요구, 품질 요구, 안전 요구, 보안 요구, 사용성 요구

 

요구 추출의 어려움

• 개발 팀이 응용 도메인에 대하여 충분히 알지 못함
• 고객과 사용자가 소프트웨어가 무엇을 하는지 또한 어떻게 요구를 표현할 지 모름
• 공통 배경지식 부족으로 개발 팀과 사용자 사이의 대화 장벽이 생김
• 소프트웨어 요구에 대한 명세와 구현이 분리될 수 없어 정확히 명시하기 어려움
• 요구 추출 작업을 관리자, 사용자, 개발자 모두 과소평가하는 경우가 많음
• 비기능적 요구를 파악하고 이해하지 못함
• 요구가 계속해서 변경됨

 

4.2 요구 추출 

추출 3가지 단계

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

2. 응용에 대한 정보 취합

3. 요구와 제한 사항의 정의

 

정보 수집 방법

~~~~~

우선 순위에 따른 요구 구별

절대적으로 필요한 요구, 요망되나 꼭 필요한 것은 아닌 요구, 제외될 수 있는 요구

요구 정보 출처

고객의 발표

개발팀이 구축하는 시스템에 대하여 초기에 개념을 잡을 수 있음

효과적인 가이드라인

문헌조사

유사한 프로젝트, 업무 문서/양식, 산업/기업 표준, 관련 정부 정책/규제 등을 조사

업무 절차 및 양식 조사

업무 관련 문서, 절차, 양식, 운영 메뉴얼 / 내부 표준 / 정부,산업, 기업의 특수 정책이나 규정 등을 조사

설문

관리자나 사용자와 같은 이해 당사자를 대상

이해 당사자들이 의사결정 과정에 포함

무기명 설문

인터뷰

가이드 라인 - 많은 당사자와, 여유롭게, 중요 관련자는 여러 차례 인터뷰

반드시 포함해야 할 질문 또는 행동 유형

- 최대, 최소, 예외 규칙, 예상되는 변동 등 자세한 사항

- 시스템에 대한 미래의 비전

- 문제에 대한 최소한의 허용 가능한 솔루션은 무엇인지

- 다른 정보원은 없는지

- 인터뷰 대상자에게 다이어그램을 작성하게 함

브레인스토밍

아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의

훈련된 요원이 주재

토론보단 아이디어를 쏟아놓는 회의, 익명성 보장

JAD(Joint Application Development) - 집중 브레인스토밍 세션

프로토타이핑(시제품)

프로토타입 - 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램

가장 단순한 형태 - 종이 프로토타입

가장 흔한 형태 - 모의 사용자 인터페이스

사용자 스토리 in 에자일 방법론

사용자와 개발 팀이 함께 작성

사용자들이 시스템에 바라는 역량을 간단히 기술한 것

내부 사람이 만들기 때문에 효과적

요구와 제한의 정의

수집한 정보에서 요구, 제한 사항 도출

요구 도출 과정 - (1) 사용자 니즈 파악 -> (2) 니즈로부터 요구 도출

 

4.3 도메인 분석

도메인이란? 요구사항의 배경

설계 모델링에 필요한 여러 개념과 비즈니스 룰을 파악

응용 분야에 존재하는 개념을 잘 정의, 분석 -> 시스템에 존재하는 개념으로 정립

도메인 정의

업무 작업 영역을 파악하고 범위를 규정

정보 시스템의 서브시스템 개념이 되는 프레임워크 제공

넓은 범위의 개념을 더 좁은 범위의 지식들로 체계화 하는 작업

도메인 분석

요구의 배경을 알아보는 것

도매인 배경 파악 3가지 단계

(1) 도메인 개념 찾기 - 도메인의 목적, 구조, 동작을 구성하는 객체, 프로세스, 사람, 룰 등

(2) 도메인 사전 작성

(3) 비즈니스 규칙 정리

도메인 개념

도메인 개념 발견을 위한 주의사항

- 요구의 핵심을 발견해야 함

- 요구가 해결될 것 같은 문제를 발견

- 문제를 구성하는 요소를 발견

- 관련된 도메인의 개념을 발견

도메인 사전

도메인 개념을 조직화한 결과물

간결한 정의

도메인 정의에서 표현된 문장, 어절, 제목에 초점을 두고 개념 추출

사전 양식 - 표로 구성, (명칭, 타입, 설명 3가지 항목 포함)

비즈니스 규칙

업무에서 지키기로 한 규정

기업이 운영되는 자세한 정책, 규정, 절차, 가이드라인, 표준의 집합

사용자에게 요구해도 준비된 전체 목록 받긴 어려움

비즈니스 규칙 종류 - 사실, 추론, 액션 구동자, 제약, 계산

 

4.4 사용 사례(use case) in OOM/UML

도메인 분석의 결과를 엑터(actor), 사용사례(use case), 관계(relation)들로 구성된 시스템 명세로 매핑하는 작업

 

사용 사례의 소개

시스템의 사용자에게 서비스를 제공하기 위한 상호작용의 단위

사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용하는 다이얼로그를 모델링

시스템 설계자/테스트 프로그래머들이 의사 교환하는데 유용

SW 개발자와 이해 당사자 간의 계약

사용사례 구축 시 주의 사항

- 시스템 내부 모델링이 X

- 비기능적 요구를 찾아내는 데 효과적 방법 X

- 시스템 흐름도 X

- 단계적 분할이 X

- 어떻게가 아니라 무엇을 시스템이 하는가?

 

사용 사례 다이어그램(use case diagram)

시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는데 사용

구성

- 사용 사례(use case) - 시스템 기능 

- 엑터(actor) - 시스템과 상호작용하는 것(사용자, 시스템)

- System boundary(범위)

- 관계

엑터와 사용사례

엑터 - 시스템과 상호작용하는 외부 엔티티 / 구별되는 이름과 설명이 필요

(역할에 따른) 엑터가 될 수 있는 것 - 사용자가 맡은 일(role) / 다른 시스템

사용사례 - 엑터의 입장에서 본 시스템의 동작(외부동작) / 엑터가 볼 수 있는 결과를 내는 이벤트의 집합, 다른 사용 사례 가동 가능

엑터 찾기

엑터를 찾기 위한 질문

어떤 사용자 그룹이 ~~

- 작업을 수행하기 위해 시스템의 지원을 받는가?

- 시스템의 주요기능을 사용하는가?

- 유지 보수와 관리 등의 부수적 기능을 사용하는가?

ex) 비디오 대여점의 엑터

사용 사례 찾기

여러 개별 시나리오를 묶는 것 - 정상적인 흐름, 오류나 예외 케이스

시나리오로부터 사용 사례 형성

ex) 사용 사례와 시나리오

시나리오 구성

개발자와 사용자가 함께 작성

현재의 응용 도메인에 대하여 기술한 여러 문서를 이용 (지침서, 절차 메뉴얼 등)

[필요한 질문]

 시스템이 어떤 작업을 수행하기를 액터가 원하는가 ?
 액터가 원하는 정보는 무엇인가?
 누가 데이터를 생성하는가? 데이터는 조작, 삭제될 수 있는가? 이런 작업이 누구에 의하여 행해지는가?
 액터가 시스템에 정보를 알리는데 필요한 것은 ? 얼마나 자주 또 언제 이런 작업이 일어나는가?
 액터가 시스템으로부터 정보를 알아내는데 필요한 이벤트는 ? 이런 사건의 빈도는?

[완성된 사용 사례(use case) 예]

사용 사례 관계 찾기

관계를 이용 -> 모형의 복잡도 줄이고, 이해도 높임

관계 종류 

포함(include) - 정상적인 이벤트, 예외적인 이벤트 분리

확장(extend) - 사용 사례 사이의 중복 제거

일반화(generalization)

포함 관계

사용 사례 사이의 중복을 제거

어떤 사용 사례가 다른 사용 사례를 포함하는 관계

공통된 동작을 뗴어넬 수 있음

포함 관계 예시

확장 관계

사용 사례가 일정한 조건 아래 확장된 동작을 포함한다면 다른 사용 사례를 확장하는 관계에 있음

ex) 사용자 정보 입력 중 미성년자를 위하여 부모 허락을 받는 사용 사례가 확장되는 경우

 

포함 / 확장 관계가 적용된 사용 사례 다이어그램

일반화

ATM 시스템 사용 사례 다이어그램 예시

 

4.5 요구 분석 명세서

시스템의 기능을 정확하고 완벽하며 일관성 있게 작성한 것

SW에 포함될 기능과 제약 조건들을 나열

기능에 대한 자세한 설명과 예외처리 기술

시스템 성능과 관련된 사항, 속도, 정확성, 사용 용이성 포함

과정 - 요구사항 명세서 작성 -> 명세서 검토

명세서 작성 - 사용자 & 개발자 간 이해를 돕기 위함

명세서 검토

요구 분석 명세서 평가 기준 - 무결성과 완벽성, 일관성, 명확성, 기능적, 검증 가능성, 추적 가능성 및 변경 용이성

 

4.6 요구 관리 도구

요구 변경 - 요구 추가, 기존 요구 삭제/변경

요구 관리: 요구 변경과 관련된 모든 이슈를 다루는 메커니즘

ex) 요구 관리 작업