소프트웨어 공학 (Software Engineering ) 요구 분석 (Requirement Analysis) 문양세 강원대학교 IT 대학 컴퓨터과학전공

1. 소프트웨어 공학 (Software Engineering) 요구 분석(Requirement Analysis) 문양세 강원대학교 IT대학 컴퓨터과학전공

2. In this chapter … (1/2) 요구 분석 (Requirement Analysis) • 무엇을 개발할 것인가를 정확하고 완전하게 결정하는 단계이다. • 정확성  Correctness • 완전성  Completeness • 다른 단계(설계, 구현, 테스트)에 비하여 잘못되었을 때 다시 개발해야 하는 비용이 가장 크다. • 요구 분석 단계의 작업은 “어떻게(how)”보다는 “무엇을(what)”에 초점을 맞추어 진행한다.

3. In this chapter … (2/2) 요구 분석 (Requirement Analysis) 요구의 결정 과정 • We will cover … • 요구란? • 요구 추출과 분석 • 구조적 분석 • 객체지향 분석 • 요구 분석 명세서

4. We are now … 요구 분석 (Requirement Analysis) 요구(Requirements) 요구 추출과 분석 구조적 분석 객체지향 분석 요구 분석 명세서

5. 요구(Requirements)란? (1/2) 요구 분석 (Requirement Analysis) • 요구란 • 시스템이 가져야 할 기능이나 시스템이 만족하여야 할 조건 • 시스템이 제공하여야 할 서비스나 제약 조건을 포괄적으로 기술한 것부터 수학 기호로 자세히 표현한 것까지 다양함 • 요구 분석의 목적 • 소프트웨어가 무엇을 위하여 필요한지 정확히 이해 (understanding) • 이해한 것을 다른 개발자에게 정확히 전달 (communicating) • 시스템이 명세에 맞도록 제품 개발을 콘트롤(control) • 현금 인출기의 예 • 외형적 기능: 현금 인출, 잔액 조회, 계좌 이체, 현금 서비스, … • 기능 및 성능: 시간당 처리 능력, 반응 시간, 제약 조건(습도, 온도 등), …

6. 요구(Requirements)란? (2/2) 요구 분석 (Requirement Analysis) • 요구의 두 가지 사용 형태 • 프로젝트 수주를 위한 제안의 기초  제안서에 포함되며, 어떠 어떠한 기능을 제공하겠다… 일단 제안이 목적이므로 서로 다른 해석이 가능하다 (同床異夢) • 프로젝트 계약의 기초 상세히 기술되어야 함 (정확성, 완전성) 특히, 외국과 일할 시에는 매우 신중하게 작성해야 함  일하고 벌금 물고하는 …

7. 요구의 실제 예제 (1/2) 요구 분석 (Requirement Analysis) 성능 관련

8. 요구의 실제 예제 (2/2) 요구 분석 (Requirement Analysis) 기능 관련

9. 요구의 종류 요구 분석 (Requirement Analysis) 사용자 요구:시스템이 제공할 서비스와 수행될 때의 제약 조건을 그림이나 글로 표현한 것  사용자를 위하여 작성 시스템 요구:시스템이 제공하여야 할 서비스를 체계적으로 자세히 적은 것 계약자(계약사)와 개발자(개발사) 사이의 계약 소프트웨어 명세(specification):개발될 소프트웨어에 대하여 기술한 것으로 설계와 구현에 기초가 됨 개발자를 위하여 작성 (규격은 어떻고, 언어는 어떻고, …)

10. 요구 분석 요구 분석 (Requirement Analysis) • 요구 분석: 무엇을 개발할 것인가를 결정하는 단계 • 잘못 되었을 때 바로 잡기 위한 비용이 큼 • Requirements Engineering (요구 분석가: Requirement Analyzer) • 시스템 요구 • 기능적 요구 (functional requirements) • 소프트웨어의 종류, 사용자, 소프트웨어가 수행되는 시스템에 따라 다름 • 시스템이 사용자를 위하여 무엇을 하는가를 거시적으로 기술 • 비기능적 요구 (non-functional requirements) • 성능: 응답 시간, 처리량, 신뢰도, 보안성, 운용 제약 • 개발 비용: 투자한계

11. 기능적 요구 (1/2) 요구 분석 (Requirement Analysis) • 기능 자체와 관련된 질문 • 시스템이 무엇을 하는가? • 시스템이 언제 그 일을 하는가? • 시스템 운용될 때 여러 가지 다른 모드가 있는가? • … • 자료와 관련된 질문 • 입력, 출력이 무엇이며 어떤 형태를 갖는가? • 얼마나 자주 자료를 받고 내보내는가? • 시스템에 유입되는 자료의 양은 얼마나 되는가? • 데이터는 어느 기간 동안 보관해야 하는가? • …

12. 기능적 요구 (2/2) 요구 분석 (Requirement Analysis) • 인터페이스와 관련된 질문 • 다른 시스템에서 유입, 유출되는 입력은 무엇인가? • 다른 시스템과 인터페이스하는 프로토콜의 종류는 무엇인가? • 자료 전달에 사용되는 특정 미디어 형식이 있는가? • … • 사용자와 관련된 질문 • 누가 시스템을 사용할 것인가? • 사용자가 여러 그룹인가?  일반 사용자, 운영자, 관리자 등 • 각 사용자 그룹의 컴퓨터 사용 경험은? • 각 사용자 그룹에 따라 필요한 교육은? • …

13. 비기능적 요구 (1/2) 요구 분석 (Requirement Analysis) • 자원과 관련된 질문 • 시스템 구축 및 유지보수에 필요한 자원, 인력은 무엇인가? • 개발자가 갖추어야 할 기본 요구사항이 있는가? • 어떤 하드웨어를 사용할 것인가? • 시스템이 차지할 수 있는 공간은 어느 정도인가? • 동작 환경(전력, 온도, 습도)에 대한 제약은 없는가? • 개발된 시스템의 디스크, 메모리 공간의 제약은 없는가? • … • 성능과 관련된 질문 • 시스템의 속도, 반응 시간, 처리율(TPS: transactions per second, CPS: calls per second, MIPS, …) • 시스템에 의하여 처리되는 자료의 크기 • …

14. 비기능적 요구 (2/2) 요구 분석 (Requirement Analysis) • 보안과 관련된 질문 • 자료와 시스템에 대한 접근이 통제되어야 하는가? • 사용자들 사이에 타인에 대한 데이터 및 프로그램 접근 방지 • 시스템의 백업 기간 및 책임자 • 화재, 홍수, 도난 등의 재난을 대비한 방지책은? • 물리적 보안 대책? ( 세콤?) • … • 품질과 관련된 질문 • 신뢰성, 가용성, 유지보수성, 보안 등의 품질 특성에 대한 요구 • 시스템이 가동되는 평균 시간 • 시스템의 작업이 중단된 후 다시 복구될 때까지 허용되는 시간 • 설계 변경이 얼마나 용이한가? • 얼마나 쉽게 위치나 플랫폼 변경이 가능한가? ( Portability) • …

15. We are now … 요구 분석 (Requirement Analysis) 요구(Requirements) 요구 추출과 분석 구조적 분석 객체지향 분석 요구 분석 명세서

16. 요구를 어떻게 모을까? 요구 분석 (Requirement Analysis) • 스웨덴에서 8000개 이상의 프로젝트를 조사한 결과 프로젝트가 성공한 이유 중 가장 중요한 요소는 … 사용자의 참여(User Involvement) • 엔드 유저를 쉽게 만날 수 있는 것이 프로젝트 성공의 중요한 요소 임(스티브맥코넬)

17. 요구는 어떻게 파악해야 하나? 요구 분석 (Requirement Analysis) 고객과 함께 일하면 좋은 관계는 개발 속도를 높임 예상되는 개발 속도를 향상시킴 고객이 원하는 것이 무엇인지 항상 아는 것은 아님 원하는 바를 알지 못하며 시간이 지나면서 요구가 변함

18. 요구 분석가의 역할? 요구 분석 (Requirement Analysis) • 요구 분석가는 기자의 취재와 유사한 작업을 수행한다. • 사용자를 만나 면담을 수행한다. • 실제 업무에 참관하거나, 업무를 직접 수행해 보기도 한다. • 분석가는 비판적이고 객관적이어야 한다. 기자가 한쪽 편의 이야기만을 들어서는 되지 않는다. • 분석가는 기자와 마찬가지로 6하 원칙에 따라서 정보를 수집한다.  다음 페이지 참조 • 기자가 취재를 종합하여 기사를 쓰듯이, 요구 분석가는 다양한 요구 추출을 통하여 요구 분석서를 작성해야 한다.

19. 분석 단계 질문의 5W1H 요구 분석 (Requirement Analysis) • (Who) 분석 대상 업무에 누가 관련되는가? • 관계자들의 작업 • 사용자 수준 • (What?) 현재의 상태는? • 문제를 일으킨 상태 • 제안된 시스템의 기능 • (When?) 새로운 시스템은 언제 완성되어야 하나? • (Where?) 새로운 시스템은 어떤 환경에 놓일 것인가? • 새 시스템에서의 조직, 환경 • (Why?) 왜 새로운 시스템을 고려하게 되었나? • (How?) 새 시스템의 어떻게 작동할 것인가? • 제약, 하드웨어 요구, 비용, 사용 언어

20. 요구 추출의 어려움 요구 분석 (Requirement Analysis) 기존에 대충이라도 굴러가는 시스템이 있다면, 기능과 프로세스가 존재하기 때문에 요구를 추출하는 작업이 용이함 BUT, 아직 존재하지 않는 문제에 대해 요구를 추출해야 한다면, 사용자와 함께 해법을 찾아야 하므로 요구 추출이 어려움

21. 요구의 우선 순위 요구 분석 (Requirement Analysis) 1) 절대적으로 필요한 요구  전필? 2) 요망되나 꼭 필요한 것은 아닌 요구  학점 못 채운 경우의 전선? 3) 요구로 볼 수는 있으나 제외될 수 있는 요구  학점 채운 경우의 전선? • 신용카드 대금청구서 예제 • 거래 내역, 총 금액 계산, 납부 기일 명시  1)에 해당 • 일시불, 할부 등의 구매 형태 표시  2)에 해당 • 취소된 내역과 승인된 내역을 다른 색으로 표시  3)에 해당

22. 요구 추출을 위한 자료의 출처 요구 분석 (Requirement Analysis) 요구 템플릿 재사용 라이브러리

23. 요구 추출의 지혜 요구 분석 (Requirement Analysis) 요구 추출에서 가장 어려운 점은 “사용자가 원하는 것을 기록하는 작업이 아니라 사용자가 무엇을 원하는지 알 수 있도록 개발자들이 도움을 주는 것”(스티브맥코넬) 사용자와 같이 생각하기 위하여 사용자와 같이 (생각/행동)하기 –시스템이 어떻게 쉽게 사용될 수 있을까에 초점 사용자와 함께 하면서 가장 합리적인 고객의 기대치를 설정

24. 잘못된 요구 분석 요구 분석 (Requirement Analysis) (a) 고객이 설명한 요구 (b) 분석가가 이해한 요구 (c) 분석가가 설계한 요구

25. 요구 분석 사례: 항공권 예매 시스템 요구 분석 (Requirement Analysis) 항공편, 탑승객, 예약 입력 기능적 요구(입력) 티켓과 리포트에 어떤 정보가 표시될 것인가  기능적 요구(출력) 요금계산 방법  기능적 요구(컴퓨팅) 여행사와 고객이 데이터베이스에 접근할 때 어떤 정보를 얻을 수 있나? 기능적 요구(저장) 자주 탑승하는 고객의 서비스를 위하여 시스템을 확장할 수 있도록 설계  비기능적 요구(확장성) 시스템은 언제나 사용 가능해야 하며, 일주일에 2시간의 다운만을 허용 비기능적(가용성) 항공편을 출발 시각으로 정렬할 때 Merge Sort 알고리즘을 이용함 요구가 아님

26. 요구추출 방법 요구 분석 (Requirement Analysis) 요구를 효과적으로 추출하고 분석하는 체계화된 기술

27. 관찰 요구 분석 (Requirement Analysis) • 문서를 읽고 사용자와 함께 요구에 대하여 논의한다. • 잠재적인 사용자들이 수행하는 복잡한 일을 관찰한다. • 사용자가 하는 일을 자세히 설명해 달라고 요구 • 경우에 따라, 해당 회사에서 함께 근무하며 요구를 파악하기도 함 • 비디오 촬영 예) 도매상에서 점원이 사려는 고객과 물건을 매매하는 과정 • 단점: 시간이 많이 소요

28. 인터뷰 (1/2) 요구 분석 (Requirement Analysis) • 미리 잘 계획하면, 짧은 시간에 많은 정보를 얻을 수 있음 • 가능하면 많은 당사자와 인터뷰 • 관련자 이외의 다름 사람도 인터뷰 • 예: 경쟁 제품의 사용자, 마케팅 담당자 등 • 인터뷰 시간은 예상 보다 여유 있게 시간을 할애하여야 함

29. 인터뷰 (2/2) 요구 분석 (Requirement Analysis) • 여러 번의 인터뷰를 준비하고, 충분한 질문을 준비함 • 포함시켜야 할 질문 유형 • 구체적인 설명 요구예) 최대, 최소, 예외 규칙, 예상 되는 변동 등 • 관련자의 시스템에 대한 미래 비전 어떤 융통성을 가져야 하는지 제안될 수도 있음 • 다른 아이디어가 있는지 질문  구현 대안을 찾을 수도 있음 • 최소한의 허용 가능한 솔루션이 무엇인지 질문 모든 기능을 아는 것도 중요하지만, 우선 순위를 파악하는 것도 중요함 • 다른 정보원이 없는지 질의  다른 인터뷰 대상자를 찾을 수도 있음 • 다이어그램 작성 요구  정보 흐름 등을 파악할 수 있음

30. 브레인스토밍 요구 분석 (Requirement Analysis) • 아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의 • 훈련된 요원이 주재하여 브레인스토밍 과정을 정돈(관리)해야 함 • 토론보다는 아이디어를 쏟아놓는 회의, 익명성 보장 • JAD(Joint Application Development) –집중 브레인스토밍세션 • 개발자가 고객(혹은 사용자)과 격리된 장소에서 사나흘 회의함 • 하나의 그룹으로 작업하거나, 특정 문제에 대해 여러 개의 작은 그룹으로 작업할 수도 있음 • 참여자가 다른 업무로 중단 받아서는 안되므로, 학회나 수련회처럼 격리된 장소에서 수행할 필요가 있음

31. 브레인스토밍 과정 요구 분석 (Requirement Analysis) 관련자 모두가 참여하는 회의 소집 (5명 ~ 30명 수준) 경험 많은 사람을 회의 주재자로 선정 테이블에 참석자를 배석시키고 종이 준비 토론을 유도할 질문을 정함 (다음 페이지 참조) 질문에 대하여 답을 종이에 적되 한 장에 하나의 아이디어만 적은 후,참석자에게 돌려 봄 5번 단계를 5~15분간 반복(아이디어가 없을 때까지 반복) (원래 아이디어 제안자가 그 내용을) 간단히 설명 모든 아이디어를 칠판에 적은 후 우선순위를 정하기 위하여 투표를 할 수도 있음

32. 브레인스토밍의 유도 질문 요구 분석 (Requirement Analysis) • 참석자가 Yes, No식의 대답이 아닌 짧은 문장의 대답이 나와야 함 • 유도 질문은 회의 소집자, 주재자, 간단한 토론 등을 통해 결정함 • 유도 질문의 예 • 어떤 기능이 이 시스템에서 중요한가? • 미래에 어떤 자료의 출처가 예상되는가? • 시스템에서 어떤 출력이 생성되어야 하는가? • 도메인 모델에서 어떤 클래스가 필요한가? • 인터뷰 질문에서 무엇을 물을 것인가? • 고려하지 않을 이슈는 무엇인가? • 이 프로젝트의 리스크는 무엇인가?

33. 프로토타이핑(1/4) 요구 분석 (Requirement Analysis) • 프로토타입이란? 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램 • 가장 단순한 형태: paper prototype • 시스템이 수행될 때 무엇이 일어날지 설명한 그림을 순서대로 그린 것 • 다수 개발자가 다른 버전을 병행 제작하여, 가장 좋은 것을 선택함

34. 프로토타이핑(2/4) 요구 분석 (Requirement Analysis)

35. 프로토타이핑(3/4) 요구 분석 (Requirement Analysis) • 가장 흔한 형태: 모의 사용자 인터페이스 • 프로토타이핑 전용 언어(rapid prototyping language)로 작성 • 컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가능

36. 프로토타이핑(4/4) 요구 분석 (Requirement Analysis)

37. We are now … 요구 분석 (Requirement Analysis) 요구(Requirements) 요구 추출과 분석 구조적 분석 객체지향 분석 요구 분석 명세서

38. 구조적 분석 – 개요 (1/2) 요구 분석 (Requirement Analysis) • 정의: 사용자의 요구분석 사항을 파악하기 위하여 자료의 흐름과 가공 절차를 그림으로 표현하는 방법 처리-중심(process-oriented)의 분석 기법 • 구조적 분석은 전체 시스템이 만들어지기 전에 해당 시스템의 모형을 만드는 절차로 볼 수 있다. • 세부 작업 순서 • 배경도 작성  학교 전체를 사진에 담는다. • 상위 자료 흐름도 작성  개별 단과대학을 사진에 담는다. • 하위 자료 흐름도 작성  개별 강의실/연구실을 사진에 담는다. • 자료 사전 작성  각 건물, 방의 이름을 기술한다. • 소단위 명세서 작성  건물, 방으로의 접근 방법을 기술한다.  참고: 자료 흐름도는 DFD(Data Flow Diagram)을 번역한 용어이다.

39. 구조적 분석 – 개요 (2/2) 요구 분석 (Requirement Analysis) • 특징 • 그림(그래프) 중심으로 표현  글로 표현하는 것보다 이해하기 쉬움 • 하향식(top-down partitioning) 원리를 적용 • 사용자의 업무 요구 사항을 쉽게 문서화할 수 있음 • 사용자, 분석자 간의 의사소통을 위한 공용어 역할을 함 • 실체의 모형(추상적 표현)을 추출 건물의 경우, 모형을 만들어 좀 더 자세한 요구사항 분석이 가능하다. 유사한 개념으로, 소프트웨어도 구조적 분석을 통한 모형을 만들어 좀 더 자세한 요구 분석을 수행할 수 있다.

40. 자료 흐름도의 구성 요소 (1/2) 요구 분석 (Requirement Analysis) 프로세스(process): 대부분 원이나 둥근 사각형으로 표기한다. 프로세스의 이름을 내부에 기재한다. 프로세스 이름 프로세스 이름 자료 흐름(data flow): 두 프로세스 사이의 자료 경로는 화살표로 표시한다. 화살표 위에 전달되는 자료의 이름을 기재한다. 자료 이름

41. 자료 흐름도의 구성 요소 (2/2) 요구 분석 (Requirement Analysis) 파일 혹은 자료 저장소(data store): 한쪽이 열려진 사각형, 혹은 한 쌍의 평행선으로 표시한다. 저장소의 이름을 안에 기재할 수 있다. 저장소 이름 저장소 이름 자료의 출처(data source)와 도착지(data sink): 직사각형으로 표시하며, 내부에 이름을 기재한다. 자료 출처의 이름

42. 옥수수 1 밀가루 식빵 만들기 식빵 2 계란 식빵 포장 우유 3 박스에 넣은 식빵 포장된 식빵 빵을 배달 식빵 공장의 DFD (1/2) 요구 분석 (Requirement Analysis) 최상위 흐름도 재료 (재료) 공급자 식빵 공장 배급자 포장된 식빵 1차 구체화

43. 1.1 옥수수 옥수수 씻고 고르기 깨끗한 옥수수 옥수수 1 1.3 밀가루 식빵 만들기 식빵 2 버터와 버무림 반죽 1.2 계란 식빵 포장 반죽을 만듦 밀가루 우유 준비된 반죽 계란 3 1.4 박스에 넣은 식빵 포장된 식빵 우유 빵을 배달 식빵을 구워냄 구워낸 식빵 식빵 공장의 DFD (2/2) 요구 분석 (Requirement Analysis) 2차 구체화

44. 자동 색인 시스템 (1/2) 요구 분석 (Requirement Analysis) • 자동 색인? • 주어진 텍스트 파일에서 단어들을 추출하여, • 단어들을 정렬하고, • 해당 단어들이 어디에서 나오는지, 몇 번 나오는지를 기록한다. • 쉽게 생각하면 • 텍스트 파일을 한 줄씩 읽어서, • 새로운 단어이면 색인에 새롭게 넣고, • 각 단어에 대해서는 위치(예: 페이지, 줄번호)를 리스트로 달아두면 된다.

45. 자동 색인 시스템 (2/2) 요구 분석 (Requirement Analysis) 자동 색인 시스템의 DFD

46. 프로세스 (Process, 처리) 요구 분석 (Requirement Analysis) • 입력 자료 흐름을 출력 자료 흐름으로 변환 • 원으로 표현하고 그 안에 처리의 이름을 적는다 • 처리의 이름은 • 처리가 하는 일 또는 • 처리를 수행하는 행위자로 기술한다 • 고유번호가 주어짐 • 차후 소단위 명세의 대상 (무엇을 해야 하는지 결정해야 하는 대상) 1.1 임대비용 계산 3.4.5 고객별 명세서 작성 3 간호사

47. 자료의 흐름 (Data Flow) 요구 분석 (Requirement Analysis) 자료흐름은 변형되어 이동중인 자료군을 나타냄 이동 방향을 표시한 화살표로 나타냄 화살표 위에 자료군의 이름을 붙임 자료 저장소에 연결된 자료의 흐름은 저장소에 자료군을 운반하여 저장함을 뜻함 초기환자자료 치료계획철 1 초기치료 계획 환자상태 자료 2 환자상태 기록 환자상태 불충분 메시지 감염정도 환자상태 환자철

48. 자료 저장소 (Data Store) 요구 분석 (Requirement Analysis) 머물고 있는 자료군의 집합 파일, 데이터베이스, 서류철 등 자료 저장소는 한쪽이 열려진 사각형 혹은 한 쌍의 평행선으로 표현 신용카드 사용전표 신용카드 사용내역철 1 신용카드 사용내역 기록 2 고객별 명세서 작성 사용내역서 고객철

49. 단말(Terminal), 자료 출처/도착지 요구 분석 (Requirement Analysis) 대상 시스템 밖에서 의사 전달하는 사람, 부서, 또는 다른 자동화 시스템 단말은 사각형으로 표현하고 그 명칭을 부여 명칭은 한 개인, 부서를 기술하기 보다는 그 역할을 기술 분석실 병원 행정 분석기록 조회 의료비 자료 의료 기록 시스템 증상, 처방 의 사

50. 자료 흐름도 작성 (1/3) 요구 분석 (Requirement Analysis) 계층적 분할에 의하여 단계적으로 표현 • 배경도(context diagram) 작성 • 개발하려는 시스템과 외부세계와의 인터페이스를 식별 • 시스템 분석의 범위를 설정 • 시스템 전체를 나타내는 하나의 처리와 관련된 단말들로 표시 재료 (재료) 공급자 식빵 공장 배급자 포장된 식빵