소프트웨어 공학 Lecture #4: 요구 분석

Presentation on theme: "소프트웨어 공학 Lecture #4: 요구 분석"— Presentation transcript:

1 소프트웨어 공학 Lecture #4: 요구 분석
최은만 저 6차 개정판 1

2 학습 목표 요구 요구 추출 도메인 분석 사용 사례 요구 명세서 요구 분석 도구

3 요구 분석 소프트웨어 개발의 실질적인 첫 단계 사용자의 요구에 대하여 이해하고 정리하는 작업 두 가지 작업
현재의 상태를 파악하고 요구를 정의 명세서 작성 요구의 변경은 파급효과가 큼

4 요구 분석 과정 요구 추출 – 기능적인 요구와 기능 이외의 조건 추출 도메인 분석 – 요구에 대한 정보를 수집하고 배경을 분석
요구 추출 – 기능적인 요구와 기능 이외의 조건 추출 도메인 분석 – 요구에 대한 정보를 수집하고 배경을 분석 모델링 – 도메인 분석을 통해 얻은 자료를 개념화 프로토타이핑과 시험 – 분석된 기능적 요구의 타당성시험을 위한 프로토 타입 생성 문서화 검토 – 요구 분석서를 작성

5 4.1 요구(Requirements) 시스템이 제공해야 할 역량(capability) 외형적으로 나타내는 기능이나 성능

6 요구 기능적 요구(functional) 기능적 요구와 사례(표 4.1) 시스템과 외부 요소들 간의 인터랙션
시스템이 어떤 상태일 때 외부의 데이터나 명령에 대해 어떤 반응을 하는지 기술 기능적 요구 항목으로 제기되는 문제들은 사용자의 문제를 해결하기 위한 구현 기술과는 독립적인 사항 기능적 요구와 사례(표 4.1) 기능 자료 입출력 사용자

7 요구 비기능적 요구(non-functional) 종류 비기능적 요구와 사례
시스템 구축에 대한 성능, 보안, 품질, 안전 등에 대한 요구 사항 종류 성능 – 시스템의 처리량, 반응시간, 실시간 처리, 자원 이용률 품질 – 신뢰성, 가용성, 사용시 오류 발생률 안전 – 의도하지 않은 오퍼레이션으로 인하여 원치 않는 상태에 있는 것을 방지하는 역량 보안 – 시스템의 자원을 악의적인 공격으로부터 보호할 수 있는 역량 사용성 – 인터페이스. 동작, 보고 느끼는 것(look and feel) 비기능적 요구와 사례 표 4.2

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

9 4.2 요구 추출 추출 세 가지 단계 정보 수집 방법 응용에 대한 정보 출처 파악 응용에 대한 정보 취합
요구와 제한 사항의 정의 정보 수집 방법 고객의 발표 문헌 조사 업무 절차와 양식 조사 관련자들 설문지 사용자와의 인터뷰 브레인 스토밍 회의 사용 스토리 또는 사용사례 작성

10 4.2 요구 추출 우선 순위에 따른 요구 구별 절대적으로 필요한 요구 요망되나 꼭 필요한 것은 아닌 요구
요구로 판단될 수 있으나 제외될 수도 있는 요구

11 요구 정보 출처 정보 출처 유형 고객 도메인 전문가 – 비즈니스 도메인을 지원하는 시스템을 구축하기 위하여 필요한 사람(예, 회계 시스템을 구축하기 위하여 회계사가 필요) 이해당사자(stakeholder) – 시스템 운용으로 인하여 영향 받는 사람 사용자 – 시스템을 직접 사용하는 사람 역공학

12 고객의 발표 개발팀이 구축하는 시스템에 대하여 초기에 개념을 잡을 수 있음 효과적인 가이드라인
고객 업무를 잘 알고 있는 운영 책임자나 관리자가 발표 발표하기 전 개발 팀원이 필요한 정보가 있는지 검토 의심이 가는 부분을 질문하여 명확히 할 것 구현과 관련된 토의는 배제 발표 내용의 복사본을 팀원과 공유 2시간 이상의 발표회는 지양

13 문헌조사 유사한 프로젝트를 조사 업무 문서나 양식을 조사 산업 및 기업 표준 조사 관련 정부 정책/규제 조사
현재 개발할 시스템에 대한 통찰 제공 업무 문서나 양식을 조사 현재의 업무나 시스템 정보에 대해 깊은 이해 가능 산업 및 기업 표준 조사 관련 정부 정책/규제 조사

14 업무 절차 및 양식 조사 업무 관련 문서, 절차, 양식, 운영 매뉴얼 조사 내부 표준 조사
정부, 산업, 기억의 특수 정책이나 규정 조사

15 설문 관리자나 사용자와 같은 이해 당사자를 대상 이해 당사자들이 의사결정 과정에 포함 무기명 설문 유의사항
이해 당사자들의 관심과 내부정보, 개선 의견 도출 감추어진 정보를 끌어내기 쉬움 유의사항 질문은 간단하고 중요한 이슈에 집중 적절하고 잘 기술된 질문

16 인터뷰 인터뷰 수행 가이드 라인 가능하면 많은 당사자와 인터뷰 여유로운 인터뷰 일정 인터뷰 약속 시간을 넘기더라도 여유롭게
중요한 관련자와는 여러 차례 인터뷰

17 인터뷰 반드시 포함해야 할 질문 또는 행동 유형 최대, 최소, 예외 규칙, 예상되는 변동 등 자세한 사항
시스템에 대한 미래의 비전 문제에 대한 최소한의 허용 가능한 솔루션이 무엇인지 다른 정보원은 없는지 인터뷰 대상자에게 다이어그램을 작성하게 함

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

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

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

21 사용자 스토리 사용자와 개발 팀이 함께 작성 사용자들이 시스템에 바라는 역량을 간단히 기술한 것
내부 사람이 만들기 때문에 효과적

22 요구와 제한의 정의 수집한 정보에서 요구와 제한 사항을 도출 요구 도출 과정 사용자 니즈 파악 요구 도출

23 4.3 도메인 분석 도메인이란? 설계 모델링에 필요한 여러 개념과 비즈니스 룰을 파악
요구의 배경 설계 모델링에 필요한 여러 개념과 비즈니스 룰을 파악 응용 분야에 존재하는 개념을 잘 정의하고 분석하여 시스템에 존재하는 개념으로 정립하는 단계

24 도메인 정의 업무 작업 영역을 파악하고 범위를 규정 정보 시스템의 서브시스템 개념이 되는 프레임워크 제공
정보 시스템을 구축하는데 필요한 개념적인 프레임워크 제공 정보 시스템의 서브시스템 개념이 되는 프레임워크 제공 넓은 범위의 개념을 더 좁은 범위의 지식들로 체계화 하는 작업

25 도메인 분석 도메인 배경 파악 세가지 단계 도메인 개념 찾기 도메인 사전 작성 비즈니스 규칙 정리

26 도메인 개념 도메인의 목적, 구조, 동작을 구성하는 객체, 프로세스, 사람, 룰 같은 것 도메인 개념 발견을 위한 주의사항
요구의 핵심을 발견해야 함 요구가 해결될 것 같은 문제를 발견 문제의 요소를 발견 관련된 도메인의 개념을 발견

27 도메인 사전 도메인 개념을 조직화한 결과물 각 항목은 용어가 사용될 때는 언제든 같은 의미로 통하게 하는 간결한 정의
요구, 인터뷰, 매뉴얼로 부터 추출 도메인 정의에서 표현된 문장, 어절, 제목에 초점을 두고 개념 추출 <예> 의료 정보 시스템에서 도메인 개념 추출 진료와 검사 의료 서비스의 성격에 따라 의사, 간호사, 검사원 이 환자에게 적절한 예약된 의료 서비스를 제공한다. 도메인 개념: 의료 서비스, 의사, 간호사, 검사원, 환자, 예약

28 도메인 사전 사전 양식 표로 구성 세가지 항목 포함 명칭 타입 설명

29 비즈니스 규칙 업무에서 지키기로 한 규정 기업이 운영되는 자세한 정책, 규정, 절차, 가이드라인, 표준의 집합
사용자에게 요구해도 준비된 전체 목록을 받기 어려움 비즈니스 규칙 종류 사실(fact) – 개념이 무엇인지 설명 추론(inference) – 다른 사실로 부터 얻은 사실 액션 구동자(action enabler) – 조건이 일치되면 액션이 수행 제약(constraints) – 시스템이나 외부 요소가 수행할 또는 수행하지 않을 제약을 가하는 규칙 계산(computation) – 공식이나 알고리즘

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

31 사용 사례의 소개 시스템의 사용자에게 서비스를 제공하기 위한 상호작용의 단위
사용자 또는 외부 시스템이나 기타 요소들이 시스템과 상호작용 하는 다이얼로그를 모델링 시스템 설계자/테스트 프로그래머들이 의사 교환하는데 유용 소프트웨어 개발자와 이해 당사자 간의 계약

32 사용 사례의 소개 사용사례 구축 시 주의 사항 시스템 내부를 모델링 하는 것이 아님
비기능적 요구를 찾아내는 데 효과적인 방법이 아님 시스템의 흐름도가 아님 단계적 분할이 아님 ‘어떻게’가 아니라 ‘무엇을’ 시스템이 하는가

33 사용 사례 다이어그램 시스템의 기능을 나타내기 위하여 사용자의 요구를 추출하고 분석하는데 사용 구성
사용 사례(use case) – 시스템 기능 액터(actor) – 시스템과 상호작용 하는 것(사용자, 시스템)

34 액터와 사용사례 액터 액터가 될 수 있는 것 사용사례 시스템과 상호작용 하는 외부 엔티티 구별되는 이름과 설명이 필요
사용자가 맡은일 다른 시스템 사용사례 액터의 입장에서 본 시스템의 동작(외부동작) 액터가 볼 수 있는 결과를 내는 이벤트의 집합 다른 사용 사례를 가동시킬 수 있음

35 액터 찾기 액터를 찾기 위한 질문 어떤 사용자 그룹이 작업을 수행하기 위하여 시스템의 지원을 받는가?
어떤 사용자 그룹이 시스템의 주요기능을 사용하는가? 어떤 사용자 그룹이 유지 보수와 관리 등의 부수적 기능을 사용하는가? 시스템이 다른 외부 하드웨어나 소프트웨어 시스템과 동작하는가? <예> 비디오 대여점의 액터

36 사용 사례 찾기 여러 개별 시나리오를 묶은 것 시나리오로부터 사용 사례 형성 예: 사용 사례와 시나리오 정상적인 흐름
오류, 예외 케이스 시나리오로부터 사용 사례 형성 예: 사용 사례와 시나리오

37 시나리오 구성 개발자와 사용자가 함께 작성 현재의 응용 도메인에 대하여 기술한 여러 문서를 이용(지침서, 절차 매뉴얼 등)
필요한 질문 시스템이 어떤 작업을 수행하기를 액터가 원하는가? 액터가 원하는 정보는 무엇인가? 누가 데이터를 생성하는가? 데이터는 조작, 삭제될 수 있는가? 이런 작업이 누구에 의하여 행해지는가? 액터가 시스템에 정보를 알리는데 필요한 것은? 얼마나 자주 또 언제 이런 작업이 일어나는가? 액터가 시스템으로부터 정보를 알아내는데 필요한 이벤트는? 이런 사건의 빈도는?

38 완성된 사용 사례 예 사용 사례 이름 : 참여 액터 : 시작 조건 : 사건의 흐름 : 종료 조건 : RentVideo
User에 의하여 구동됨 스캐너를 이용 1. User가 터미널에서 “비디오 대여” 기능을 활성시킨다. 시스템이 고객 ID 입력 양식을 화면에 제시하여 반응한다. 2. 점원인 User가 비디오를 대여하려는 고객에게 전화번호의 끝 네 자리를 물어 입력한다. 3. 입력한 네 자리로 찾은 이름들을 화면에 보여주고 맞는 것을 선택하도록 한다. 4. 연체료가 있다면 화면에 출력하고 없으면 스캐너를 이용하여 대여하려는 비디오 ID를 입력한다. 5. 비디오 ID를 이용하여 비디오 정보를 찾아 화면에 출력하고 대여중인 비디오 데이터베이스에 기록한다. 대여할 비디오가 더 있으면 반복한다. 6. User가 대여료를 받고 테이프를 건네준다.

39 사용 사례 관계 찾기 관계를 이용하여 모형의 복잡도를 줄이고 이해도를 높인다. 관계 종류
포함(include) – 정상적인 이벤트와 예외적인 이벤트를 분리 확장(extend) – 사용 사례 사이의 중복을 제거

40 포함 관계 사용 사례 사이의 중복을 제거함 어떤 사용 사례가 다른 사용 사례를 포함하는 관계 공통된 동작을 떼어 낼 수 있다.
<예> 포함 관계의 예

41 확장 관계 사용 사례가 일정한 조건 아래 확장된 동작을 포함한다면 다른 사용 사례를 확장하는 관계에 있다.
<예> 사용자 정보 입력 중 미성년자를 위하여 부모 허락을 받는 사용 사례가 확장되는 경우

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

43 4.5 요구 분석 명세서 시스템의 기능을 정확하고 완벽하며 일관성 있게 작성한 것
소프트웨어에 포함될 기능과 제약 조건들을 나열 기능에 대한 자세한 설명과 예외처리 기술 시스템 성능과 관련된 사항, 속도, 정확성, 사용 용이성 포함 과정 명세서 작성 명세서 검토

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

45 요구 분석서 목차 1. 개 요 1.1 시스템의 목적 1.2 범위 1.3 정의, 약어 1.4 참조 2. 기능적 요구
2.1 외부 인터페이스 요구 2.1.1 사용자 인터페이스 2.1.2 하드웨어 인터페이스 2.1.3 소프트웨어 및 통신 인터페이스 2.2 기능 요구 2.2.1 기능 #1(사용 사례 #1) 2.2.2 기능 #2(사용 사례 #2) ... 3. 기타 요구 및 제약 사항 3.1 성능 요구(반응 시간, 처리 소요 시간, 처리율) 3.2 H/W 요구(기억 장치 규모, 통신수용도) 3.3 예외 조건 및 이의 처리 3.4 자원, 인력에 대한 제약 조건 4. 인수 조건 4.1 기능 시험 및 성능 시험 5. 참고 자료

46 명세서 검토 요구 분석 명세서 평가 기준 무결성과 완벽성 – 요구 분석서는 사용자의 요구를 오류없이 완벽하게 반영하고 있어야 한다. 일관성 – 요구 분석서 안에 서로 모순되는 부분이 없어야 한다. 명확성 – 요구 분석의 내용이 여러 의미로 해석되는 모호한 점이 없는지 살펴본다 기능적 – ‘어떻게’ 보다 ‘무엇을’에 관점을 두고 기술되어야 한다. 검증 가능성 – 요구 분석은 두 가지로 검증 가능해야 함 사용자 요구 만족 시스템이 요구 분석에 기술된 내용과 일치하는가 추적 가능성 및 변경 용이성 – 내용은 체계적으로 정리되어야 한다.

47 4.6 요구 관리 도구 요구 변경 요구 관리란? 요구 추가 기존 요구 삭제/변경
요구 변경과 관련된 모든 이슈를 다루는 메커니즘 <예> 요구 관리 작업

48 요구 관리 도구 ProR

49 Questions?