소프트웨어 설계 - 요구사항 확인

정보처리기사
공개

2026년 1월 10일

소프트웨어 생명(수명) 주기

  • 소프트웨어 개발 방법론[^1]의 바탕이 되는 것으로, 소프트웨어를 개발하기 위해 정의하고 운용, 유지보수 등의 과정을 각 단계별로 나눈 것
  • 소프트웨어 공학
    • 소프트웨어의 위기를 극복하기 위한 방안으로 연구된 학문
    • 기본 원칙:
      • 현대적인 프로그래밍 기술을 계속 적용해야 함
      • 개발된 소프트웨어 품질이 유지되도록 지속적으로 검증해야 함
      • 소프트웨어 개발 관련 사항 및 결과에 대한 명확한 기록을 유지해야 함

대표적 모형

  1. 폭포수 모형
    • 이전 단계로 돌아갈 수 없다는 전제하에 각 단계를 확실히 매듭짓고 그 결과를 철저하게 검토하여 승인 과정을 거친 후 다음 단계로 진행하는 방식
    • 가장 오래되고 폭넓게 사용된 모형. 적용 경험과 성공 사례가 많음
    • 결과물이 명확하게 산출되어야 함
    • 병행 작업 불가
  2. 프로토타입(원형) 모형
    • 의뢰자나 개발자 모두에게 공동의 참조 모델이 되는 시제품 개발
    • 새로운 요구사항이 도출될 때마다 이를 반영한 프로토타입을 새롭게 만듦
    • 단기간 제작을 목적으로 함
    • 비효율적인 언어나 알고리즘이 사용될 수 있음
  3. 나선형(점진적) 모형
    • 위험 관리에 중점을 둔 모형
    • 핵심 기술에 문제가 있거나 사용자의 요구사항이 이해하기 어려운 경우 적합
    • 각 단계마다 계획, 분석, 개발, 평가의 활동을 반복
  4. 애자일 모형
    • 스크럼, XP, 칸반, 린, 크리스탈, ASD, 기능 중심 개발(FDD), DSDM, DAD 등
    • 4가지 핵심 가치
      1. 프로세스와 도구보다 개인과 상호작용을 중시
      2. 포괄적인 문서화보다 작동하는 소프트웨어를 중시
      3. 계약 협상보다 고객과의 협력을 중시
      4. 계획을 따르기보다 변화에 대응하는 것을 중시

XP(익스트림 프로그래밍) 기법

  • 릴리즈의 기간을 짧게 반복하면서 고객의 요구사항 반영에 대한 가시성을 높이는 기법
  • 핵심 가치: 의사소통, 단순성, 용기, 존중, 피드백

개발 프로세스
  • 스파이크: 잘 모르는 프로그램 그냥 간단하게 데모로 만들어 보는 것
  • iteration: 하나의 릴리즈를 세분화 한 단위. 일반적으로 1~3주
  • 승인 검사: iteration 완료 후 고객이 직접 수행

주요 실천 방법

  1. pair programming: 혼자 개발하지 마라
  2. collective ownership: 코드 권한, 책임 공유
  3. continuous integration
  4. design improvement / refactoring

요구사항 정의

유형

  • 기능 요구사항: 사용자가 시스템을 통해 제공받기 원하는 기능
  • 비기능 요구사항: 품질, 제약사항 등

개발 프로세스

  1. 타당성 조사
  2. 도출
    • 관련 사람들이 서로 의견을 교환하며 요구사항이 어디에 있는지, 어떻게 수집할 것인지 식별
    • 청취, 인터뷰, 브레인 스토밍, 프로토타이핑, 유스케이스 등
  3. 분석
    • 소프트웨어 개발의 실제적인 첫 단계, 사용자의 요구사항을 이해하고 문서화하는 활동을 의미
    • 타당성 조사, 제약 설정, 중복 제거, 소프트웨어 범위 파악 등
    • Agile, UML, 자료 흐름도(DFD), 자료 사전(DD) 등의 도구가 사용됨
      • 자료 흐름도(자료 흐름 그래프, 버블 차트)
        • 프로세스: 원, 자료 흐름: 화살표, 자료 저장소: top-bottom border, 단말: 네모
        • 처리를 거칠 때 마다 새로운 자료 흐름 이름 부여
        • 출력은 반드시 입력이 필요. 역은 성립하지 않음
      • 자료 사전: 자료 흐름도에 있는 자료를 더 자세히 정의하고 기록한 것(메타 데이터)
        • =: 자료의 정의(구성 요소)
        • \(\{\}_n\): n번 이상 반복, \(\{\}^n\): 최대 n 번 반복
        • (): optional
        • +: and, []: or
        • * *: 주석
  4. 명세
    • 정형 명세 기법
      • 수학적 원리, 모델 기반
      • 일관성 있고 간결하지만 이해하기 어려움
      • VDM, Z, Petri net, CSP 등
    • 비정형 명세 기법
      • 상태 / 기능 / 객체 중심
      • 자연어로 작성되어 이해하기 쉬우나, 모호하고 일관성이 떨어짐
      • FSM, Decision Table, ER 모델링, State Chart 등
  5. 확인

요구사항 분석 CASE(자동화 도구)

  • SADT(Structured Analysis and Design Technique): 구조적 요구 분석을 위해 블록 다이어그램을 채택한 도구
  • HIPO(Hierarchy Input Process Output): 입력, 처리, 출력으로 구성되며 하향식 소프트웨어 개발을 위한 문서화 도구
    • HIPO Chart 종류:
      • 가시적 도표: 목차
      • 총체적 도표: 프로그램을 구성하는 기능들 기술
      • 세부적 도표: 기능의 구성 요소 기술

UML(Unified Modeling Language)

  • 모두를 위한 객체지향 모델링 언어

사물

  • 구조 사물: 노드, 클래스, 컴포넌트 등
  • 행동 사물: 시간과 공간에 따른 요소들의 행위 (상호작용, 상태 머신 등)
  • 그룹 사물
  • 주해 사물: 부가 설명

관계

  • 연관 관계: 실선으로 표현. 양방향의 경우 화살표 생략 가능
    • 0, 1, n: 연관된 객체의 갯수
    • *: 연관된 객체가 다수일 수 있음을 의미
    • 1..n: 최소 1개에서 최대 n개
  • 의존 관계: 점선 화살표. 짧은 시간 동안만 연관있는 관계
  • 일반화 간계: 속이 빈 화살표
  • 실체화 관계: 점선 속이 빈 화살표. 사물의 기능 표현

다이어그램

  • 구조적 다이어 그램: 정적 모델링
    • 클래스 다이어그램
      • class: 일반적으로 3개의 획으로 나눠 클래스 이름, 속성, 오퍼레이션을 표기함
      • 제약 조건: 입력될 값에 대한 조건, 오퍼레이션(함수) 전후에 지정해야 할 조건
      • 관계: 연관, 포함, 집합, 일반화, 의존
    • 객체 다이어그램: 인스턴스를 특정 시점의 객체와 객체 사이의 관계로 표현
    • 컴포넌트 다이어그램: 구현 단계에서 실제 컴포넌트 간의 관계나 인터페이스 표현
    • 배치(deployment) 다이어그램: 결과물, 프로세스, 컴포넌트 등 물리적 요소들의 위치를 표현
    • 패키지 다이어그램: 유스케이스나 클래스 등의 모델 요소들을 그룹화한 패키지들의 관계 표현
  • 행동 다이어그램: 동적 모델링
    • 유스케이스 다이어그램: 사용자, 사용 사례로 구성. 사용 사례 간 여러 관계 표현
      • 시스템: 시스템 내부에서 수행되는 기능들을 사각형으로 묶어 표현
      • 액터: 시스템과 상호작용 하는 모든 외부 요소
        • 주액터: 시스템을 사용함으로써 이득을 얻는 대상
        • 부액터: 주액터의 목적 달성을 위해 서비스를 제공하는 외부 시스템
      • 유스케이스: 사용자가 보는 관점에서 시스템이 액터에게 제공하는 서비스
      • 관계: 연관, 포함, 확장, 일반화
    • 순차 다이어그램: 객체 간 메세지 표현
      • 액터: 외부 시스템
      • 객체: 메시지를 주고받는 주체
      • 생명선: 객체가 메모리에 존재하는 기간
      • 실행 상자: 객체가 메시지를 주고받고 있음을 표현
      • 메시지
      • 회귀 메시지(reply message)
      • 제어 블록(loop)
    • 상태 다이어그램: 이벤트에 의한 객체들의 변화 표현
    • 활동 다이어그램: 객체의 처리 흐름 표현
맨 위로