요구 사항이 없는 시스템 개발 설계는 어떻게

포인트1. 소프트웨어 요구란 무엇인가?

포인트2. 사용자의 요구를 추출하는 방법은 무엇인가?

포인트3. 요구를 분석하고 정의하는 방법은 무엇인가?

포인트4. 유스케이스란 무엇이며 어떻게 찾아내는가?

포인트5. 소프트웨어 요구 명세서를 작성하는 방법은 무엇인가?

요구분석

소프트웨어 개발의 실질적인 첫 단계

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

분석작업

1. 요구 추출

• 개발하려고 하는 시스템에 대한 기대와 요구를 고객, 사용자로부터 찾아냄

2. 요구 분석 및 정의

• 찾아낸 시스템에 대한 요구를 이해 관계자와 합의할 수 있는 형태로 정의함

3. 요구 확인

• 기술된 요구가 고객과 사용자를 만족시킬 것인지 확인하고 필요에 따라 수정함

4-1. 요구

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

진정한 요구를 찾는 것은 프로젝트 성공의 필수 조건이지만 진정한 요구를 찾아내기에는 제약사항들이 존재

제약사항들

• 고객이 특정한 프로그래밍 언어로 개발할 것을 요구
• 특정한 제품을 사용하는 것을 금지할 것을 요구(정치적, 사업적 고려)

제약사항은 소프트웨어 시스템의 해결책을 제한한다.

제약은 여러 가지 설계 구현안을 줄인다는 점

요구와 제약은 요구 분석 명세서에 우선순위 표시와 함께 잘 정리되어야 함

요구의 분류

용어에 대한 이해를 중심으로 공부하면 된다.

4-1-1. 기능요구

시스템이 외형적으로 나타내는 기능과 동작

예를 들어 현금인출기에서의 기능 요구는 현금의 인출, 잔금 조회, 계좌 이체 같은 것들이 된다.

시스템이 데이터나 인스트럭션에 대해 반응하는 동작, 상태의 변화도 기능요구이다.

시스템은 _______을/를 해야 한다.

기능요구에 포함되어야 하는 사항들

• 입력의 검증
• 정확한 작업 순서
• 비정상적인 상태(오버플로우, 네트워크 오류)에 대한 응답 및 복구
• 매개변수의 유효성
• 입출력 관계

기능요구는 외부 사용자에게 직접적으로 혜택을 줄 수 있는 시스템의 기능을 말함

4-1-2. 비기능 요구

시스템이 제공하는 기능에 직접 관련되지 않은 요구

기능요구를 지원하기 위하여 파생적으로 필요한 요구이다.

비기능 요구의 종류

• 외부 인터페이스
• 메모리 제약
• 성능 요구 - 처리량, 반응 속도, 실시간 처리, 자원 이용률 등..
• 사용자의 특성과 가정
• 설치 환경의 적합성

4-1-3. 요구 대상에 의한 분류

요구하는 대상에 따른 요구 분류

• 비즈니스 요구 - 소프트웨어 적용 업무 사례로부터 획득하는 요구사항
• 아키텍처 및 설계 요구 - 비즈니스 요구보다 더 상세한 요구사항, 구현에 필요한 전체적인 설계 및 관련 요구사항
• 시스템 및 통합 요구 - 개발자가 코딩하는 데 필요한 아주 상세한 요구사항

4-2. 요구 추출

사용자가 무엇을 원하는지 결정을 내리는 작업, 여러가지 기법이 동원

요구 추출을 위한 세 단계의 작업

• 요구에 대한 정보 출처 파악
• 요구에 대한 정보 취합
• 요구와 제한 사항 정리

요구추출 방법

• 고객의 발표
• 문헌, 양식 조사
• 인터뷰
• 설문
• 브레인스토밍 회의
• 관찰과 작업 분석
• 프로토타이핑

4-2-1. 요구정보 출처

요구 추출 작업은 정보의 수집이 필요함 -> 어디서 정보를 얻느냐?(출처)를 알아야 함

정보 출처 유형

- 고객

• 프로젝트 유치, 재정적 지원, 운명을 결정하는 당사자
• 소수이지만 재정적인 지원을 맡으며, 중요한 의사결정을 함 -> 프로젝트에 상당한 영향력을 행사함

- 도메인 전문가

• 비즈니스 도메인을 지원하는 시스템을 구축하기 위해 필요한 사람
• 예를 들어 회계 시스템 구축을 위해 회계사가 필요함

- 이해 당사자

• 시스템 운용으로 인하여 영향받는 사람들
• 시스템의 사용자가 될 수도 있고 아닐 수도 있다
• 주된 관심은 비즈니스 목표, 규칙등에 부합하는 가를 확인하는 것

- 사용자

• 시스템을 직접 사용하는 사람들
• 주 사용자 - 업무 프로세스에 참여하여 무엇을 하는지 뿐만 아니라 왜 해야 하는지도 안다
• 단순 운영자 - 주 사용자를 보조, 반복 업무만 수행 가능

- 역공학

• 레거시 시스템(낡은 기술, 방법론) 이랑 현재 문서는 업무 규칙에 대한 풍부한 출처가 될 수 있음
• 이러한 어플리케이션, 문서, 규정등을 파헤치는 것

요구 추출 뷰 포인트

요구를 추출할 때 기준이 되는 관점

개발자는 시스템에 대한 다양한 관점을 인식하여 다양한 요구사항들을 받아 냄

-> 요구사항에 모순이 있을 때 발견하기 쉬운 틀이 제공되기 때문

- 상호작용 관점(Interaction Viewpoint)

• 대상 시스템을 직접 조작하는 사람이나 직접 정보를 교환하는 시스템의 관점
• 시스템의 기능과 인터페이스를 결정하는 구체적인 요구를 제시
• 예시 : 현금자동인출기(ATM)에서 ATM을 사용하는 고객, 계정을 관리하는 DB의 관점

- 간접 관점(Indirect Viewpoint)

• 대상 시스템을 직접 조작하는 것은 아니지만, 어떤 상태로든 영향을 미치는 이해 관계자의 관점
• 비교적 높은 조직의 요구와 제약을 규정(추상적인 요구)
• 예시 : ATM의 경우 관리부서의 직원, 보안요원

- 도메인 관점(Domain Viewpoint)

• 대상 시스템의 요구사항에 영향을 미치는 응용 영역의 특징과 제약사항
• 대상 시스템의 범위를 선정하는 데 도움을 줌
• 이미 설치된 다른 시스템과 연동함, 개발할 때 다른 시스템과의 연계를 계획해야 함
• 예시 : ATM의 경우 은행 사이 상호작용이 가능하게 한 통신 표준기술

4-2-2. 고객의 발표

고객의 업무를 개발팀에게 소개시키고 의심되는 것을 명확히 할 수 있으며, 개발팀이 구축하는 시스템에 대하여 초기에 개념을 잡을 수 있음

효과적인 가이드라인

• 업무 및 고객과 사용자가 원하는 것을 잘 알고 있어야 함 - 운영 책임자나 관리자가 발표하는 것이 적절
• 고객 또는 대표 발표자에게 무엇을 다루어야 하는지 알게 해야 한다. 필요시 정보를 얻을 수 있는 제 3자 요구 가능
• 발표하기 전에 개발 팀원이 필요한 정보가 있는지 검토
• 발표하는 동안 명확하지 않은 부분에 질문을 하고, 구현과 관련된 토의는 배제한다 - 무엇을 원하는가만!
• 발표 내용의 복사본을 요청, 팀원과 공유
• 2시간 이상의 긴 발표는 지양할 것

4-2-3. 문헌 양식 조사

유사한 프로젝트를 조사

• 개발 할 시스템에 대한 통찰 제공

업무 문서나 양식을 조사

• 현재의 업무나 시스템 정보에 대해 깊은 이해 가능

산업 및 기업의 표준 조사

• 요구와 제한사항을 찾는 데 도움이 됨

관련 정부의 정책/규제 조사

• 해결책에 대해 제한함 -> 제한점이 시스템 요구 분석서의 제한사항이 됨

4-2-4. 인터뷰

질문지를 만들어 직접 사용자나 고객을 만나 요구사항을 들어보는 것

인터뷰 형식

- 정형적 인터뷰

• 사전에 질문 항목 설정 및 조사표 준비
• 답변 결과 분류 취합, 계량화 -> 통계처리가 가능
• 문항 범위를 넘어서는 답변을 듣기 어려움

- 비정형 인터뷰

• 주제만 정한 뒤, 자유롭게 대화하며 응답자의 생각을 이끌어 가는 방법
• 진행 중, 임기응변으로 문항을 바꾸어 풍부한 정보를 알아낼 수 있음

- 부분 정형 인터뷰

• 정형적 + 비정형 인터뷰
• 사전에 준비한 조사표 + 필요시 추가 질문
• 일반적으로 많이 이용함

인터뷰 절차

• 가능하면 많은 당사자와 인터뷰를 한다
• 인터뷰 일정은 여유롭게 잡는게 좋다
• 약속 시간을 넘기더라도 여유롭게 진행한다
• 중요한 관련자와는 여러 번 인터뷰를 진행한다

효과적인 인터뷰 원리

1. 인터뷰를 준비하라 - 주제 영역에 대해 미리 공부하고, 알고 있을 것 같은 정보들을 예측한다
2. 다수를 함께 인터뷰하지 말 것
3. 개방형 질문을 하라
4. 후속 질문을 한다 - 추가 질문을 하여 감추어진 데이터를 이끌어내라
5. 대답을 듣고 분석하라 - 대답한 내용의 의미에 대해 깊이 조사하며, 이해할 수 있도록 명확한 답변을 요구할 것

미숙한 질문의 원인

• 용어이해 부족 - 해당 전문 분야의 용어에 대한 이해가 부족하면 요구 설명이 힘듦
• 대상 분야의 특수 지식 - 특수지식을 설명하기 어려운 경우

4-2-5. 설문

관리자나 사용자 같은 이해 대상자를 대상으로 한다

무기명 설문

• 이해 당사자들의 관심과 내부정보, 개선의견 도출
• 감추어진 정보를 끌어내기 쉬움 -> 새로운 시스템을 위한 요구를 만드는 데 쓰임

설문지 사용에서 유의할 점

• 질문은 간단하고, 중요한 이슈에 집중해야 함
• 이해 당사자 그룹별로 다른 설문지를 준비한다
• 질문이 적절하고 잘 기술되었는가 확인한다

4-2-6. 브레인스토밍

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

훈련된 요원이 주재

장점

• 그룹에 있는 참석자가 다른 사람의 아이디어에 자극을 받아 아이디어 창안을 적극적으로 하게 됨
• 익명성이 보장되어 내성적인 사람들도 효과적으로 이야기 할 수 있음

JAD(Joint Application Development)

• 개발자는 고객과 사용자를 격리된 장소에서 사나흘동안 만남
• 요구를 정의하기 위한 공동작업에 시간 할애
• 최종 결과는 요구 문서로 작성됨

4-2-7. 프로토타이핑

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

목적

• 소프트웨어 엔지니어의 아이디어에 대한 피드백을 조기에 받아 요구사항 취합을 하기 위함
• 현재 발굴된 아이디어를 시험, 검증하며 새로운 아이디어를 창출하기 위함

Papaer ProtoType

• 가장 단순한 형태의 프로토타입
• 고객과 사용자에게 보이는 화면을 순서대로 그린 것
• 아이디어 추출 및 피드백 수집에 적합, 적은 노력으로 제작 가능
• 여러 개를 병행하여 제작하기 적합

모의 사용자 인터페이스

• 프로토타이핑 전용 언어(rapid prototyping language)로 작성한다
• UI의 중요한 부분을 디스플레이 하기 위해 신속하게 작성
• 프로토타이핑을 어느 정도는 실제와 같이 사용 가능
• 그러나 UI 배후에 있는 사항(컴퓨팅, DB접근, 다른 시스템과의 상호작용)은 불가능
• 알고리즘이나 DB를 프로토타이핑 하기 위해서도 사용됨

4-3. 요구 분석

요구 후보를 분석하고 결정하여 요구로 확정하는 단계

4-3-1. 요구 품질

요구사항이 다음과 같은 성질을 가지는 지 분석해야 함

• 원자적(atomic) - 요구사항이 단일 목적을 가지는 성질
• 완전성(complete) - 요구사항 속에 정의된 것이 정보의 모든 것을 포함
• 비모호성(unambiguous), 통일성(consistent) - 명확하지 않는 것을 기술, 같은 내용을 다르게 언급하지 않는 성질
• 추적성(traceable) - 요구사항을 쉽게 추적할 수 있도록 고유번호를 부여
• 우선순위화(prioritize) - 요구사항의 중요도를 파악할 수 있는 성질
• 테스트 가능성(testable) - 요구사항이 검증 가능하도록 기술되어 있는 특성

각 성질들의 예시를 적어놓은 표이다. ( 출처 - 소프트웨어 공학의 모든 것 156page )

4-3-2. 도메인 분석

도메인 - 요구의 배경을 의미

도메인 분석 - 응용분야(현실)에 존재하는 개념을 잘 정의하고 분석하여 시스템에 존재하는 개념으로 정립하는 단계

왜 분석하는가?

• 설계 모델링에 필요한 여러 개념과 비즈니스 규칙을 파악하기 위함

도메인 분석 방법

- 도메인 개념 찾기

• 도메인 개념 - 도메인의 목적, 구조, 동작을 구성하는 객체, 프로세스, 사람, 규칙과 같은 것들
• 프로젝트 초기에 개념을 세우기 위해 용어를 바르게 정의하는 것이 중요함

- 도메인 사전 작성

• 도메인 사전 - 시스템과 관련된 도메인 개념을 조직화 한 것
• 사전의 각 항목 - 용어가 사용 될 때는 언제든 같은 의미로 통하게 하는 간결한 정의

- 비즈니스 규칙 정리

• 비즈니스 규칙 - 업무에서 지키기로 정한 규정

4-3-3. 시나리오 기반 분석

다양한 사람들이 참여하여 다양한 용어와 개념을 전달하여 요구를 도출함

5W1H 원칙 (육하원칙) 사용

사용자 스토리

• 애자일 방법에서 요구 파악에 많이 사용하는 방법
• 대상 시스템이 제공해야 할 기능 하나를 일정한 형식의 한 문장으로 정의하는 것

< 사용자/역할 (who) >는
< 목표/혜택/이익 (why) >를 얻기 위하여
< 행위/작업 (what) >을 원한다.

위와 같은 형식에 맞추어 사용자 스토리를 작성한다.

예시

< 고객 >은
< 현찰을 받기 >위하여
< ATM기에서 현금을 인출하기 >를 원한다

4-4. 유스케이스

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

= 유스케이스 모델링 : 시스템의 동작을 모형화 하는 것

유스케이스 - 네 가지 요소들(액터, 시스템 범위, 유스케이스, 관계)이 결합된 것

유스케이스 분석 작업

• 액터 찾기
• 유스케이스 찾기
• 유스케이스 사이의 관계 찾기

분석 작업의 결과 - 유스케이스 다이어그램, 유스케이스 명세

4-4-1. 유스케이스 다이어그램

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

외부에서 보는 시스템의 동작에 초점을 맞춤

유스케이스, 액터로 구성

액터 (actor)

• 시스템과 작용하는 외부 엔티티
• 사람이 될 수도 있고, 외부 시스템이 될 수도 있다
• 액터는 역할을 추상화한 것 - 무조건 사람과 결부시킬 필요는 없음
• 대상 시스템에게 서비스를 제공하거나 제공 받는다

액터를 찾고싶어요

• 어떤 사용자들이 작업을 수행하기 위해 시스템의 지원을 받는가?
• 어떤 사용자들이 시스템의 주요 기능을 사용하는가?
• 어떤 사용자 그룹이 유지 보수와 관리 등의 부수적 기능을 사용하는가?
• 시스템이 어떤 외부 하드웨어나 소프트웨어 시스템과 동작하는가?

유스케이스(use case)

• 시스템의 단위 기능
• 각 유스케이스는 특정 이벤트 흐름을 나타냄
• 유스케이스에 대한 설명 - 유스케이스가 수행될 때 시스템에서 발생하는 상황

유스케이스를 찾고싶어요

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

4-4-2. 유스케이스 명세

대상 시스템이 제공해야 할 서비스를 시간이 경과되는 순서로 정렬하여 기술한 것

요구분석에 사용되는 시나리오에 포함될 정보

• 시나리오가 시작될 때 외부 시스템이나 사용자가 기대하는 것
• 시나리오에서 일어나는 사건에 대한 기본 흐름
• 문제가 발생되는 비정상적인 사건에 대한 대안 흐름
• 동시에 병행으로 일어나는 다른 활동에 관한 정보
• 시나리오가 종료되었을 때 시스템의 상태에 대한 정보

이벤트 흐름

외부에서 보이는 시스템의 기능을 나타낸 것

이벤트 흐름 가이드라인

• 유스케이스의 시작과 종료 조건을 설명한다
• 액터와 유스케이스 간에 교환되는 데이터를 설명한다
• 시스템의 동작을 이해하기 위해 꼭 필요한 경우가 아니라면 UI 세부사항을 설명하지 않는다
• 너무 상세한 내용은 설계에서 결정할 사항이기 때문에 언급을 지양한다
• 기능 뿐 아니라 이벤트 흐름을 설명해야 한다 ( 액터가 _____ 할 때 로 시작한다 )
• 유스케이스에 속하는 이벤트만 설명하고 다른 유스케이스 또는 시스템 외부에서 어떤 일이 발생하였는지는 기술하지 않는다
• "예를 들면", "등", "정보" 와 같은 모호한 용어는 피한다
• 이벤트 흐름에 대한 자세한 내용은 시스템의 "What"에 대한 답변이어야 함 (테스트 엔지니어는 이벤트 흐름의 내용으로 테스트 케이스를 식별하기 때문)

4-4-3. 유스케이스 사이의 관계

종류

• 대안흐름 - 기본 유스케이스에서 이벤트의 흐름이 역간 변형되거나 선택, 예외인 경우
• 포함관계 - 다른 유스케이스에서 재사용 할 수 있도록 캡슐화하려는 경우 (A에도 포함, B에도 포함일 때)
• 확장관계 - 기본 유스케이스의 기본 이벤트 흐름이 특정 조건에 만족되었을 때 분리 확장된 것

포함관계

• 유스케이스 사이의 중복을 제거함
• 어떤 유스케이스가 다른 유스케이스를 포함하는 관계
• 공통된 동작을 떼어낼 수 있음
• 포함 유스케이스에 대해 정의된 동작이 기본 유스케이스에 대해 정의된 동작에 삽입된다

포함관계의 두 가지 경우

• 유스케이스의 기본 목적을 이해하는 데 꼭 필요하지 않은 이벤트 묶음을 떼 놓을 때
• 두 개 이상의 유스케이스에 공통적인 요소를 덜어 낼 때

위 그림에서 예금과 고객인증, 현금인출과 고객인증은 포함관계이다.

확장관계

• 확장 유스케이스에 정의된 동작이 기본 유스케이스에 정의된 동작에 삽입, 확장된 관계
• 확장은 기본 유스케이스에 포함되지 않은 예외적인 의미를 가짐

확장관계를 사용하는 목적

• 확장관계를 이용하여 선택적 동작을 필수 동작과 분리할 때 사용
• 서브플로우가 어떤 조건이 만족 되었을 때만 실행됨을 표시할 때 사용
• 기본 유스케이스의 확장 포인트에 하나 또는 여러 개의 동작 세그먼트가 삽입될 수 있음을 보여줄 때 사용

기본 유스케이스 자체는 완전해야 한다.

= 확장에 대한 언급 없이 이해가 가능하여야 하고, 별도로 실행할 수 있어야 함

사용자 스토리와 유스케이스

공통점 - 사용자가 이해할 수 있는 일상 언어로 요구를 나타냄(이해관련자들이 소통할 수 있게 만드는 도구)

차이점

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

특징 정리

4-5. 요구 명세

명세 - 분석한 요구사항을 모두 빠짐없이 명확하게 작성하는 것

요구분석 명세서(SRS - Software Requirement Specification) - 명세한 문서

요구명세서 목차

SRS에는 대상 시스템이 어떻게 할 것인가가 아니라 무엇을 할 것인가가 기술이 된다.

4-5-1. 작성 방법

• 명세의 내용은 고객과 개발자 사이에서 모두가 이해하기 쉽고 간결하게 작성되어야 한다
• 기술된 모든 요구사항은 검증이 가능하여야 한다 (시스템의 품질, 상대적 중요도, 품질 측정, 검증방법 등을 명시)
• 참여자들이 시스템의 기능을 이해하기 쉽고 변경에 대한 영향 분석 등을 고려하여 계층적으로 구성한다.

요구분서 명세서 작성 시 주의사항

1. 요구분석 명세서는 사용자와 개발자 모두가 쉽게 이해할 수 있도록 써야 한다.
2. 명세서에 기술된 조건은 개발자와 사용자 모두가 동의하고 이해 한 것 이어야 한다.
3. 명세서는 목표 시스템에 의하여 수행될 모든 기능들을 정확히 기술하여야 한다.
4. 명세서는 목표 시스템에 영향을 주는 모든 제약 조건을 기술하여야 한다.
5. 명세서는 시스템 인수를 위한 테스트 기준을 제공해야 한다.
6. 명세서는 원하는 시스템의 품질과 상대적인 중요도 및 품질 측정방법이 기술되어야 한다.

4-6. 요구 검증

사용자의 요구가 요구분석 명세서에 올바르게 기술되었는지 검토하는 활동

검증을 위해 체크하는 내용은 다음 표와 같다.