3. 요구분석

728x90

1. 도메인 분석

도메인 분석은 소프트웨어 엔지니어가 개발하려는 분야의 배경 지식을 알아가는 과정이다.

• 소프트웨어 엔지니어가 문제를 더 잘 이해하기 위하여 도메인에 대하여 알아가는 과정

– 도메인이란 소프트웨어를 사용할 것으로 예상되는 고객이 일하는 분야의 비즈니스나 기술
– 도메인 전문가란 응용 분야에 깊이 있는 지식을 가진 사람

• 도메인 분석을 수행하는 이점

– 빠른 개발
– 더 좋은 시스템
– 확장을 예견

2. 문제정의와 범위설정

도메인에 대해 충분히 숙지했다면 드디어 요구를 결정할 수 있는데 이를 '요구 추출'이라고 한다. 이때 먼저 해결하려는 문제를 정의하고 프로젝트 범위를 결정한 후 여러 가지 방법을 활용하여 요구를 추출한다.

• 문제란?
– 고객이나 사용자가 직면한 어려움
– 생산성이나 매출을 높일 수 있는 기회

• 문제의 해결은 일반적으로 소프트웨어의 개발을 필요로 한다.
• 좋은 문제 정의는 짧고 간결

범위 설정

• 문제를 상세히 정의하여 범위를 축소
– 시스템이 할 수 있는 모든 일을 상상하여 리스트 작성

• 범위가 너무 넓으면 일부는 배제
• 범위가 너무 좁으면 상위 목표를 설정

3. 요구 추출

3.1) 요구의 정의

요구는 한마디로 제안된 시스템이 무엇을 하는가를 나타낸 문장으로, 이는 고객의 문제가 적절히 해결되도록 관련자들이 동의한 것이어야 한다. 요구의 특징은 다음과 같다.

– 짧고 간결한 정보
– 시스템이 무엇을 하는가를 나타냄
– 관련자 모두가 동의한 것
– 고객의 문제를 적절히 해결한 것

요구를 모아놓은 것이 요구 분석서

3.2) 요구의 유형

• 기능적 요구(functional requirements)

– 시스템이 무엇을 하여야 하는지, 즉 사용자나 다른 시스템을 위해 제공하는 서비스가 무엇인지 기술한 것
• 예) 현금 인출, 잔금 조회, 계좌 이체, 현금 서비스 등의 외형적 기능

1. 입력

2. 출력

3. 저장

4. 컴퓨팅

5. 타이밍과 동기화

• 비기능적 요구(nonfunctional requirements)

– 개발 과정에 고수하여 할 제약 조건
• 예) 하드웨어 자원의 제약, 소프트웨어 품질 특성에 대한 수준

1. 다음 사항을 반영하는 카테고리: 사용성, 효율성, 신뢰성, 유지보수성, 재사용성

• 반응시간
• 처리량
• 자원 사용량
• 신뢰도
• 가용성
• 고장에서의 회복
• 유지보수와 확장의 허용
• 재사용성의 허용

2. 시스템의 환경과 기술에 관한 카테고리

• 플랫폼
• 사용 기술

3. 프로젝트 계획과 개발 방법에 관한 카테고리

• 사용하는 개발 프로세스(방법론)
• 비용과 납기일
– 시스템 개발 계약서나 별도의 프로젝트 계획서에 표시

4. 요구 추출 방법

• 요구를 효과적으로 추출하고 분석하는 체계화된 기술

관찰

• 관찰 방법

– 문서를 읽고 사용자와 함께 요구에 대하여 논의한다

– 잠재적인 사용자들이 수행하는 복잡한 일을 관찰
• 사용자가 하는 일을 자세히 설명해 달라고 요구

– 비디오 촬영
• 예) 도매상에서 점원이 사려는 고객과 물건을 매매하는 과정

– 시간이 많이 소요

인터뷰

• 미리 잘 계획하여야 많은 정보를 얻을 수 있음

• 가능하면 많은 당사자와 인터뷰

• 관련자 이외의 다름 사람도 인터뷰
– 경쟁 제품의 사용자, 마케팅 담당자 등

• 여유 시간 할애

• 여러 번의 인터뷰 준비
– 구체적인 설명 요구

• 최대, 최소, 예외 규칙, 예상 되는 변동 등
– 관련자의 시스템에 대한 미래 비전

• 어떤 융통성을 가져야 하는지 제안될 수도 있음
– 다른 아이디어가 있는지 질문
– 최소한의 허용 가능한 솔루션이 무엇인지 질문
– 다른 정보원이 없는지 질의
– 다이어그램 작성을 요구

• 인터뷰 시 유의 사항

– 인터뷰하는 사람은 고객과 사용자에게 공감하고 잘 듣는 훈련이 되어 있어야 함
– 두 당사자가 상당히 다른 배경 지식을 가지고 있기 때문에 의사소통에 심각한 문제가 생길 수 있으므로 대화의 수준을 명확히 할 필요가 있음
– 인터뷰 초기 단계에서는 정보를 수집하는 것이지 분석이 이루지는 것은 아니므로 제시해 준 아이디어가 모두 구현되는 것은 아니라는 것을 말할 필요 있음
– 인터뷰에서 찾아낸 정보를 요약하고 이를 관련자들과 함께 나누면서 의견을 묻는 것임

브레인스토밍

• 아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의
• 훈련된 요원이 주재
• 토론보다는 아이디어를 쏟아놓는 회의, 익명성 보장
• JAD(Joint Application Development) – 집중 브레인스토밍 세션

브레인스토밍 과정

1. 관련자 모두가 참여하는 회의 소집
2. 경험 많은 사람을 회의 주재자로 선정
3. 테이블에 참석자를 배석시키고 종이 준비
4. 토론을 유도할 질문을 정함
5. 질문에 대하여 답을 종이에 적되 한 장에 하나의 아이디어만 적은 후 참석자에게 돌려 봄
6. 5번 단계를 5~15분간 반복
7. 간단한 설명
8. 모든 아이디어를 칠판에 적은 후 우선순위를 정하기 위하여 투표를 할 수도 있음

프로토타이핑

• 프로토타입
– 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램
• 가장 단순한 형태: paper prototype
– 무엇이 일어날지 설명한 그림을 순서대로 그린 것
– 병행하여 만들기 적합
• 가장 흔한 형태: 모의 사용자 인터페이스
– 프로토타이핑 언어로 작성
– 컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가능
– 시스템의 특별한 측면을 프로토타이핑 하기도 함
• 알고리즘, 데이터베이스 등

5. 사용사례 분석

• 개발한 소프트웨어를 가지고 사용자가 무엇을 할 수 있는지를 분석하는 체계적 방법

사용사례 분석 과정

1) 액터 찾기

-사용 사례 분석의 첫 단계는 개발할 시스템의 기능을 사용하는 시용자 클래스 또는 다른 시스템을 결정하는 일이다. 이러한 사용자 클래스나 외부 시스템을 액터라고 부르며, 각 액터는 시스템에 대해 각기 다른 작업을 필요로 하는 주체이다.

2) 사용 사례 찾기

사용사례 분석의 두 번째 단계는 각 액터가 시스템을 사용할 필요가 있는 작업을 결정하는 일이다. 이러한 작업을 사용 사례라 부르는데, 이는 시스템이 사용되는 특정한 유형을 나타내는 것이다. 다시 말해 시스템의 범위를 정하고 고객이 문제를 해결하기 위해 시스템을 사용할 때 액터가 사용할 사용 사례를 나열하는 작업이다.

3) 사용사례 다이어그램 그리기

사용 사례를 분석한 최종 결과는 다이어그램으로 그리고 각 사용 사례를 더 자세히 분할한다. 사용 사례 다이어그램은 액터와 사용 사례의 관계를 나타내기 위한 UML의 표현법으로, 시스템의 기능을 개략적으로 나타내어 개발자에게 도움을 준다.

사용사례 간 관계

액터가 시스템과 상호작용할 때 여러가지 이벤트가 발생할 수 있다. 또한 액터나 시스템이 특정 단계에 다르게 반응할 수 있다. 예를 들면 액터가 파일을 불러올 때 검색창을 여는 이벤트, 파일 이름을 입력하는 이벤트, 검색 버튼을 누르는 이벤트 등이 발생하는 것이다.

1) 확장 관계

선택적인 상호작용을 명시할 때 또는 예외적인 경우를 다룰 때 사용한다. 확장 관례는 예컨대 액터가 파일에 접근하기 위해 파일 이름을 잘못 입력했을 때 어떤 예외적인 사건이 일어나는지를 나타낸다.

• 선택적인 인터랙션을 명시적으로 나타낼 때 또는 예외적인 사례를 다룰 때 사용
• 사용사례 확장을 분리함으로써 기본적인 사용사례의 표현이 간단해 진다.
• 사용사례 확장도 사용사례의 처음부터 끝까지 모든 단계를 나열하여야 함
– 특수한 경우의 처리도 포함

2) 상세화 관계

클래스의 서브 클래스와 같은 의미로서 일반화된 사용 사례와 여러 유사 사용 사례의 관계를 나타낸다. 상세화된 사용 사례는 간략한 사용 사례에 대해 더 상세한 사건 흐름을 제공한다.

• 클래스 다이어그램에서 슈퍼 클래스와 유사
• 일반화된 사용사례는 여러 유사 사용사례를 표현
• 상세화 된 여러 사용사례가 유사 사용사례의 상세한 내용을 제공

3) 포함 관계

여러 사용 사례 사이에 공통적인 부분이 있을 때 이를 사용 사례의 일부로 분리하여 나타낼 수 있다. 즉 여러 사용 사례가 일련의 액션을 공유하는 것이다.

• 여러 사용사례들 사이에 공통적인 부분을 표현
• 다른 사용사례들 안에
– 일련의 액션을 공유
– 다수의 사용사례 사이에 중복을 피함
• 하위 수준의 작업의 수행을 하위 수준의 목표로 표현

사용사례의 장점

• 시스템의 범위를 정하는데 도움이 됨
• 개발 과정을 계획하는데도 사용됨
• 요구를 개발하고 검증하는데 사용 됨
• 테스트케이스를 정의하는데 기초가 됨
• 사용자 매뉴얼 구성하는데 사용될 수 있음

6. 요구 문서화

• 두 가지 극단적 형태
– 몇 문단의 글이나 다이어그램으로 요구의 아우트라인을 정의한 것
– 요구 정의(requirement definition)
– 수천 페이지의 복잡하고 자세한 명세 리스트
- 요구 명세서(requirement specification)
• 대규모 시스템을 위한 요구 문서는 계층적으로 정리

요구분석 상세 수준
• 얼마나 자세히 기술하여야 하는가는 다음 사항을 고려하여 결정
– 시스템의 크기
– 다른 시스템에 대한 인터페이스 요구
– 목표로 하는 독자
– 개발을 위한 계약
– 요구 취합 단계
– 도메인 및 기술에 대한 경험 수준
– 잘못된 요구에 대한 비용

요구 분석서의 내용

1. 문제

2. 배경 정보

3. 환경 및 시스템 모델

4. 기능적 요구

5. 비기능적 요구

7. 요구 검토

1. 개발 비용 대비 투자 효과

2. 문제의 우선 순위

3. 명확하고 일관성 있는 표현

4. 모호하지 않은 표현

5. 일관성

6. 품질 좋은 시스템의 유도

7. 실현 가능성

8. 검증 가능성

9. 식별할 이름

10. 설계 무제한성

11. 완전성
12. 조직화

13. 분명한 이유

14. 관련자의 동의

요구분석서의 변경관리

• 요구는 다음 이유로 계속 바뀜
– 비즈니스 프로세스의 변경
– 기술의 변경
– 문제 이해의 향상
• 요구분석은 중단될 수 없음
– 고객과 사용자와 계속 대화
– 변화의 이익은 비용을 초과
• 작은 변화는(UI) 적은 비용으로 빠르고 신속히 가능
• 대규모 변화는 신중하게 접근
– 예상하지 않은 변화를 부분적인 시스템으로 구축하면 설계가 부실해지고 완성이 늦어질 수 있음
– 어떤 변경은 겉만 향상
• 시스템의 규모를 키우는 것은 피하고 오직 더 좋은 시스템이 되도록 노력