<4D F736F F F696E74202D205B34C0E55D20BFE4B1B8BBE7C7D720B0B3B9DF20B9D720B0FCB8AE2E BC8A3C8AF20B8F0B5E55D>

Size: px

Start display at page:

Download "<4D F736F F F696E74202D205B34C0E55D20BFE4B1B8BBE7C7D720B0B3B9DF20B9D720B0FCB8AE2E BC8A3C8AF20B8F0B5E55D>"

호재 경
5 years ago
Views:

1 1 4. 요구사항개발및관리

2 주요내용 요구사항이란무엇인가? 요구사항개발은어떻게진행되는것인가? 유스케이스기반의요구사항분석은무엇인가? 2

3 목차 강의내용 팀프로젝트 (5 주차 ) - 요구사항개발 - 제안서발표 - 요구사항개발프로세스 - 유스케이스기반의요구사항분석 3

4 4 요구사항개발

5 요구사항이란? 정의 - 문제의해결또는목적달성을위하여고객에의해요구되거나, 표준이나명세등을만족하기위하여시스템이가져야하는서비스또는제약사항 - 고객이요구한사항과요구하지않았더라도당연히제공되어야한다고가정되는사항들 5

6 요구사항의중요성 요구사항의중요성 - 참여자들로하여금개발되는소프트웨어제품을전체적으로파악하도록하여의사소통시간을절약하게해주는것 - 상세한요구사항이있어야만산정이가능하고, 이를기반으로계획을세울수있기때문 요구사항 설계구현테스트유지보수 가이드라인 가이드라인테스트의기준 가이드라인및지침 6

7 요구사항의분류 기능적요구사항 (Functional Requirements) - 수행될기능과관련되어입력과출력및그들사이의처리과정 - 목표로하는제품의구현을위해소프트웨어가가져야하는기능적속성 예 ) 워드프로세서에서파일저장기능, 편집기능, 보기기능등 비기능적요구사항 (Non-Functional Requirements) - 제품의품질기준등을만족시키기위해소프트웨어가가져야하는성능, 사용의용이성, 안전성과같은행위적특성 - 시스템의기능에관련되지않는사항을나타냄 예 ) 성능 ( 응답시간, 처리량 ), 사용의용이성, 신뢰도, 보안성, 운용상의제약, 안전성등 7

8 8 요구사항개발프로세스

9 요구사항개발 의미 - 발주자나고객으로부터구현될소프트웨어제품의사양을정확히도출하여요구사항을명세하고, 이를분석한결과를개발자들이이해할수있는형식으로기술하는작업 요구사항개발단계 요구사항개발 요구사항수집 / 추출요구사항분석요구사항명세요구사항검증 요구사항관리 9

10 요구사항추출 (1/2) 개요 - 고객이원하는요구사항을수집 - 수집된요구사항을통해개발되어야하는시스템에대한사용자요구와시스템기능및제약사항을식별하고이해하는단계 중요성 - 고객의최초요구사항은추상적이기때문에수주자는정확한요구사항을파악 - 요구사항은계약및최초산정의기본이됨 10

11 요구사항추출 (2/2) 요구사항추출기법의종류 - 인터뷰 개발될프로젝트참여자들과의직접적인대화를통하여정보를추출하는일반적인요구사항추출기법 획득가능한정보 개발된제품이사용될조직안에서의작업수행과정에대한정보 사용자들에관한정보등 요구사항분석가는인터뷰전략을세우고목표를달성해야함 - 시나리오 시스템과사용자간에상호작용을시나리오를작성하여시스템요구사항을추출 시나리오가포함해야할필수정보 시나리오로들어가기이전의시스템상태에대한기술 정상적인사건의흐름 정상적인사건의흐름에대한예외흐름 동시에수행되어야할다른행위의정보 시나리오의완료후에시스템상태의기술 11

12 요구사항분석 (1/2) 개요 - 추출된고객의요구사항을분석기법을이용하여식별가능한문제들을도출하고요구사항을이해하는과정 - 참여자들로부터추상적요구사항을명세서작성전에완전하고일관성있는요구사항으로정리하는활동 요구사항분석의기준 - 시스템을계층적이고구조적으로표현하여야한다. - 외부사용자와의인터페이스및내부시스템구성요소간의인터페이스를정확히분석하여야한다. - 분석단계이후의설계와구현단계에필요한정보를제공하여야한다. 12

13 요구사항분석 (2/2) 요구사항분석기법의종류 - 구조적분석 (Structured Analysis) 시스템의기능을중심으로구조적분석을실행 시스템의기능을정의하기위해서프로세스들을도출하고, 도출된프로세스간의데이터흐름을정의 - 객체지향분석 요구사항을사용자중심의시나리오분석을통해유스케이스모델 (Usecase Model) 로구축하는것 요구사항을추출하고, 유스케이스의실체화 (Realization) 과정을통해추출된요구사항을분석 13

14 요구사항명세 (1/4) 의미 - 분석된요구사항을명확하고완전하게기록하는것 - 소프트웨어시스템이수행하여야할모든기능과시스템에관련된구현상의제약조건및개발자와사용자가합의한성능에관한사항등을명세 최종결과물 - 요구사항명세서 (SRS: Software Requirement Specification) 14

15 요구사항명세 (2/4) 요구사항명세서 (SRS: Software Requirement Specification) - 프로젝트산출물중가장중요한문서 - 사용자, 분석가, 개발자및테스터모두에게공동의목표를제시 - 시스템이어떻게수행될것인가가아닌무엇을수행할것인가에대한기술 시스템이이루어야할목표를기술하지만목표를달성하기위한해결방법은기술하지않는다. 15

16 IEEE-Std-830 명세표준 요구사항명세 (3/4) 1. 소개 (Introduction) 1.1 SRS의목적 (Purpose of SRS) 1.2 산출물의범위 (Scope of product) 1.3 정의, 두문자어, 약어 (Definitions, acronyms and Abbreviations) 1.4 참조문서 (References) 1.5 SRS 개요 (Overview of rest of SRS) 2. 일반적인기술사항 (General Description) 2.1 제품의관점 (Product Perspective) 2.2 제품의기능 (Product Functions) 2.3 사용자특성 (User Characteristics) 2.4 제약사항 (Constraints) 2.5 가정및의존성 (Assumptions and Dependencies) 상세한요구사항 (Specific requirements) 3.1 기능적요구사항 (Functional requirements) 기능적요구사항1 (Functional requirements 1) 개요 입력물 프로세싱 (Processing) 산출물 (Outputs) 수행요구사항 (Performance requirements) 디자인제약사항 (Design constraints) 속성 (Attributes) 기타요구사항 (Other requirements) 외부적인인터페이스요구사항 (External interface requirements) 사용자인터페이스 (User Interface) 하드웨어인터페이스 (Hardware interface) 소프트웨어인터페이스 (Software interface) 커뮤니케이션인터페이스 (Communications interface) 부록 (Appendices) 인덱스 (Index)

17 요구사항명세 (4/4) 요구사항명세서를작성하기위한명세원리 - 시스템이수행할모든기능과시스템에영향을미치는제약조건을명확하게기술 - 명세내용은고객과개발자사이에서모두가이해하기쉽고간결하게작성 - 기술된모든요구사항은검증이가능하기때문에원하는시스템의품질, 상대적중요도, 품질의측정및검증방법및기준등을명시 - 요구사항명세서는시스템의외부행위를기술하는것으로, 특정한구조나알고리즘을사용하여설계하지않도록함 - 참여자들이시스템의기능을이해하거나, 변경에대한영향분석등을위하여계층적으로구성 - 요구사항을쉽게참조할수있도록고유의식별자를가지고번호화하고, 모든요구사항이동등한것이아니기때문에요구사항을우선순위화 17

18 요구사항검증 (1/5) 개요 - 사용자요구가요구사항명세서에올바르게기술되었는가에대해검토하는활동 검증내용 - 요구사항이사용자나고객의목적을완전하게기술하는가? - 요구사항명세가문서표준을따르고, 설계단계의기초로적합한가? - 요구사항명세의내부적일치성과완정성이있는가? - 기술된요구사항이참여자의기대에일치하는가? 18

19 요구사항검증 (2/5) 요구사항타당성검증 - 검증활동 명세된요구사항의구현가능성검증 명세표현의정확성및완전성검증 표준과의일치성검증 요구사항간의충돌검증 기술적결함에대한검증 - 검증목적 시스템요구사항이설계기준에따라하드웨어형상항목, 소프트웨어형상항목등에적절하게할당되었는지검증 안전, 보안, 및위험성과관련된소프트웨어요구사항이정확한지검증 19

20 요구사항검증 (2/5) 요구사항타당성검증사항 검증사항 무결성 (correctness) 과 완전성 (completeness) 설명 사용자의요구를에러없이완전하게반영하고있는가? 일관성 (consistency) 요구사항이서로간에모순되지않는가? 20 명확성 (unambiguous) 기능성 (functional) 검증가능성 (verifiable) 추적가능성 (traceable) 및변경용이성 요구분석의내용이모호함없이모든참여자들에의해명확하게이해될수있는가? 요구사항명세서가 어떻게 보다 무엇을 에관점을두고기술되었는가? 요구사항명세서에기술된내용이사용자의요구를만족하는가? 개발된시스템이요구사항분석내용과일치하는지를검증할수있는가? 시스템요구사항과시스템설계문서를추적할수있는가?

21 요구사항검증 (3/5) 요구사항명세구조검증 - 개요 정의된요구사항들로부터구현되는시스템이사용자의요구와목표를만족하는가에대해확인하는활동 - 검증항목 각단계별명세요건들이완전하고정확하게명세되었는가 요구명세서가내부적으로일관성을가지고있는가 - 목적 요구사항들간의정확성과완전성및일치성을확립 21

22 요구사항검증 (4/5) 요구사항공통어휘검증 - 개요 요구사항추출단계에서나온공통용어에대하여외부사용자또는고객과검증 22

23 23 유스케이스기반의요구사항분석

24 요구사항분석 의미 - 요구사항명세서작성의기반을다지는작업 요구사항분석방법 - 객체지향방법인유스케이스기반분석 유스케이스모델링기술서작성기능, 비기능분류요구사항명세서작성 24

25 UML 의역사 다양한객체모델링방법론공존 1993 년이전 Booch (by Booch) OMT (by Rumbaugh) OOSE (by Jacobson) 1995 년 Booch + Rumbaugh + Jacobson 모델링기법통일 1997 년 9 월 UML 1.1 발표, OMG(Object Management Group) 가표준으로채택 2004 년 UML 2.0 발표 2007 년 2007 년현재, UML 2.0 사용됨 25

26 통합된표준모델링언어, UML UML 의표기법 (notation) 만알고있다면프로젝트이해관계자간의의사소통의불일치를지적할수있다! 26

27 시스템구축시 UML 의역할 가시화 시스템 UML S/W 청사진작성표준언어 명세화구축문서화 27

28 유스케이스다이어그램 (1/2) 개요 - 사용자의관점에서시스템의서비스혹은기능및그와관련한외부요소를보여주는다이어그램 - 고객과개발자가함께보며요구사항에대한의견을조율할수있음 28

29 유스케이스다이어그램의구성요소 시스템 (System) 액터 (Actor) 소비자 <<subsystem>> 음료수자동판매기시스템 음료수를산다 음료수의재고를채운다 관계 (Association) 수금자 판매기의돈을수금한다 관리자 유스케이스 (Usecase) 29

30 시스템 (System) 의미 - 만들고자하는시스템의범위 표기법 - 유스케이스나액터를둘러싼사각형의틀을그리고, 시스템이나모델의명칭을사각형 안쪽상단에기술 - 서브시스템일경우 <<subsystem>> 이라기술하고모델 ( 액터, 유스케이스 ) 의단위일경우에 <<usecasemodel>> 이라고기술한다 <<subsystem>> 서브시스템명칭 <<subsystem>> 음료수자동판매기시스템 < 시스템의표현방법 > < 예시 > 30

31 액터 (Actor) 의미 - 시스템의외부에있으면서시스템과상호작용을하는사람또는다른시스템 표기법 - 원과선을조합하여사람모양으로표현 - 그위또는아래에액터명표시 - 액터명은액터의역할로정함 액터명 소비자 < 액터의표현방법 > < 예시 > 31

32 유스케이스 (Usecase) 의미 - 시스템이액터에게제공해야하는기능의집합 - 시스템의요구사항을보여줌 표기법 - 타원으로표시하고그안쪽이나아래쪽에유스케이스명을기술 - 유스케이스의이름은 ~ 한다 와같이동사로표현 - 각유스케이스가개발될기능하나와연결될수있도록한다. 유스케이스명 자판기에서돈을수금한다 < 유스케이스의표현방법 > < 예시 > 32

33 관계 (Relationship) (1/3) 의미 - 액터와유스케이스사이의의미있는관계 종류 - 연관관계 (Association) - 의존관계 포함관계 (include) 확장관계 (extend) - 일반화관계 (generalization) 33

34 관계 (2/3) 관계종류설명표기법 유스케이스와액터간의상호작용이있음 유스케이스명 연관관계 을표현 액터명 유스케이스와액터를실선으로연결함 음료수를산다 소비자 유스케이스가다른유스케이스를포함하 는경우 포함관계 포함되는유스케이스는포함하는유스케이스를실행하기위해반드시실행되어야 기능을포함하는유스케이스 <<include>> 기능에포함되는유스케이스 (include) 하는유스케이스 포함하는쪽에서포함되는쪽으로점선 돈을수금한다 <<include>> 자판기를연다 으로된화살표를그리고, <<include>> 라 는표시한다. 34

35 관계 (3/3) 관계종류설명표기법 어떠한유스케이스로부터다른유스케이 스가특정조건에서생성되는경우 확장기능유스케이스는특정조건이나 확장대상유스케이스 <<extend>> 확장기능유스케이스 확장관계 (extend) 액터의선택에따라발생 확장된기능을가지는유스케이스에서 음료수를산다 <<extend>> 자판기에돈을투입한다 확장대상이되는원래의기능을가진유 스케이스쪽으로점선화살표를그리고, <<extend>> 라고함께표시한다. 추상적인유스케이스 구체적인유스케이스 일반화관계 (generalization) 액터나유스케이스가구체화된다른여러액터나유스케이스로구성될경우 구체적인유스케이스로부터추상적인유스케이스쪽으로속이비어있는삼각형모 돈을투입한다 동전을투입한다 지폐를투입한다 양으로된실선화살표를그려표현한다. 35

36 단순화된유스케이스다이어그램의예 <<subsystem>> 음료수자동판매기시스템 음료수를산다 소비자 음료수의재고를채운다 판매기의돈을수금한다 관리자 수금자 36

37 유스케이스다이어그램작성순서 액터식별유스케이스식별 관계정의 소비자 음료수를산다 <<include>> <<extends>> - 사용자식별 - 외부시스템식별 - 액터가요구하는서비스식별 - 액터가요구하는정보식별 - 액터가시스템과상호작용하는행위식별 - 액터와유스케이스간의연관관계정의 - 유스케이스간포함, 확장관계정의 - 액터간, 유스케이스간의일반화정의 37

38 액터식별 액터를찾기위한질문들 - 누가정보를제공하고, 사용하고, 삭제하는가? - 누가또는어떤조직에서개발될시스템을사용할것인가? - 누가요구사항에대해관심을가지고, 시스템이만들어낸결과에관심이있는가? - 누가시스템이잘운영될수있도록유지보수및관리를하는가? - 개발될시스템과상호작용하는하드웨어나소프트웨어시스템은무엇인가? 38

39 유스케이스식별 유스케이스를찾기위한질문들 - 액터가원하는시스템제공기능은무엇인가? - 액터는시스템에어떤정보를생성, 수정, 조회, 삭제하고싶어하는가? - 액터는시스템의갑작스러운외부변화에대해어떤정보를필요로하는가? - 시스템이어떤기능을제공하면액터의일상작업이효율적이고편리해지는가? - 모든기능요구사항들을만족할수있도록유스케이스가모두식별되었는가? 39

40 관계를식별하기위한질문 연관관계 (Association) - 액터와유스케이스간에상호작용이존재하는가? 포함관계 (Include) - 이유스케이스를실행하기위하여반드시실행되어야하는유스케이스가존재하는가? 확장관계 (Extend) - 이유스케이스를실행하기위하여기존유스케이스를참조하는가? 일반화관계 (generalization) - 액터또는유스케이스가구체화된다른여러액터나유스케이스를가지고있는가? 40

41 유스케이스다이어그램의예 (1/6) 예제요구사항 - SE 사는 K 고객으로부터다음의요구사항을전달받았다. - 음료수자동판매기시스템을만드시오. SE사는 K고객의요구사항을 Usecase Diagram 으로모델링하기로한다. 음료수자동판매기 41

42 유스케이스다이어그램의예 (2/6) 시스템식별 - 요구사항을통해만들고자하는시스템은 음료수자동판매기시스템 <<subsystem>> 음료수자동판매기시스템 42

43 유스케이스다이어그램의예 (3/6) 액터식별 - 음료수자동판매기 ( 시스템 ) 외부에서상호작용하는액터는소비자, 관리자, 수금원으로식별할수있다. <<subsystem>> 음료수자동판매기시스템 소비자 수금자 관리자 43

44 유스케이스다이어그램의예 (4/6) 유스케이스식별 음료수를산다 동전을투입한다 지폐를투입한다 음료수를선택한다 소비자 자판기를연다 부족한음료수를채워넣는다 자판기를닫는다 관리자 수금자 자판기를연다 판매기의돈을수금한다 자판기를닫는다 44

45 유스케이스다이어그램의예 (5/6) 관계정의 음료수를산다 <<extend>> 돈을투입한다 소비자 음료수를꺼낸다 지폐를투입한다 동전을투입한다 부족한음료수를채워넣는다 판매기를연다 자판기의돈을수금한다 판매기를연다 관리자 판매기를닫는다 수금자 판매기를닫는다 45

46 유스케이스다이어그램의예 (6/6) 완성된유스케이스다이어그램의예제 <<subsystem>> 음료수자동판매기시스템 음료수를산다 <<extend>> 돈을투입한다 소비자 음료수를꺼낸다 지폐를투입한다 동전을투입한다 부족한음료수를채워넣는다 판매기를연다 관리자 판매기를닫는다 자판기의돈을수금한다 판매기를연다 수금자 판매기를닫는다 46

47 유스케이스기술서작성 (1/3) 개요 - 유스케이스다이어그램을보완하기위한산출물 - 유스케이스다이어그램과의차이 유스케이스다이어그램 : 유스케이스는시스템의기능을표현하는것 유스케이스기술서 : 각각의유스케이스에대해서해당유스케이스가어떻게수행되는지를표현하는수단 47

48 유스케이스기술서작성 (2/3) 유스케이스기술서항목 유스케이스명 액터명 유스케이스개요및설명 사전및사후조건 작업흐름 - 정상흐름 (Normal Flow): 해당유스케이스가정상적으로수행되는흐름을표현하는절차 - 대치흐름 (Alternative Flow): 유스케이스내의작업흐름이수행되는중에특정시점에서여러가지선택적인흐름으로나뉘어질경우에발행하는흐름 - 예외흐름 (Exceptional Flow): 유스케이스내의작업흐름이수행되는중에발생할수있는예외상황이나오류를표현하는흐름 시나리오 : 각시나리오는유스케이스의특정한예를나타냄 48

49 유스케이스기술서작성 (3/3) 유스케이스기술서예제 유스케이스기술서예제 유스케이스명 : 음료수보충 액터명 : 관리자 유스케이스개요및설명 - 음료수관리자는 2 주마다음료수자동판매기의부족한음료수를보충한다. 사전조건 : 마지막으로음료수를보충한지 2 주가지났다. 작업흐름 - 정상흐름 1. 유스케이스는 2주마다시작한다. 2. 관리자는음료수자동판매기를연다. 3. 부족한음료수를보충한다. 5. 관리자는음료수자동판매기를닫고유스케이스는종료된다. 사후조건 : 음료수자동판매기에부족한음료수가보충되었다. 49

50 연습문제 1. 요구사항을정확하게명세하는이유는무엇인가? 2. 기능적요구사항과비기능적요구사항의차이점을나열하라. 3. 요구사항개발단계를나타내어라. 4. 요구사항명세서 (SRS: Software Requirement Specification) 란무엇인가? 5. 유스케이스다이어그램을작성하는이유는무엇인가? 6. 유스케이스다이어그램을표현하는절차를설명하라. 50

51 팀프로젝트 5 주차 51

52 이번주할일 각팀별로작성된제안서를발표한다. ( 각 10 분씩 ) 52

53 다음주제출문서 요구사항명세서를작성하여제출한다. 53

1. 파일 명명규칙

1. 파일 명명규칙 소프트웨어 공학 UML 과제 [UseCase Diagram] Use Case Diagram [ 목 차 ] 2.1.Use Case Diagram 개요 2.2.Use Case 구성요소 2.3.Relationship 2.4.작성방법 2.5.참고문헌 1. Use Case Diagram 1.1 Use Case 모델링 개요 - Use Case 는 개발자가 아닌 사용자