3. Understanding Requirements – Use case model

김명윤·2024년 4월 23일

Requirements

  • desired behavior의 표현
  • solution과 implementation이 아닌 customer needs에 초점을 맞춤
  • needs와 관련 constraints, 조건을 표현하는 statement
    constraints : 우리가 원하는 것을 구현할 때 반드시 고려해야 하는 실제 세계의 한계나 제한

Why Are Requirements Important?

  • project가 실패하는 주 원인
    • Incomplete requirements
    • Lack of user involvement
    • Unrealistic expectations
    • Lack of executive support
    • Changing requirements and specifications
    • Lack of planning
    • System no longer needed
  • 프로젝트 실패의 주요 요인들 중 대부분이 Requirements 프로세스와 관련 있음
  • Requirements error는 초기에 감지되지 않을 경우 큰 비용과 문제를 야기함

Types of requirements

  1. Functional Requirement
    시스템이나 제품이 수행해야 할 기능에 관한 것입니다. 예를 들어, 사용자 로그인, 데이터 검색, 주문 처리 등과 같은 기능적인 요구사항을 포함합니다.
  2. Quality Requirement or Nonfunctional Requirement
    시스템의 성능과 관련된 요구사항으로, 성능, 신뢰성, 사용성, 보안 등에 대한 기준을 설정합니다.
  • Performance, Reliability, Usability, Security
  • Safety
  • Maintainability

  1. Constraints
    프로젝트 개발 과정에서 반드시 지켜야 할 제약 조건을 나타냅니다. 이에는 법적, 기술적, 개발 프로세스 및 리소스, 디자인, 운영 제약사항 등이 포함될 수 있습니다.

  2. External Interfaces
    시스템이나 제품이 상호작용해야 할 외부 요소와의 인터페이스에 관한 요구사항

  • Users, Organizations, Roles (사용자, 조직, 역할): 시스템을 사용하는 사용자의 프로필, 관련 조직 및 역할에 대한 요구사항입니다.
  • Other Systems, Devices, etc. (다른 시스템, 장치 등): 시스템이 연동되어야 하는 다른 시스템이나 장치에 대한 요구사항입니다.

Requirements Elicitation: Stakeholders

  • 요구사항 도출(Requirements Elicitation)은 프로젝트의 성공을 위해 필요한 요구사항을 수집하고 정의하는 과정
  • 이 과정에서 다양한 이해당사자(Stakeholders)들과의 협업이 필요

Clients (의뢰인):
소프트웨어 개발 비용을 지불
Customers (고객):
소프트웨어 개발이 완료된 후에 해당 소프트웨어를 구매
Users (사용자):
시스템을 사용하여 작업을 수행
Domain Experts (도메인 전문가):
소프트웨어가 자동화해야 할 문제에 익숙
Market Researchers (시장 조사자):
미래의 트렌드와 잠재적 고객을 파악하기 위해 설문조사 등을 수행
Lawyers or Auditors (변호사 또는 감사인):
정부, 안전, 법률적 요구사항 등에 대한 이해를 가지고 있습니다.
Software Engineers or Other Technology Experts (소프트웨어 엔지니어 또는 기술 전문가):
소프트웨어 개발과 관련된 기술적 지식을 가지고 있음

Requirements Elicitation: Means of Eliciting Requirements

Interviewing Stakeholders (이해당사자 인터뷰): 이해당사자들과 일대일로 만나 질문을 하고 대화를 통해 요구사항을 수집
Reviewing Available Documentations
기존에 작성된 문서, 보고서, 명세서 등을 검토하여 요구사항을 파악
Observing Current System (현재 시스템 관찰): 기존에 존재하는 시스템의 작동 방식을 직접 관찰하여 요구사항을 도출
Observing Stakeholders (이해당사자 관찰):
이해당사자들의 일상적인 업무나 활동을 관찰하여 요구사항을 이해합니다. 관찰은 관찰자, 카메라, 컴퓨터 모니터링 등을 통해 이루어질 수 있습니다.
Apprenticing with Users (사용자와 함께 학습): 사용자와 함께 일하는 것을 통해 사용자의 작업과 프로세스를 상세하게 이해
Focus Group Interview (포커스 그룹 인터뷰):이해당사자들을 한 그룹으로 모아 집단 인터뷰를 진행
Survey (설문조사):
이해당사자들에게 설문지를 제공하여 의견과 피드백을 수집
Brainstorming with Current and Potential Users (현재 및 잠재 사용자와 아이디어 회의):
사용자들과 아이디어를 공유하고 토론하는 세션을 진행
Prototyping (프로토타이핑):
초기 설계나 모델을 만들어 사용자에게 제시하고 피드백을 받음

Use case Model

use case :

  • 시스템이 수행할 수 있는 특정 기능이나 작업을 나타내는 개념

use case model :

  • 여러 Use Case를 조직적으로 표현한 것입니다.
  • Use Case Model은 시스템의 전체적인 기능과 작업 흐름을 나타내며, 시스템의 요구사항을 명확하게 이해하고 문서화하는 데 사용

User Story :

  • 사용자의 필요와 가치를 중심으로 시스템의 기능을 작성
  • "As a [사용자 역할], I want to [기능], so that [목적]."

Use Case (사용 사례)

시스템과 액터(사용자 또는 시스템) 간의 대화를 통해 특정 목표를 달성하기 위한 시나리오를 기술하는 것

  • Use Case는 특정 액터와 시스템 간의 대화를 기술

    • 이 대화는 액터가 어떤 목표를 달성하기 위해 시스템을 어떻게 사용하는지를 나타냅니다.

  • Use Case는 여러 개의 use-case instance의 집합

    • 각 인스턴스는 시스템이 수행하는 일련의 동작을 나타냅니다. 이 동작들은 특정 액터에게 가치 있는 결과를 제공합니다.

  • Use Case에는 성공 시나리오와 실패 시나리오가 포함됩니다.

Actor

  • Anything that interfaces with your system:
    액터는 시스템과 상호작용하여 특정 기능을 수행하거나 정보를 제공

  • Each actor defines a particular role:
    각 액터는 시스템 내에서 특정한 역할을 가집니다. 예를 들어, '고객', '관리자', '외부 시스템', '센서' 등의 역할을 가진 액터들이 있을 수 있음

  • Always external to your system : 액터는 항상 시스템 외부에 위치하며, 시스템의 일부가 아닙니다. 이는 시스템과의 상호작용을 통해 특정 작업을 수행하는 요소로서의 역할을 강조

  • 다양한 유형의 액터

    • Person/Organization, Computer system, Hardware device

    ➡️ 액터는 시스템과 상호작용하여 특정 기능을 수행하는 모든 요소를 의미합니다. 각 액터는 시스템 내에서 특정 역할을 가지며, 다양한 형태와 유형을 가질 수 있습니다.

Writing Use Cases

Use Case를 작성하는 것은 시스템을 사용하는 과정을 스토리 형태로 기술하는 것

  • Stories using a system
    Use Case는 시스템을 사용하는 과정을 스토리 형태로 작성
  • Easy to understand and describe requirements
    Use Case를 통해 요구사항을 명확하게 이해하고 문서화할 수 있음
  • Help fulfill various stakeholder goals
    Use Case는 다양한 이해당사자의 목표를 지원하고 달성하는 데 도움을 줌
  • Use cases are not merely feature list
    Use Case는 단순한 기능 목록이 아닙니다. 대신, 시스템 사용의 흐름과 상호작용을 포함하는 이야기로 작성되어야 함
  • Focus on “How can using the system provide observable value to the user, or fulfill their goals?”
    Use Case는 시스템이 사용자에게 어떤 가치를 제공하고, 사용자의 목표를 어떻게 달성하는지에 초점을 맞춰야 함
  • Focus on functionality of the system, but useful tool to discover nonfunctional, quality requirements
    시스템의 기능성을 중점으로 하지만, 이 과정에서 비기능적 요구사항 및 품질 요구사항을 발견하고 문서화하는 유용한 도구로 활용될 수 있음

Use Case 작성 과정

  1. Choose the System Boundary
  2. Identify the primary actors
  3. For each primary actor, identify their user goals
    주요 액터에 대해 사용자의 목표를 식별
  4. Identify use cases that satisfy user goals
    각 주요 액터의 사용자 목표를 만족시키는 Use Case를 식별
  5. For each use case, write various scenarios and supporting sections
    각 Use Case에 대한 다양한 시나리오와 지원 섹션을 작성

시스템 경계 (System Boundary)

  • 시스템과 외부 세계 간의 구분
  • 시스템 내부에는 시스템이 직접 관리하고 제어하는 요소들이 위치하며, 외부에는 시스템과 상호작용하는 다른 요소들이 있습니다.
  • 시스템 내부에 있는 것들 (What things are inside your system?)
    • 시스템 내부에는 시스템이 관리하고 제어하는 모든 구성 요소들이 포함
    • 데이터베이스, 서버, 애플리케이션 모듈, 사용자 인터페이스 등과 같은 요소
    • have to create
  • 외부에 있는 것들 (What are outside your system?)
    • 시스템 외부에는 시스템과 상호작용하는 다른 시스템, 사용자, 장치 등이 위치
    • don’t have to create

System Boundary and Actor

  • Actor는 시스템 외부의 개체나 엔터티를 나타냅니다.
  • 이러한 액터들은 시스템과 상호작용하여 시스템의 서비스를 이용하거나 정보를 제공합니다.
  • 액터는 시스템 경계 내부에 위치하지 않으며, 시스템과의 상호작용을 통해 시스템에 영향을 미칠 수 있습니다.

Primary and Supporting actors

Primary Actor

  • 시스템을 통해 자신의 사용자 목표를 달성하려고 합니다. 즉, 시스템의 서비스를 이용하여 특정 목표나 활동을 수행하려는 액터를 의미
  • 시스템과의 상호작용을 시작하며, 이를 통해 시스템의 서비스를 이용하거나 정보를 제공받습니다.

Supporting Actor

  • 시스템에 특정 서비스나 정보를 제공하는 역할을 합니다. 이 액터는 주요 액터의 목표 달성을 도와주는 보조적인 역할을 합니다

"시간"이 액터인가?
"시간"은 시스템의 행동을 촉발하는 요소이지만, 액터의 정의에 따르면 액터는 시스템과 상호작용하는 외부 개체나 엔터티를 의미합니다. 따라서 "시간"은 액터로 간주되지 않습니다.

Identifying Actors

• Who uses the system?
• What other systems use this system?
• Who gets information from this system?
• Who provides information to the system?
• Who installs the system?
• Who starts up the system?
• Who maintains the system?
• Who shuts down the system?
• Does anything happen automatically at a present time?

Actor-Goal List

  • 액터 식별
    시스템과 상호작용하는 모든 액터를 목록화합니다.
    Primary 액터와 Supporting 액터를 구분합니다.
  • 사용자 목표 정의
    각 주요 액터에 대해 사용자 목표를 식별하고 문서화합니다.

Identify Use Cases

  • Define Use Case Based on User Goals
    각 주요 액터의 user goal 기반으로 하나의 Use Case를 정의합니다. 즉, 하나의 Use Case는 하나의 user goal를 중심으로 설계=

  • Name Use Case Similar to User Goal
    사용 사례의 이름은 해당 사용자 목표와 유사하게 명명

Use case Diagram


1. Identify Actors
2. Identify Use Cases
3. Connect Actors with Use Cases
4. Complete the Diagram

로욜라 도서관 시스템 재구축을 위한 요구사항 정의

  1. 시스템 구축 범위 정의
  2. Primary Actor 식별
  3. Primary Actor 별 Goal 정의
  4. Use case 식별 + secondary actor 식별
  5. Use case Diagram 으로 표현하기

Write scenarios

시나리오는 시스템과 액터(사용자) 간의 특정 상호작용을 구체적으로 설명하는 것

  1. Actor action or input …
    액터가 시스템에 대해 어떤 행동을 취하거나 입력을 제공
  2. System responsibility
    시스템이 액터의 입력을 받아 처리하는 책임을 수행
  3. Actor enter input into the system ….
    액터가 시스템에 추가적인 입력을 제공
  4. System records … and response …
    시스템이 액터의 입력을 기록하고 적절한 응답을 제공

시나리오 유형
Main Success Scenario (Basic Flow)

  • 시스템이 예상대로 잘 작동할 때의 주요 시나리오를 설명
  • 이 시나리오는 사용 사례의 기본 흐름을 보여줌

Alternative Scenarios (Extensions)

  • 주요 시나리오 외에 발생할 수 있는 다양한 상황을 설명
  • 예외 상황, 오류 처리, 사용자의 다른 선택 등을 포함

Use cases are text documents, not diagrams

Use Case Description

  1. Use Case Name
  • Use Case가 어떤 actor의 어떤 목표를 달성하기 위해 사용되는 지 명확하게 표현
  • Actor-Goal List을 기반으로 정의됨
  1. Primary Actor
  • 시스템의 서비스를 호출하여 특정 목표를 달성하려는 액터
  1. Stakeholder and Interests
  • Use Case가 어떤 이해관계자의 어떤 관심사를 충족시키기 위해 설계되었는지를 명확하게 기술
  1. Preconditions
  • Use Case의 시나리오를 시작하기 전에 항상 참이어야 하는 조건을 명시

  1. Postconditions
  • Use Case가 성공적으로 완료될 경우에 반드시 충족되어야 하는 조건을 명시
  • 모든 이해관계자의 요구사항을 만족시키는 보장을 제공


6. Main Success Scenario (or Basic Flow)

  • “Happy path” scenario
  • 이해관계자의 관심사를 만족시키는 일반적인 성공 경로
  • 일반적으로 복잡한 조건이나 branching이 없는 단순한 시나리오를 따름
    • "Branching"은 사용 사례에서 흐름이 여러 가지 경로로 나뉘는 것을 의미

Two-Column Variation

  • Use Case를 표 형식으로 작성할 때 사용되는 형식 중 하나.
  • 이 방식은 주로 대화형 형식으로 사용되며, 두 개의 열(column)을 사용하여 액터와 시스템 간의 대화를 나타냅니다.
  1. Alternative Flows
  • Main Success Scenario)에서 분기되는 다른 시나리오나 상황을 설명
  • 성공적인 경우뿐만 아니라 실패하는 경우에 대한 처리 방법도 포함
  • 오류나 예외 상황에 대한 처리 방법을 상세하게 명시
  • 흐름이 끝나면 기본 흐름(Basic Flow)으로 다시 병합되어 기본 흐름이 계속됩니다. 병합하지 않는 경우에는 명시적으로 표시

Finding Alternative Flows

주요 질문:

  • 이 지점에서 다른 동작을 취할 수 있는가?
  • 이 지점에서 문제가 발생할 수 있는가?
  • 아무 때나 발생할 수 있는 특정 행동이 있는가?

카테고리 사용:
• An actor exists the application.
• An actor cancel a particular operation.
• An actor requests help.
• An actor provides bad data.
• An actor incomplete data.
• An actor chooses an alternative way of performing the use case.
• The system crashes.
• The system is unavailable.

  1. Special Requirements
  • Use Case에 대한 Non-functional requirements, quality requirements, design constraints 등을 기술
  • Usability: 사용자가 시스템 또는 애플리케이션을 쉽고 효과적으로 사용할 수 있는 정도를 의미
  • Performance : 시스템이 얼마나 빠르고 효율적으로 동작하는지
  • Accessibility : 모든 사용자가 애플리케이션을 동등하게 이용할 수 있는 능력을 의미
  • Reliability : 시스템이 일관되고 예측 가능하게 작동하는 정도
  • User Environment: 사용자가 시스템을 사용하는 환경을 의미

Use case Reviews

• A behavior of the system that produces a measurable result of value to an actor
특정 액터(사용자나 시스템)에게 어떠한 가치 있는 결과를 제공해야 함
• A use case should be a complete task from the actor’s perspective
use case는 액터의 관점에서 완전한 작업을 나타내야 함, 이는 시작부터 끝까지의 전체 과정을 포함해야 함을 의미
• The behavior of a single use case is often complete in a relatively short period of time
대부분의 use case는 상대적으로 짧은 시간 내에 완료되어야 함
• A use case is always started by an actor

Elementary Business Process (EBP) Test

  • EBP 테스트는 시스템의 특정 작업이 유용하고 비즈니스에 가치를 더하는지 확인하는 방법
  • 작업은 한 사람이 한 번에 한 장소에서 수행할 수 있는 작업이어야 함
  • 작업은 시간이나 비용 절약과 같이 비즈니스에 측정 가능한 이점을 창출해야 함
  • 작업은 일관된 방식으로 데이터를 유지하거나 업데이트해야 함

Size Test

  • use case가 보통 단일 행동이나 단계로 구성되지 않는다는 것을 강조

  • 단일 단계만을 설명하는 것은 사용 사례의 전체적인 흐름을 놓치게 되므로, 크기 테스트를 통과하지 못함

  • 예시:
    온라인 주문 시스템: "상품 구매"라는 사용 사례는 다음과 같은 여러 단계로 구성될 수 있습니다:
    로그인
    상품 선택
    장바구니에 추가
    주문 및 결제
    주문 완료

이렇게 여러 단계를 포함하는 사용 사례는 전체적인 프로세스를 상세하게 설명하므로, 크기 테스트를 통과할 수 있습니다.

Include Relationship

  • include는 하나의 use case가 다른 use case의 실행을 전제로 할 때 형성되는 관계
  • 포함되는 use case는 포함하는 use case를 실행하기 위해 반드시 실행되어야 함
  • 일반적으로 여러 use case에서 공통적으로 나타나는 부분적인 동작이 존재
  • 이는 중복을 방지하기 위해 subfunction use case로 분리하여 포함 여부를 표시하는 것이 바람직

Extend Relationship

  • 핵심 기능을 변경하지 않고 기본 유스 케이스에 추가 기능이나 변형을 추가하는 방법
  • 추가 단계 또는 기능(확장 사용 사례)은 특정 조건이 충족되는 경우에만 적용됨
  • Extension points : 추가 단계나 기능을 추가할 수 있는 base use case 의 특정 지점
profile
김명윤
김변
이전 포스트

블록체인

다음 포스트

2. Software Development Process

0개의 댓글