StarUML NS Guide - Requirements
- 1. Requirements Sections 1. Requirements Overview 2. Software Requirements 3. System Envisioning 4. Use Case Modeling 5. Specifying Supplementary Requirements 6. Software Requirements Specification
- 2. Requirements Lecture Objectives 요구사항의 기본 개념 이해 유스케이스 다이어그램 이해 및 작성 품질 속성의 이해 요구사항의 문서화
- 7. Requirements Contents Definition of Requirements Kind of Requirements Business Requirements Functional Requirements Non-functional Requirements How Are Requirements Specified Why Are Requirements Important?
- 8. Requirements Definition of Requirements 구현되어야 하는 것에 대한 명세 시스템의 동작 방식 및 속성/특성에 대한 설명
- 10. Requirements Business Requirements 고객 혹은 조직의 고차원적인 목적을 포함 시스템을 구축하려는 이유 시스템 고유의 특징을 포함 고급 매니저, 마케팅 부서 등에서 작성
- 11. Requirements Functional Requirements 시스템이 사용자에게 제공해야 하는 기능 주로 유스케이스(Use Case)의 형태로 표현
- 12. Requirements Non-functional Requirements 시스템 기능 이외의 요구사항들 시스템의 품질에 관한 속성(Quality Attributes) 비즈니스 규칙(Business Rules) 제약 조건(Constraints)
- 13. Requirements How Are Requirements Specified
- 14. Requirements Why Are Requirements Important?
- 16. Requirements Contents Activity Overview Concepts and Notations Steps Example Exercise
- 18. Requirements Concepts and Notations What Is Vision? Why Is Vision Important? Vision Document
- 19. Requirements What Is Vision? 시스템이 무엇을 위한 것인가? 시스템을 개발하려는 궁극적 목적은 무엇인가? 어떤 시스템이 될 것인가?
- 20. Requirements Why Is Vision Important? 궁극적으로 달성하고자 하는 목적을 이해 의도에 벗어난 시스템 개발을 미연에 방지 상업적 제품인 경우 마케팅과 연계 요구사항의 우선순위 부여의 기준
- 21. Requirements Vision Document Table of Contents 1. Introduction 2. Vision Statement 1. Background 2. Objective 3. Major Features
- 22. Requirements Steps (System Envisioning) 1. 시스템 개발의 배경을 이해 2. 시스템 개발 목적을 파악 3. 비즈니스 수준의 시스템 특징들을 묘사
- 23. Requirements Example Vision • Background • 사내에 준비되어 있는 회의실의 사용을 함에 있어서, 어떤 회의실이 직접 방문하지 않고서는, 현재 사용되지 않고 있는지는 확인 불가능합니다. 이와 더불어서 각 회 의실에 비치되어 있는 장비와 수용인원이 확인 되지 않아, 잘못된 회의실을 찾아 가는 경우도 발생하게 됩니다. 이를 보안하기 위해, 각각의 회의실에 대한 정보를 관리하고, 예약 시스템을 갖추어 사원들이 회의실을 원활히 사용할 수 있도록 하기 위해 시스템을 구축하고자 한다 • Objectives • 사내에 존재하는 회의실 사용을 원활히 하기 위하여 시스템을 도입한다. 사원은 회 의실에 대한 모든 정보를 조회함으로써, 회의에 가장 잘 맞는 회의실을 선택할 수 있도록 한다.
- 24. Requirements Exercise Write Vision document for your system Write Glossary document for your system
- 25. Requirements Section 4. Use Case Modeling
- 26. Requirements Contents Activity Overview Concepts and Notations Steps Example Exercise
- 28. Requirements Concepts and Notations Use Case Diagram Concepts Use Case Modeling • • • • • • • • • Use Case Diagram Actor Use Case Association Navigability Generalization Include Extend Package Related • CRUD (Create, Read, Update, Delete) • Benefits of Use Case • Bad Practices
- 29. Requirements Use Case Diagram 시스템 혹은 서브시스템의 행동을 표현하기 위해 사용
- 30. Requirements Actor 시스템 외부에 존재 시스템과 상호작용하는 모든 것 • 사람 • 외부 시스템 • 하드웨어 장치 등
- 31. Requirements Use Case 시스템이 제공하는 가시적 기능 액터와 시스템간 상호작용의 추상화
- 32. Requirements Use Case (cont.) 유스케이스 리포트(Use Case Report) • 유스케이스의 내용을 상세히 기술한 보고서 • 주요 내용 • 트리거 조건(Trigger) • 선/후-조건 (Pre-Conditions and Post-Conditions) • 이벤트 흐름(Flow of Events) • 확장점(Extension Points) • 특별한 요구사항(Special Requirements)
- 33. Requirements Use Case (cont.) 유스케이스 리포트 양식 예
- 34. Requirements Use Case (cont.) 이벤트 흐름(Flow of Events) • 유스케이스가 수행되어지는 과정을 이벤트의 흐름으로 기술하는 것 이벤트 흐름의 종류 • Basic Flow • Alternative Flow • Exceptional Flow
- 35. Requirements Use Case (cont.) 시나리오(Scenario) • 유스케이스에 대한 하나의 인스턴스 • 이벤트의 흐름은 모든 가능한 시나리오를 기술한 것
- 36. Requirements Use Case (cont.) 트리거(Trigger) • 언제 유스케이스가 시작되는가? 선-조건(Pre-Conditions) • 유스케이스가 시작되기 전에 만족해야 할 조건 후-조건(Post-Conditions) • 유스케이스가 종료하고 난 후에 만족해야 할 조건 확장점(Extension Points) • 확장되어지는 부분을 기술 특별한 요구사항(Special Requirements) • 관계된 비-기능적 요구사항들을 기술
- 37. Requirements Use Case (cont.) 이벤트 흐름을 구성하기 • Basic Flow (1개) • 여러 개의 Subflow로 분할 하여 구성 가능 • Alternative Flows (여러 개) • Exceptional Flows (여러 개) • Alternative Flows로 편입시켜 함께 구성 가능
- 38. Requirements Use Case (cont.) 이벤트 흐름을 기술하기 • 이벤트 단위로 한번에 한 스텝씩 기술 • 다음과 같은 스타일을 따르는 것이 좋음 1. “(액터)가 (무엇)을 한다” 2. “(시스템)이 (무엇)을 한다.” 3. “(액터)가 (무엇)을 한다” 4. “(시스템)이 (무엇)을 한다.” 5. … • 데이터 관련 항목들도 함께 표현하는 것이 좋음
- 39. Requirements Association 액터와 유스케이스 사이의 연관 시스템과 외부 액터와의 대화를 표현
- 40. Requirements Navigability 연관(Association)의 양쪽 끝 부분에 설정 접근 가능성을 표현 액터와 시스템의 상호작용 방향을 표현
- 41. Requirements Generalization 일반적 요소와 특수한 요소 사이의 관계 공통적 특징을 가지는 액터와 유스케이스를 일반화하기 위 해 사용
- 43. Requirements Include 다른 유스케이스의 내용을 포함 유스케이스들 간의 공통적 흐름을 공유
- 44. Requirements Extend 유스케이스의 흐름을 확장 확장점(Extension Point)에서부터 확장
- 45. Requirements Package 요소들을 그룹화하기 위해 사용 유스케이스 모델을 구조화 • 액터별, 유스케이스별로 그룹화 • 관련된 업무별로 액터와 유스케이스들을 그룹화
- 46. Requirements CRUD (Create, Read, Update, Delete) 특정 정보에 대한 생성, 읽기, 변경, 삭제 기능 • 하나의 유스케이스로 표현 • CRUD에 목록 보기(List)도 포함 가능 • 각각은 부흐름(Subflow) 혹은 대안흐름(Alternative Flow)으로 기술
- 47. Requirements Benefits of Use Case 사용자 중심적이다. 고객이 이해하기 쉽다. 과도한 요구사항 양산을 절제할 수 있다. 이벤트 흐름 기술을 통해 기능 누락을 예방한다.
- 48. Requirements Bad Practices 너무 많은 유스케이스 너무 복잡한 이벤트 흐름 사용자 인터페이스를 가정한 이벤트 흐름 기술 과도한 포함(Include) 및 확장(Extend) 사용
- 49. Requirements Steps (Use Case Modeling) 1. 유스케이스 다이어그램 생성 2. 시스템 외부의 액터들 발견 3. 각각의 유스케이스에 대해 1. 관련된 유스케이스들을 식별 2. 각각의 유스케이스에 대한 리포트 작성 4. 유스케이스 모델을 구조화 5. 비전에 따라 우선 순위 부여
- 51. Requirements Exercise Draw an Use-Case Diagram for your system. Write Use-Case Reports for each use case.
- 52. Requirements Section 5. Specifying Supplementary Requirements
- 53. Requirements Contents Activity Overview Concepts and Notations Steps Example Exercise
- 55. Requirements Kinds of Non-functional Requirements 품질 속성(Quality Attributes) • 일반적인 시스템 품질에 관한 요구사항 비즈니스 규칙(Business Rules) • 업무를 수행하는 규칙 제약사항(Constraints) • 프로젝트에 관한 여러 가지 제약사항들
- 57. Requirements Quality Attributes (cont.) Kinds of Quality Attributes • • • • Runtime Quality Non-runtime Quality Business Quality Architectural Quality
- 58. Requirements Quality Attributes (cont.) Tradeoffs
- 59. Requirements Steps (Specifying Supplementary Requirements) • • • • 시스템에 요구되어지는 품질 속성을 파악 비즈니스 규칙 및 제약사항들을 파악 비전에 따라 우선 순위 부여 Supplementary Requirements 문서 작성
- 60. Requirements Example Functionality Usability Reliability Performance Security • 여러 명의 사용자가 동시에 사용할 수 있어야 한다 • 관리자가 회의실 예약에 대하여 승인 또는 불허 했을 시에는 반드시 예약 신청자에게 알려주어야 한다 • 기본 클라이언트 표준은 Windows 기반의 Internet Explorer 5.0 이상으로 한다. 그러나 모든 웹 브라우저에 서 사용할 수 있어야 한다. • 일주일에 월요일 새벽 2시부터 3시사이의 백업 시간을 제외하고는 이용이 가능해야 한다 • 기존 시스템과의 대화에서 10초 이하로 설정하고, 대화 시간을 초과할 경우 관리자에게 알린다 • 최초 사용자 인증 시에 인증 과정 정보를 저장하고, 이 저장된 정보를 활용하여 사용자의 권한을 할당한다.
- 61. Requirements Exercise Define quality attributes related to your system.
- 62. Requirements Section 6. Software Requirements Specification (SRS)
- 63. Requirements Contents SRS Overview SRS Contents Exercise
- 64. Requirements SRS Overview SRS (Software Requirements Specification) 소프트웨어 시스템에 대한 요구사항을 총체적으로 명세화 한 문서 IEEE Std 830
- 65. Requirements SRS Contents Table of Contents • Introduction • Overall Description • Use Case Model Survey • Constraints • Specific Requirements • Use Case Reports • Supplementary Requirements
- 66. Requirements Exercise Write a SRS using Use-Case Model, Use-Case Reports and Supplementary Requirements Document.
- 67. Requirements Lecture Summary 소프트웨어 요구사항에는 비즈니스, 기능적, 비기능적 요구 사항의 여러 분류가 존재하며 각기 다른 중요성을 가진다. 유스케이스 모델은 시스템의 기능적 요구사항들을 반영한 다. 품질 속성은 시스템의 비기능적 요구사항들을 반영한다. 시스템에 요구되어지는 요구사항들은 총체적으로 소프트 웨어 요구사항 명세서(SRS)로 문서화하는 것이 좋다.