[SE] 요구사항 정의 및 개발

이 글은 충남대학교 김현수 교수님의 소프트웨어 공학 수업을 바탕으로 작성한 글입니다.

# 요구사항 정의

'어떻게' 보다는 '무엇을'에 관점을 두어야 함. 

 

# 도메인 분석

● 소프트웨어 엔지니어가 문제를 더 잘 이해하기 위하여 도메인에 대하여 알아가는 과정
    - 도메인 : 소프트웨어를 사용할 것으로 예상되는 고객이 일하는 분야의 비즈니스나 기술
    - 도메인 전문가 : 소프트웨어가 사용될 도메인 분야에 깊이 있는 지식을 가진 사람(사용자이자 고객)

● 도메인 분석을 수행하는 이점
    - 빠른 개발(빠른 요구사항 파악)
    - 더 좋은 시스템 구축 가능(고객의 문제를 효과적으로 해결하는 솔루션 결정 가능)
    - 확장 예견(트렌드를 예측하는 능력, 적응도 높은 시스템 구축)

 

# EX. 항공 예약 시스템의 도메인 분석

● 도메인 분석을 위한 정보 수집
   ≫ 항공편 일정이 어떻게 계획되는지 
   ≫ 요금은 얼마이며 요금체계는 어떤지
   ≫ 해당 항공사와 다른 항공사의 예약 방식, 발권 방식은 어떤지
   ≫ 항공권 예약에 관련된 비즈니스 종사자, 즉 여행사와 항공사 직원들의 업무 수행 방식은 어떤지
   ≫ 현재 예약 시스템이 있다면 어떻게 작동하는지
   ≫ 이 분야의 법규, 조례 등 규정은 어떤지
   ≫ 경쟁 예약 시스템의 기능 분석
   ≫ 탑승객이 직접 항공권을 예약하게 될 경우에는 어떤 변화가 필요한지

 

# 프로젝트 착수

 

# 문제 정의

● 문제란 고객이나 사용자가 직면한 어려움이다. 이는 생산성이나 매출을 높일 수 있는 기회
● 문제의 해결은 일반적으로 소프트웨어의 개발을 필요로 함.
● 좋은 문제 정의서는 짧고 간결해야 함.

 

# 범위 설정

● 시스템이 해결할 수 있는 모든 일을 상상하여 리스트 작성   
   ≫ 범위가 너무 넓으면 일부는 배제
   ≫ 범위가 너무 좁으면 시스템을 사용할 궁극적인 최상위 목표를 파악

EX) 대학 수강 신청 시스템 : 원활한 수강 신청을 위해서!
    - 문제 정의 범위 : 시스템은 교무처 직원들이 강좌, 학위 취득 요건, 수강 신청 성적 리스트를 관리하는 것을 도와준다. 또한 학생들이 취득을 위해 흥미 있는 강좌를 선택하고 신청하는 것을 도와준다.
    - 시스템에 포함되어야 할 기능 결정(+ : 포함, - : 제외)
      ≫ 수강료 수납 및 관련 회계, 고지서 발급(-)
      ≫ 입학을 위한 지원(-)
      ≫ 강의 리스트, 강의 해설, 선수 과목 리스트의 편집과 조회(+)
      ≫ 학위 취득을 위한 요건의 편집과 조회(-)
      ≫ 특정 학기에 개설된 강좌 리스트의 편집과 조회(+)
      ≫ 개설된 강의의 시간 배정(-)
      ≫ 학위 취득 요건, 지난 학기까지의 수강 과목, 일정 선호도 분석을 이용한 강의 추천(+)
      ≫ 학생 등록(+), 성적 기록(+), 성적 증명서 인쇄(+)

 

# 요구사항 추출

● 요구사항 : 제안된 시스템이 무엇을 하는가를 나타낸 문장으로 고객의 문제가 적절히 해결되기 위하여 관련자들이 동의한 것
   - 짧고 간결한 정보로 표현
   - 시스템이 무엇을 하는가를 나타냄
   - 관련자 모두가 동의한 것
   - 고객의 문제를 해결하기 위한 것

● 요구사항을 모아 놓은 것 : 요구사항 문서

 

# 요구사항의 유형

● 기능적 요구사항
   - 시스템이 무엇을 하여야 하는가를 기술한 것
   ex)  ATM 시스템, 현금 인출, 잔액 조회 등

● 비기능적 요구사항
    - 개발 과정에 고수하여야 할 제약 조건
    - 성능, 효율, 반응 시간, 소프트웨어 품질 특성에 대한 수준

● 기능적 요구 사항
    - 입력
       ≫ 시스템이 받아들이는 입력은 무엇인가?
       ≫ 사용자와 다른 시스템으로부터 유입되는 데이터와 명령어
    - 출력    
      ≫ 시스템이 생성하는 출력은 무엇인가? 
      ≫ 화면 디스플레이, 인쇄, 다른 시스템에 전달되는 정보
    - 저장
      ≫ 시스템은 어떤 데이터를 저장하는가?
    - 컴퓨팅
      ≫ 시스템에서 어떤 계산이 이루어지는가?
    - 타이밍과 동기화
      ≫ 하드웨어 장치 제어, 리얼타임으로 작업을 수행하는 시스템에서 중요
      ≫ 통신 시스템, 발전소/공장 제어 시스템, 자동차/비행기 제어 시스템 등

● 비기능적 요구 사항
   - 소프트웨어를 개발하는 동안 지켜야 할 제약 조건
     ≫ 소프트웨어 품질 특성에 대한 수준의 범위
     ≫ 모든 사항이 검증 가능(시스템 구현 후 요구사항의 충족 여부 확인)

   - 1. 소프트웨어 품질 특성 측면(성능, 신뢰성, 가용성, 사용성 등)
   - 2. 시스템의 환경과 기술적 측면
         ≫ 플랫폼 : 시스템이 동작할 HW, OS
         ≫ 사용 기술 : 프로그래밍 언어, 전자정부 표준 프레임워크 등
   - 3. 프로젝트 계획과 개발 방법에 관한 측면
         ≫ 사용하는 개발 프로세스(방법론) 
         ≫ 비용과 납기일(시스템 개발 계약서나 별도의 프로젝트 계획서에 명시)

● EX) 기능적 요구사항과 비기능적 요구사항 구별하기
    - 항공권 예약 시스템의 요구사항
      ≫ 항공편, 탑승객, 예약 입력 방법 결정
      ≫ 티켓과 리포트에 어떤 정보를 표시할 지 결정
      ≫ 요금 계산 방법 결정
      ≫ 여행사와 고객이 데이터베이스에 접근할 때 어떤 정보를 얻을 수 있는지 결정
      ≫ 자주 탑승하는 고객을 서비스하기 위해 시스템을 확장할 수 있도록 설계
      ≫ 시스템은 항상 사용 가능해야 함. 일주일에 2분 정도의 down만 허용
      ≫ 항공편을 출발 시각으로 정렬할 때 합병 정렬 알고리즘을 사용

 

 

# 요구사항 추출 방법

● 요구사항을 효과적으로 추출하고 분석하는 체계화된 기술

 

 

# 관찰

● 관찰 방법
    - 문서를 읽고 사용자와 함께 요구사항에 대하여 논의함
    - 잠재적인 사용자들이 수행하는 복잡한 일을 관찰    
      ≫ 사용자가 하는 일을 자세히 설명해 달라고 요청할 수 있음
    - 비디오 촬영
      ≫ ex) 은행의 텔러가 수행하는 업무
    - 시간이 많이 소요됨

 

 

# 인터뷰

● 미리 잘 계획하여야 많은 정보를 얻을 수 있음

● 가능하면 많은 당사자와 인터뷰 진행

● 관련자 이외의 사람과도 인터뷰
    - ex) 경쟁 제품 사용자, 마케팅 담당자 등

● 여유 시간 할애

● 인터뷰 절차
    - 대상자 선정 → 일정계획 → 질문 작성 → 언터뷰 → 분석 및 정리

● 인터뷰 질문 내용
    - 최대, 최소, 예외 규칙, 예상되는 변동 등 자세한 사항까지 질문    
      ≫ 업무 프로세스를 구성하는 각 단계가 무엇인지, 단계 개수의 변경 여부
      ≫ 설계 단계에서의 확장 가능성
      ≫ 육하원칙 적용

    - 관련자에게 시스템에 대한 미래 비전을 질문
      ≫ 어떤 융통성을 가져야 하는가?
      ≫ 다른 차선의 방법이 있는지? 
      ≫ 개발 축이 가지고 있는 대안에 대해 어떻게 생각하는지?
● 인터뷰 질문 내용
    - 문제에 대해 최소한의 허용 가능한 솔루션이 무엇인지 질문
      ≫ 너무 많은 아이디어를 얻는 경우 발생 → 사용되지 않을 기능 생성 가능 
      ≫ 고객과 사용자가 기본적으로 필요한 것이 무엇인지 확인

    - 다른 정보원에 대해 요청
      ≫ 보고 싶은 문서 요청
      ≫ 유용한 지식을 지닌 다른 사람 소개 요청

    - 다이어그램 작성을 요구
      ≫ 다이어그램을 통해 정보의 흐름, 명령의 순서, 기술이 어떻게 작용하는지 등을 파악
      ≫ 다이어그램은 정보 수집을 촉진

 

 

# 브레인스토밍

● 아이디어를 낼 목적으로 여러 명으로부터 정보를 얻기 위한 회의

● 훈련된 요원이 주재

● 토론보다는 아이디어를 쏟아 놓는 회의, 익명성 보장

● JAD(Joint Application Development)
   - 최종 사용자와 개발자가 시스템 개발 논의
   - 격리된 장소에서 개발자는 고객과 사용자를 만나 요구사항을 정의하기 위해 공동 작업
   - 집중 브레인스토밍 세션
   - 요구사항 분석에 필요한 기간을 획기적으로 단축 가능

 

 

# 프로토타이핑

● 최종 시스템의 예상 기능 중 일부를 빠르게 구현한 프로그램

● 가장 단순한 형태 : paper prototype
    - 사용자 인터페이스를 종이에 그림
    - 시스템의 화면을 순서대로 사용자에게 보여주는 형태
    - 아이디어 추출, 피드백 받기에 적합
    - 다수의 개발자가 시스템에 대한 자신의 관점 병행하여 작성, 결과 평가  

● 가장 흔한 형태 : mock-up of the UI
    - 프로토타이핑 전용 언어로 작성
    - 컴퓨팅, 데이터베이스 접근, 다른 시스템과의 상호작용은 불가

● 시스템의 특별한 측면을 프로토타이핑 하기도 함
    - 알고리즘, 데이터베이스 등

 

 

# 요구사항 문서화

● 두 가지 극단적인 형태
    - 몇 문단의 글이나 다이어그램으로 요구사항의 아우트라인을 정의한 것
       ≫ 요구사항 정의(requirement definition)
    - 수천 페이지의 복잡하고 자세한 명세 리스트
       ≫ 요구사항 명세서

● 대규모 시스템을 위한 요구사항 문서는 계층적으로 정리

 

 

# 요구사항 문서의 상세 수준

● 얼마나 자세히 기술하여야 하는가는 다음 사항을 고려하여 결정
    - 시스템의 크기 - 다른 시스템에 대한 인터페이스 요구 (통신 프로토콜)
    - 목표로 하는 독자 (일반 사용자, 전문인)
    - 개발을 위한 계약 (외주 계약, 정부 기관 계약)
    - 요구사항 취합 단계 (초기 단계 – 시스템이나 서브시스템 개요 간략)
    - 도메인 및 기술에 대한 경험 수준
      ≫ 혁신적인 소프트웨어 개발: 대략적인 요구사항 → 프로토타입 개발, 아이디어 검증, 보유 기 술의 신뢰성 검토
    - 요구사항의 오류로 인한 손해 비용
      ≫ 고장으로 인해 안전이나 환경에 심각한 위험 초래 → 정확한 명세 필요

 

 

# 요구사항 문서의 구성

 

 

# 요구사항 검토

● 각 요구사항이 다음을 만족하는지 검토

 

 

# 요구사항 변경 관리

● 요구사항은 게속 바뀜
    - 비즈니스 프로세스의 변경
    - 기술의 변경
    - 문제 이해 향상

● 요구사항 변경 시 고려 사항
    - 고객 및 사용자와 지속적인 상호작용
    - 변경으로 인한 이익이 변경 비용을 초과하여야 함
       ≫ 작은 변화는 적은 비용으로 빠르고 신속히 가능
       ≫ 대규모 변화는 신중하게 접근
    - 어떤 변경은 위장된 확장일 가능성 존재
       ≫ 시스템의 규모를 키우는 것은 피하고 오직 더 좋은 시스템이 되도록 노력