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




요구사항의 기본 개념 이해
유스케이스 다이어그램 이해 및 작성
품질 속성의 이해
요구사항의 문서화

3. Requirements
f
Section 1
Requirements Overview

4. Requirements
Requirements Overview

5. Requirements
Requirements Overview (cont.)

6. Requirements
Section 2.
Software Requirements

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
 구현되어야 하는 것에 대한 명세
 시스템의 동작 방식 및 속성/특성에 대한 설명

9. Requirements
Kinds 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?

15. Requirements
Section 3.
System Envisioning

16. Requirements
Contents





Activity Overview
Concepts and Notations
Steps
Example
Exercise

17. Requirements
Activity Overview

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

27. Requirements
Activity Overview

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
 일반적 요소와 특수한 요소 사이의 관계
 공통적 특징을 가지는 액터와 유스케이스를 일반화하기 위
해 사용

42. Requirements
Generalization (cont.)
 액터(Actor) 일반화의 예

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. 비전에 따라 우선 순위 부여

50. Requirements
Example

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

54. Requirements
Activity Overview

55. Requirements
Kinds of Non-functional Requirements
 품질 속성(Quality Attributes)
• 일반적인 시스템 품질에 관한 요구사항
 비즈니스 규칙(Business Rules)
• 업무를 수행하는 규칙
 제약사항(Constraints)
• 프로젝트에 관한 여러 가지 제약사항들

56. Requirements
Quality Attributes







Performance
Usability
Reliability
Security
Extensibility
Maintainability
…

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)로 문서화하는 것이 좋다.