staruml ns guide - requirements

Sections

Requirements

Chap-ter 4.

1. Requirements Overview

2. Software Requirements

3. System Envisioning

4. Use Case Modeling

5. Specifying Supplementary Requirements

6. Software Requirements Specification

Lecture Objectives

Requirements Chap-ter 4

요구사항의 기본 개념 이해 유스케이스 다이어그램 이해 및 작성 품질 속성의 이해 요구사항의 문서화

Requirements

f

Chap-ter 4

Requirements Overview

Section 1

Requirements Overview


Requirements Overview (cont.)



Software Requirements

Section 2.

Contents


Definition of Requirements Kind of Requirements Business Requirements Functional Requirements Non-functional Requirements How Are Requirements Specified Why Are Requirements Important?

Definition of Requirements


구현되어야 하는 것에 대한 명세 시스템의 동작 방식 및 속성 / 특성에 대한 설명

Kinds of Requirements


Business Requirements


고객 혹은 조직의 고차원적인 목적을 포함 시스템을 구축하려는 이유 시스템 고유의 특징을 포함 고급 매니저 , 마케팅 부서 등에서 작성

Functional Requirements


시스템이 사용자에게 제공해야 하는 기능 주로 유스케이스 (Use Case) 의 형태로 표현

Non-functional Requirements


시스템 기능 이외의 요구사항들 시스템의 품질에 관한 속성 (Quality Attributes) 비즈니스 규칙 (Business Rules) 제약 조건 (Constraints)

How Are Requirements Specified


Why Are Requirements Important?



System Envisioning

Section 3.

Contents


Activity Overview Concepts and Notations Steps Example Exercise

Activity Overview


Concepts and Notations


What Is Vision? Why Is Vision Important? Vision Document

What Is Vision?


시스템이 무엇을 위한 것인가 ? 시스템을 개발하려는 궁극적 목적은 무엇인가 ? 어떤 시스템이 될 것인가 ?

Why Is Vision Important?


궁극적으로 달성하고자 하는 목적을 이해 의도에 벗어난 시스템 개발을 미연에 방지 상업적 제품인 경우 마케팅과 연계 요구사항의 우선순위 부여의 기준

Vision Document


Table of Contents1. Introduction2. Vision Statement

1. Background2. Objective3. Major Features

Steps (System Envisioning)


1. 시스템 개발의 배경을 이해2. 시스템 개발 목적을 파악3. 비즈니스 수준의 시스템 특징들을 묘사

Example


Vision• Background

• 사내에 준비되어 있는 회의실의 사용을 함에 있어서 , 어떤 회의실이 직접 방문하지 않고서는 , 현재 사용되지 않고 있는지는 확인 불가능합니다 . 이와 더불어서 각 회의실에 비치되어 있는 장비와 수용인원이 확인 되지 않아 , 잘못된 회의실을 찾아 가는 경우도 발생하게 됩니다 . 이를 보안하기 위해 , 각각의 회의실에 대한 정보를 관리하고 , 예약 시스템을 갖추어 사원들이 회의실을 원활히 사용할 수 있도록 하기 위해 시스템을 구축하고자 한다

• Objectives• 사내에 존재하는 회의실 사용을 원활히 하기 위하여 시스템을 도입한다 . 사원은

회의실에 대한 모든 정보를 조회함으로써 , 회의에 가장 잘 맞는 회의실을 선택할 수 있도록 한다 .

Exercise


Write Vision document for your system Write Glossary document for your system


Use Case Modeling

Section 4.

Contents



Activity Overview


Concepts and Notations


Use Case Diagram Con-cepts• Use Case Diagram• Actor• Use Case• Association• Navigability• Generalization• Include• Extend• Package

Use Case Modeling Re-lated• CRUD (Create, Read, Up-

date, Delete)• Benefits of Use Case• Bad Practices

Use Case Diagram


시스템 혹은 서브시스템의 행동을 표현하기 위해 사용

Actor


시스템 외부에 존재 시스템과 상호작용하는 모든 것

• 사람• 외부 시스템• 하드웨어 장치 등

Use Case


시스템이 제공하는 가시적 기능 액터와 시스템간 상호작용의 추상화

Use Case (cont.)


유스케이스 리포트 (Use Case Report)• 유스케이스의 내용을 상세히 기술한 보고서• 주요 내용

• 트리거 조건 (Trigger)• 선 / 후 - 조건 (Pre-Conditions and Post-Conditions)• 이벤트 흐름 (Flow of Events)• 확장점 (Extension Points)• 특별한 요구사항 (Special Requirements)

Use Case (cont.)


유스케이스 리포트 양식 예

Use Case (cont.)


이벤트 흐름 (Flow of Events)• 유스케이스가 수행되어지는 과정을

이벤트의 흐름으로 기술하는 것

이벤트 흐름의 종류• Basic Flow• Alternative Flow• Exceptional Flow

Use Case (cont.)


시나리오 (Scenario)• 유스케이스에 대한 하나의 인스턴스• 이벤트의 흐름은 모든 가능한 시나리오를 기술한 것

Use Case (cont.)


트리거 (Trigger)• 언제 유스케이스가 시작되는가 ?

선 - 조건 (Pre-Conditions)• 유스케이스가 시작되기 전에 만족해야 할 조건

후 - 조건 (Post-Conditions)• 유스케이스가 종료하고 난 후에 만족해야 할 조건

확장점 (Extension Points)• 확장되어지는 부분을 기술

특별한 요구사항 (Special Requirements)• 관계된 비 - 기능적 요구사항들을 기술

Use Case (cont.)


이벤트 흐름을 구성하기• Basic Flow (1 개 )

• 여러 개의 Subflow 로 분할 하여 구성 가능• Alternative Flows ( 여러 개 )• Exceptional Flows ( 여러 개 )

• Alternative Flows 로 편입시켜 함께 구성 가능

Use Case (cont.)


이벤트 흐름을 기술하기• 이벤트 단위로 한번에 한 스텝씩 기술• 다음과 같은 스타일을 따르는 것이 좋음

1. “( 액터 ) 가 ( 무엇 ) 을 한다”2. “( 시스템 ) 이 ( 무엇 ) 을 한다 .”3. “( 액터 ) 가 ( 무엇 ) 을 한다”4. “( 시스템 ) 이 ( 무엇 ) 을 한다 .”5. …

• 데이터 관련 항목들도 함께 표현하는 것이 좋음

Association


액터와 유스케이스 사이의 연관 시스템과 외부 액터와의 대화를 표현

Navigability


연관 (Association) 의 양쪽 끝 부분에 설정 접근 가능성을 표현 액터와 시스템의 상호작용 방향을 표현

Generalization


일반적 요소와 특수한 요소 사이의 관계 공통적 특징을 가지는 액터와 유스케이스를 일반화하기

위해 사용

Generalization (cont.)


액터 (Actor) 일반화의 예

Include


다른 유스케이스의 내용을 포함 유스케이스들 간의 공통적 흐름을 공유

Extend


유스케이스의 흐름을 확장 확장점 (Extension Point) 에서부터 확장

Package


요소들을 그룹화하기 위해 사용 유스케이스 모델을 구조화

• 액터별 , 유스케이스별로 그룹화• 관련된 업무별로 액터와 유스케이스들을 그룹화

CRUD (Create, Read, Update, Delete)


특정 정보에 대한 생성 , 읽기 , 변경 , 삭제 기능• 하나의 유스케이스로 표현• CRUD 에 목록 보기 (List) 도 포함 가능• 각각은 부흐름 (Subflow) 혹은 대안흐름 (Alternative Flow) 으로 기술

Benefits of Use Case


사용자 중심적이다 . 고객이 이해하기 쉽다 . 과도한 요구사항 양산을 절제할 수 있다 . 이벤트 흐름 기술을 통해 기능 누락을 예방한다 .

Bad Practices


너무 많은 유스케이스 너무 복잡한 이벤트 흐름 사용자 인터페이스를 가정한 이벤트 흐름 기술 과도한 포함 (Include) 및 확장 (Extend) 사용

Steps (Use Case Modeling)


1. 유스케이스 다이어그램 생성2. 시스템 외부의 액터들 발견3. 각각의 유스케이스에 대해

1. 관련된 유스케이스들을 식별2. 각각의 유스케이스에 대한 리포트 작성

4. 유스케이스 모델을 구조화5. 비전에 따라 우선 순위 부여

Example


Exercise


Draw an Use-Case Diagram for your system. Write Use-Case Reports for each use case.


Specifying Supplementary Require-ments

Section 5.

Contents



Activity Overview


Kinds of Non-functional Requirements


품질 속성 (Quality Attributes)• 일반적인 시스템 품질에 관한 요구사항

비즈니스 규칙 (Business Rules)• 업무를 수행하는 규칙

제약사항 (Constraints)• 프로젝트에 관한 여러 가지 제약사항들

Quality Attributes


Performance Usability Reliability Security Extensibility Maintainability …

Quality Attributes (cont.)


Kinds of Quality Attributes• Runtime Quality• Non-runtime Quality• Business Quality• Architectural Quality

Quality Attributes (cont.)


Tradeoffs

Steps


(Specifying Supplementary Requirements) • 시스템에 요구되어지는 품질 속성을 파악• 비즈니스 규칙 및 제약사항들을 파악• 비전에 따라 우선 순위 부여• Supplementary Requirements 문서 작성

Example


Functionality• 여러 명의 사용자가 동시에 사용할 수 있어야 한다• 관리자가 회의실 예약에 대하여 승인 또는 불허 했을 시에는 반드시 예약 신청자에게 알려주어야 한다

Usability• 기본 클라이언트 표준은 Windows 기반의 Internet Explorer 5.0 이상으로 한다 . 그러나 모든 웹

브라우저에서 사용할 수 있어야 한다 .

Reliability• 일주일에 월요일 새벽 2 시부터 3 시사이의 백업 시간을 제외하고는 이용이 가능해야 한다

Performance• 기존 시스템과의 대화에서 10 초 이하로 설정하고 , 대화 시간을 초과할 경우 관리자에게 알린다

Security• 최초 사용자 인증 시에 인증 과정 정보를 저장하고 , 이 저장된 정보를 활용하여 사용자의 권한을

할당한다 .

Exercise


Define quality attributes related to your system.


Software Requirements Specification (SRS)

Section 6.

Contents


SRS Overview SRS Contents Exercise

SRS Overview


SRS (Software Requirements Specification) 소프트웨어 시스템에 대한 요구사항을 총체적으로

명세화한 문서 IEEE Std 830

SRS Contents


Table of Contents• Introduction• Overall Description

• Use Case Model Survey• Constraints

• Specific Requirements• Use Case Reports• Supplementary Requirements

Exercise


Write a SRS using Use-Case Model, Use-Case Re-ports and Supplementary Requirements Document.

Lecture Summary

Requirements

소프트웨어 요구사항에는 비즈니스 , 기능적 , 비기능적 요구사항의 여러 분류가 존재하며 각기 다른 중요성을 가진다 .

유스케이스 모델은 시스템의 기능적 요구사항들을 반영한다 .

품질 속성은 시스템의 비기능적 요구사항들을 반영한다 . 시스템에 요구되어지는 요구사항들은 총체적으로

소프트웨어 요구사항 명세서 (SRS) 로 문서화하는 것이 좋다 .

staruml ns guide - requirements

Education